Preguntas más frecuentes sobre Azure Developer CLI

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, pero le 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.

Azure Developer CLI utiliza un nombre de entorno para establecer la variable de entorno AZURE_ENV_NAME que utilizan las plantillas de Azure Developer CLI. 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, Azure Developer CLI 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 varios entornos (por ejemplo, desarrollo, prueba, 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 azd comandos 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, el 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 archivo 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 secretOrRandomPassword función recupera un secreto de Azure Key Vault si se proporcionan parámetros para el nombre y el secreto del almacén de claves. Si estos parámetros no se proporcionan 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 muestra un caso de uso común de secretOrRandomPassword en un main.parameters.json archivo . Las ${AZURE_KEY_VAULT_NAME} variables y sqlAdminPassword se pasan como parámetros para los nombres de Key Vault y 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 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 especificado, se recupera de Key Vault mediante la secretOrRandomPassword función .
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 secretOrRandomPassword método 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 en la main.parameters.jsoninfra carpeta . 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 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 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 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 primero detecta 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 un valor que coincida con el nombre del servicio desde azure.yaml.

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

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

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

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 Conectar GitHub y Azure | Microsoft Docs.

No. El azd pipeline config comando 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 ni Terraform.

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

Vaya a y, a https://github.com/<your-GH-account>/<your-repo>settings/secrets/actionscontinuación, 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 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 y, a https://github.com/<your-GH-account>/<your-repo>/actionscontinuación, consulte el archivo de registro en la ejecución del flujo de trabajo.

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