FAQ sur Azure Developer CLI

Il existe différentes options pour désinstaller azd en fonction de la manière dont vous l'avez installé à l'origine. Visitez la page d'installation pour plus de détails.

Azure Developer CLI (azd) et Azure CLI (az) sont tous deux des outils de ligne de commande, mais ils vous aident à effectuer des tâches différentes.

azd Azure CLI se concentre sur le workflow de haut niveau des développeurs. Outre l'approvisionnement et la gestion des ressources Azure, azd permet d'assembler les composants cloud, la configuration du développement local et l'automatisation du pipeline en une solution complète.

Azure CLI est un outil de plan de contrôle permettant de créer et d'administrer l'infrastructure Azure telle que les machines virtuelles, les réseaux virtuels et le stockage. L'Azure CLI est conçu autour de commandes granulaires pour des tâches administratives spécifiques.

Azure Developer CLI utilise un nom d’environnement pour définir la variable d’environnement AZURE_ENV_NAME utilisée par des modèles Azure Developer CLI. AZURE_ENV_NAME est également utilisé pour préfixer le nom du groupe de ressources Azure. Étant donné que chaque environnement dispose de son propre ensemble de configurations, Azure Developer CLI stocke tous les fichiers de configuration dans des répertoires d’environnement.

├── .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 

Oui. Vous pouvez configurer plusieurs environnements (par exemple, dev, test, production). Vous pouvez utiliser azd env pour gérer ces environnements.

Le chemin d’accès du fichier .env est <your-project-directory-name>\.azure\<your-environment-name>\.env.

Dans Azure Developer CLI, les commandes azd font référence au fichier .env pour la configuration de l'environnement. Les commandes telles que azd deploy mettent également à jour le fichier .env avec, par exemple, la chaîne de connexion db et le point de terminaison d'Azure Key Vault.

Oui. Vous pouvez poursuivre votre travail de développement localement.

1. Exécutez azd init -t <template repo> pour cloner le projet modèle sur votre machine locale.
2. Pour tirer vers le bas l'env existant créé à l'aide de Codespaces, exécutez azd env refresh. Assurez-vous de fournir le même nom d'environnement, le même abonnement et le même emplacement que précédemment.

Le fichier azure.yaml décrit les applications et les types de ressources Azure qui sont inclus dans le modèle.

La fonction secretOrRandomPassword récupère un secret à partir de Azure Key Vault si les paramètres du nom du coffre-fort et du secret sont fournis. Si ces paramètres ne sont pas fournis ou si un secret ne peut pas être récupéré, la fonction renverra un mot de passe généré de manière aléatoire à utiliser à la place.

L'exemple suivant illustre un cas d'utilisation courante du secretOrRandomPassword dans un fichier main.parameters.json. Les variables ${AZURE_KEY_VAULT_NAME} et sqlAdminPassword sont transmises en tant que paramètres pour les noms du Key Vault et du secret. Si la valeur ne peut pas être récupérée, un mot de passe aléatoire est généré à la place.

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

La sortie de secretOrRandomPassword doit également être enregistrée dans Key Vault à l'aide de Bicep pour les exécutions ultérieures. Le fait de récupérer et de réutiliser les mêmes secrets d'un déploiement à l'autre permet d'éviter les erreurs ou les comportements involontaires qui peuvent survenir lors de la génération répétée de nouvelles valeurs. Pour créer un Key Vault et y stocker le secret généré, utilisez le code Bicep ci-dessous. Vous pouvez consulter l'intégralité des exemples de code pour ces modules dans le référentiel GitHub Azure Developer CLI.

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
  }
}]

Cette configuration Bicep permet le workflow suivant pour la gestion de vos secrets :

1. Si le secret spécifié existe, il est extrait de Key Vault à l'aide de la fonction secretOrRandomPassword.
2. Si le secret n'existe pas, un Key Vault est créé et le secret généré aléatoirement est stocké à l'intérieur.
3. Lors des déploiements ultérieurs, la méthode secretOrRandomPassword récupère le secret stocké maintenant qu'il existe dans Key Vault. Le Key Vault ne sera pas recréé s'il existe déjà, mais la même valeur secrète sera à nouveau stockée pour la prochaine exécution.

Oui, mais chaque site Azure ne peut avoir qu'un seul déploiement. Si vous avez déjà utilisé l'emplacement Azure sélectionné, vous verrez l'erreur de déploiement :

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.

Vous pouvez sélectionner un autre emplacement Azure pour résoudre le problème.

Cela peut se produire en raison de notre méthode de dénomination des ressources.

Nos modèles créés par Azure Dev permettent de configurer le nom de la ressource. Pour ce faire, vous pouvez ajouter une entrée au dossier main.parameters.json dans le dossier infra. Par exemple :

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

Cette entrée crée une nouvelle ressource nommée « my-unique-name » au lieu d'une valeur aléatoire telle que « app-web-aj84u2adj » la prochaine fois que vous provisionnez votre application. Vous pouvez soit supprimer manuellement l'ancien groupe de ressources à l'aide du portail Azure, soit exécuter azd down pour supprimer tous les déploiements précédents. Après avoir supprimé les ressources, exécutez azd provision pour les créer à nouveau avec le nouveau nom.

Ce nom devra être globalement unique, sinon vous recevrez une erreur ARM pendant azd provision lorsqu'il tentera de créer la ressource.

La commande utilise les modèles Bicep, qui se trouvent sous <your-project-directory-name>/infra pour provisionner les ressources Azure.

Allez sur https://portal.azure.com puis cherchez votre groupe de ressources, qui est rg-<your-environment-name>.

Nous utilisons les modèles Bicep, qui se trouvent sous <your-project-directory-name>/infra, pour provisionner les ressources Azure. En cas de problème, nous incluons le message d'erreur dans la sortie CLI.

Vous pouvez également aller sur https://portal.azure.com puis rechercher votre groupe de ressources, qui est rg-<your-environment-name>. Si l'un des déploiements échoue, sélectionnez le lien d'erreur pour obtenir plus d'informations.

Pour d'autres ressources, consultez Dépannage des erreurs de déploiement Azure courantes - Azure Resource Manager.

Prochainement disponible. Cette fonctionnalité est prévue pour une version ultérieure.

Oui.

Lors du déploiement, azd découvre d'abord tous les groupes de ressources qui composent votre application en recherchant les groupes balisés avec azd-env-name et dont la valeur correspond au nom de votre environnement. Ensuite, il énumère toutes les ressources dans chacun de ces groupes de ressources, à la recherche d'une ressource balise azd-service-name dont la valeur correspond au nom de votre service de azure.yaml.

Bien que nous recommandions d'utiliser des balises sur les ressources, vous pouvez également utiliser la propriété resourceName dans azure.yaml pour fournir un nom de ressource explicite. Dans ce cas, la logique ci-dessus n'est pas exécutée.

Oui. Nous utilisons le mode de déploiement incrémental.

Prochainement disponible. Cette fonctionnalité est prévue pour une version ultérieure.

Un principal de service Azure est une identité créée pour être utilisée avec des applications, des services hébergés et des outils automatisés afin d'accéder aux ressources Azure. Cet accès est limité par les rôles attribués au principal de service, ce qui vous permet de contrôler les ressources auxquelles il est possible d'accéder et à quel niveau. Pour plus d'informations sur l'authentification entre Azure et GitHub, consultez la page Connecter GitHub et Azure sur Microsoft Docs.

Non. La commande azd pipeline config se charge de créer le principal de service Azure et d'effectuer les étapes nécessaires pour stocker les secrets dans votre référentiel GitHub.

La commande stocke quatre secrets dans GitHub : AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION et AZURE_SUBSCRIPTION_ID. Vous pouvez remplacer la valeur de chaque secret en allant sur https://github.com/<your-GH-account>/<your-repo>/secrets/actions.

Avec OpenID Connect, vos workflows peuvent échanger des jetons de courte durée directement depuis Azure.

Alors que OIDC est pris en charge par défaut pour GitHub Actions et Azure Pipeline (défini comme fédéré), il n'est pas pris en charge pour Azure DevOps ou Terraform.

• Pour Azure DevOps, appeler explicitement --auth-type en tant que federated entraînera une erreur.
• Pour Terraform :
  • Si --auth-type n'est pas défini, il reviendra à clientcredentials et donnera lieu à un avertissement.
  • Si --auth-type est explicitement défini comme federated, il en résultera une erreur.

Allez à https://github.com/<your-GH-account>/<your-repo>settings/secrets/actions, puis mettez à jour AZURE_CREDENTIALS en copiant et en collant l'objet JSON complet pour le nouveau principal de service. Par exemple :

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

Le chemin d'accès au fichier GitHub Actions est <your-project-directory-name>\.github\workflows\azure-dev.yml.

Oui. Remplacez run: azd up --no-prompt par run: azd deploy --no-prompt.

Rendez-vous à https://github.com/<your-GH-account>/<your-repo>/actions, puis reportez-vous au fichier journal de l'exécution du workflow.

Lorsque vous créez des applications conteneurisées localement, vous devez exécuter azd auth login dans le conteneur pour que l'application fonctionne avec AzureDeveloperCliCredential. Vous pouvez également configurer votre application de manière à ce qu'elle utilise un principal de service au lieu du AzureDeveloperCliCredential.