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 de para obtener más información.

de la CLI para desarrolladores de Azure (azd) y cli de Azure (az) son herramientas de línea de comandos, pero ayudan a realizar diferentes tareas.

azd se centra en el flujo de trabajo de desarrollador de alto nivel. Además de aprovisionar o administrar recursos de Azure, azd ayuda a unir componentes en la nube, configuración de desarrollo local y 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 para tareas administrativas específicas.

La CLI para desarrolladores de Azure usa un nombre de entorno para establecer la variable de entorno AZURE_ENV_NAME que usan las plantillas de la CLI para desarrolladores de Azure. AZURE_ENV_NAME también se usa para prefijar 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 los 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 varios entornos (por ejemplo, desarrollo, prueba, producción). Puede usar azd env para administrar estos entornos.

La ruta de acceso 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 para la configuración del entorno. Los comandos como azd deploy también actualizan el archivo .env con, por ejemplo, la cadena de conexión de base de datos y el punto de conexión de Azure Key Vault.

Sí. Puede continuar el trabajo de desarrollo localmente.

1. Ejecute azd init -t <template repo> para clonar el proyecto de plantilla en la máquina local.
2. Para extraer el objeto env existente creado mediante Codespaces, ejecute azd env refresh. Asegúrese de proporcionar 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 proporcionan parámetros para el nombre y el secreto del almacén de claves. Si no se proporcionan estos parámetros o no se puede recuperar un secreto, la función devuelve una contraseña generada aleatoriamente para usarla.

En el ejemplo siguiente se muestra un caso de uso común del secretOrRandomPassword en un archivo main.parameters.json. Las variables ${AZURE_KEY_VAULT_NAME} y sqlAdminPassword se pasan como parámetros para los nombres de Key Vault y el 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)"
  } 

La salida de secretOrRandomPassword también debe guardarse en Key Vault mediante Bicep para futuras ejecuciones. La recuperación y reutilización de los mismos secretos entre implementaciones puede evitar errores o comportamientos 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 de GitHub de la CLI de Azure Developer de .

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 especificado, se recupera de Key Vault mediante la función secretOrRandomPassword.
2. Si el secreto no existe, se crea una instancia de Key Vault y el secreto generado aleatoriamente se almacena dentro de él.
3. En futuras implementaciones, el método secretOrRandomPassword recupera el secreto almacenado ahora que existe en Key Vault. Key Vault no se volverá a crear si ya existe, pero el mismo valor secreto se almacenará de nuevo para 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, verá el 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 ocurrir debido 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 a la 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 quitar manualmente el grupo de recursos antiguo mediante Azure Portal o ejecutar azd down para quitar todas las implementaciones anteriores. Después de quitar los recursos, ejecute azd provision para crearlos de nuevo con el nuevo nombre.

Este nombre tendrá que 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 la salida de 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 de error para obtener más información.

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

Próximamente. Esta característica está planeada para una versión futura.

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 de su entorno. A continuación, 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 de azure.yaml.

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

Al implementar el proyecto, puede optar por implementar servicios específicos especificando el nombre del servicio en el comando (es decir, azd deploy api) o navegando a una subcarpeta que contenga solo los servicios que desea implementar. Al hacerlo, todos los demás servicios se mostrarán como - Skipped.

Si no desea omitir ningún servicio, asegúrese de ejecutar el comando desde la carpeta raíz o de agregar la marca --all al comando.

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

Próximamente. Esta característica está planeada para una versión futura.

Una entidad de servicio de Azure es una identidad que se crea para su uso con aplicaciones, servicios hospedados y herramientas automatizadas para acceder a los recursos de Azure. Este acceso está restringido por los roles asignados a la entidad de servicio, lo que le proporciona control sobre qué recursos se puede acceder y en qué nivel. Para más información sobre la autenticación desde Azure a GitHub, consulte Connect 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 valor predeterminado para Acciones de GitHub y Azure Pipeline (establecido como federado), no se admite para Azure DevOps o Terraform.

• Para Azure DevOps, al llamar explícitamente --auth-type como federated se producirá un error.
• Para Terraform:
  • Si no se define --auth-type, se revertirá a clientcredentials y generará una advertencia.
  • Si --auth-type se establece explícitamente en federated, se producirá un error.

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

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

La ruta de acceso 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>/actionsy, a continuación, consulte el archivo de registro en la ejecución del flujo de trabajo.

Al compilar aplicaciones contenedora localmente, debe ejecutar azd auth login en el contenedor para que la aplicación funcione con el AzureDeveloperCliCredential. Como alternativa, puede configurar la aplicación para que use una entidad de servicio en lugar de la AzureDeveloperCliCredential.