Preguntas más frecuentes sobre la CLI para desarrolladores de Azure

Hay diferentes opciones para desinstalar azd en función de cómo se instaló originalmente. Visite la página de instalación para obtener más información.

La CLI para desarrolladores de Azure (azd) y la CLI de Azure (az) son herramientas de línea de comandos útiles para realizar diferentes tareas.

azd se centra en el flujo de trabajo de alto nivel del desarrollador. Además de aprovisionar o administrar recursos de Azure, azd permite unir los componentes de la nube, la configuración loca del desarrollo y la automatización de canalizaciones en una solución completa.

La CLI de Azure es una herramienta de plano de control para crear y administrar la infraestructura de Azure, como máquinas virtuales, redes virtuales y almacenamiento. La CLI de Azure está diseñada en torno a comandos granulares destinados a tareas administrativas específicas.

La CLI para desarrolladores de Azure utiliza un nombre de entorno para establecer la variable de entorno AZURE_ENV_NAME que utilizan las plantillas de la CLI para desarrolladores de Azure. AZURE_ENV_NAME también se utiliza para anteponer el nombre del grupo de recursos de Azure. Dado que cada entorno tiene su propio conjunto de configuraciones, la CLI para desarrolladores de Azure almacena todos los archivos de configuración en directorios de entorno.

├── .Azure                          [This directory displays after you run add init or azd up]
│   ├── <your environment1>         [A directory to store all environment-related configurations]
│   │   ├── .env                    [Contains environment variables]
│   │   └── main.parameters.json    [A parameter file]
│   └── <your environment2>         [A directory to store all environment-related configurations]
│   │   ├── .env                    [Contains environment variables]
│   │   └── main.parameters.json    [A parameter file]
│   └──config.json 

Sí. Puede configurar diferentes entornos (por ejemplo, desarrollo, pruebas, producción). Puede utilizar azd env para administrar estos entornos.

La ruta del archivo .env es <your-project-directory-name>\.azure\<your-environment-name>\.env.

En la CLI para desarrolladores de Azure, los comandos azd hacen referencia al archivo .env de la configuración del entorno. Los comandos como azd deploy también actualizan el archivo .env con, por ejemplo, el cadena de conexión de base de datos y el punto de conexión de Azure Key Vault.

Sí. Puede seguir las tareas de desarrollo de forma local.

1. Ejecute azd init -t <template repo> para clonar el proyecto de la plantilla en la máquina local.
2. Para extraer el archivo env existente creado mediante Codespaces, ejecute azd env refresh. Asegúrese de facilitar el mismo nombre de entorno, suscripción y ubicación que antes.

El archivo azure.yaml describe las aplicaciones y los tipos de recursos de Azure que se incluyen en la plantilla.

La función secretOrRandomPassword recupera un secreto de Azure Key Vault si se dan los parámetros del nombre del almacén de claves y del secreto. Si estos parámetros no se indican o no se puede recuperar un secreto, la función devolverá en su lugar una contraseña generada aleatoriamente para usarla.

En el ejemplo siguiente se ve un caso práctico común de la propiedad secretOrRandomPassword en un archivo main.parameters.json. Las variables ${AZURE_KEY_VAULT_NAME} y sqlAdminPassword se pasan como parámetros para los nombres del almacén de claves y del secreto. Si el valor no se puede recuperar, se genera una contraseña aleatoria en su lugar.

  "sqlAdminPassword": {
    "value": "$(secretOrRandomPassword ${AZURE_KEY_VAULT_NAME} sqlAdminPassword)"
  } 

El resultado de secretOrRandomPassword también debe guardarse en el almacén de claves mediante Bicep para ejecuciones posteriores. La recuperación y reutilización de los mismos secretos entre implementaciones puede evitar errores o funcionamientos no deseados que pueden surgir al generar repetidamente nuevos valores. Para crear un almacén de claves y almacenar el secreto generado en él, use el código de Bicep siguiente. Puede ver el código de ejemplo completo de estos módulos en el repositorio GitHub de la CLI para desarrolladores de Azure.

module keyVault './core/security/keyvault.bicep' = {
  name: 'keyvault'
  scope: resourceGroup
  params: {
    name: '${take(prefix, 17)}-vault'
    location: location
    tags: tags
    principalId: principalId
  }
}

module keyVaultSecrets './core/security/keyvault-secret.bicep' = {
  name: 'keyvault-secret-sqlAdminPassword'
  scope: resourceGroup
  params: {
    keyVaultName: keyVault.outputs.name
    name: 'sqlAdminPassword'
    secretValue: sqlAdminPassword
  }
}]

Esta configuración de Bicep habilita el siguiente flujo de trabajo para administrar los secretos:

1. Si existe el secreto correspondiente, se recupera del almacén de clave mediante la función secretOrRandomPassword.
2. Si el secreto no existe, se crea una instancia del almacén de claves y el secreto generado aleatoriamente se almacena dentro de él.
3. En futuras implementaciones, el método secretOrRandomPassword recupera el secreto almacenado ahora que está en el almacén de claves. El almacén de claves no se volverá a crear si ya existe, pero el mismo valor secreto se almacenará de nuevo en la siguiente ejecución.

Sí, pero cada ubicación de Azure solo puede tener una implementación. Si ya ha usado la ubicación de Azure seleccionada, se producirá un error de implementación:

InvalidTemplateDeployment: The template deployment '<env_name>' isn't valid according to the validation procedure. The tracking ID is '<tracking_id>'. See inner errors for details.

Puede seleccionar otra ubicación de Azure para corregir el problema.

Esto puede deberse a nuestro método para asignar nombres a los recursos.

Nuestras plantillas creadas "Azure Dev" permiten configurar el nombre del recurso. Para ello, puede agregar una entrada en main.parameters.json en la carpeta infra. Por ejemplo:

  "webServiceName": {
  "value": "my-unique-name"
}

Esta entrada crea un nuevo recurso denominado "my-unique-name" en lugar de un valor aleatorio como "app-web-aj84u2adj" la próxima vez que aprovisione la aplicación. Puede eliminar manualmente el grupo de recursos antiguo en Azure Portal o ejecutar azd down para eliminar todas las implementaciones anteriores. Después de quitar los recursos, ejecute azd provision para volver a crearlos con el nuevo nombre.

Este nombre deberá ser único globalmente; de lo contrario, recibirá un error de ARM durante azd provision cuando intente crear el recurso.

El comando usa plantillas de Bicep, que se encuentran en <your-project-directory-name>/infra para aprovisionar recursos de Azure.

Vaya a https://portal.azure.com y busque el grupo de recursos, que es rg-<your-environment-name>.

Usamos plantillas de Bicep, que se encuentran en <your-project-directory-name>/infra, para aprovisionar recursos de Azure. Si hay problemas, se incluye el mensaje de error en lo que se genere en la CLI.

También puede ir a https://portal.azure.com y buscar el grupo de recursos, que es rg-<your-environment-name>. Si se produce un error en alguna de las implementaciones, seleccione el vínculo del error para obtener más información.

Para otros recursos, consulte Solución de errores comunes de implementación de Azure: Azure Resource Manager.

Próximamente. Está planeado que esta característica se lance en el futuro.

Sí.

Durante la implementación, azd detecta primero todos los grupos de recursos que componen la aplicación buscando grupos etiquetados con azd-env-name y con un valor que coincida con el nombre del entorno. Seguidamente, enumera todos los recursos de cada uno de estos grupos de recursos, buscando un recurso etiquetado con azd-service-name con un valor que coincida con el nombre del servicio en azure.yaml.

Aunque se recomienda usar etiquetas en recursos, también puede usar la propiedad resourceName en azure.yaml para indicar un nombre de recurso explícito. En ese caso, la lógica anterior no se ejecuta.

Sí. Usamos el modo de implementación gradual.

Próximamente. Está planeado que esta característica se lance en el futuro.

Una entidad de servicio de Azure es una identidad que se ha creado para su uso con aplicaciones, servicios hospedados y herramientas automatizadas que acceden a los recursos de Azure. Este acceso está restringido por los roles que se han asignado a la entidad de servicio, lo que le permite controlar a qué recursos pueden tener acceso y en qué nivel. Para obtener más información sobre la autenticación de Azure a GitHub, consulte Conexión de GitHub y Azure | Microsoft Docs.

No. El comando azd pipeline config se encarga de crear la entidad de servicio de Azure y de realizar los pasos necesarios para almacenar los secretos en el repositorio de GitHub.

El comando almacena cuatro secretos en GitHub: AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION y AZURE_SUBSCRIPTION_ID. Para invalidar el valor de cada secreto, vaya a https://github.com/<your-GH-account>/<your-repo>/secrets/actions.

Con OpenID Connect, los flujos de trabajo pueden intercambiar tokens de corta duración directamente desde Azure.

Aunque OIDC se admite como el valor predeterminado para Acciones de GitHub y Azure Pipeline (con la opción federado), no se admite en Azure DevOps o Terraform.

• En Azure DevOps, al llamar explícitamente a --auth-type como federated, se producirá un error.
• En Terraform:
  • Si no se ha definido --auth-type, se revertirá a clientcredentials y se generará una advertencia.
  • Si --auth-type se pasa explícitamente a federated, se producirá un error.

Vaya a https://github.com/<your-GH-account>/<your-repo>settings/secrets/actions y luego actualice AZURE_CREDENTIALS copiando y pegando todo el objeto JSON de la nueva entidad de servicio. Por ejemplo:

{
  "clientId": "<GUID>",
  "clientSecret": "<GUID>",
  "subscriptionId": "<GUID>",
  "tenantId": "<GUID>",
  (...)
}

La ruta del archivo de Acciones de GitHub es <your-project-directory-name>\.github\workflows\azure-dev.yml.

Sí. Reemplace run: azd up --no-prompt por run: azd deploy --no-prompt.

Vaya a https://github.com/<your-GH-account>/<your-repo>/actions y luego consulte el archivo de registro en la ejecución del flujo de trabajo.

Al compilar aplicaciones contenedoras localmente, debe ejecutarse azd auth login en el contenedor para que la aplicación funcione con la AzureDeveloperCliCredential. También está la opción de configurar la aplicación para usar una entidad de servicio en lugar de la AzureDeveloperCliCredential.