FAQ sur Azure Developer CLI

Il existe différentes options de désinstallation azd en fonction de la façon dont vous l’avez installée à l’origine. Pour plus d’informations, consultez la page d’installation.

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

azd se concentre sur le flux de travail de développeur de haut niveau. Outre l’approvisionnement/la gestion des ressources Azure, azd permet de relier les composants cloud, la configuration du développement local et l’automatisation des pipelines dans une solution complète.

Azure CLI est un outil de plan de contrôle permettant de créer et d’administrer une infrastructure Azure telle que des machines virtuelles, des réseaux virtuels et du stockage. 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 différents 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 azd commandes font référence au fichier .env pour la configuration de l’environnement. Les commandes telles que azd deploy mettre à jour le fichier .env avec, par exemple, la base de données chaîne de connexion et le point de terminaison Azure Key Vault.

Oui. Vous pouvez continuer le travail de développement localement.

1. Exécutez pour cloner azd init -t <template repo> le projet de modèle sur votre ordinateur local.
2. Pour extraire l’env existante créée à l’aide de Codespaces, exécutez azd env refresh. Veillez à fournir le même nom d’environnement, l’abonnement et l’emplacement que précédemment.

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

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

L’exemple suivant illustre un cas d’usage courant du secretOrRandomPassword fichier.main.parameters.json Les ${AZURE_KEY_VAULT_NAME} variables et sqlAdminPassword les variables sont passées en tant que paramètres pour les noms du coffre de clés 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 doit également être enregistrée dans Key Vault à l’aide de secretOrRandomPassword Bicep pour les exécutions ultérieures. La récupération et la réutilisation des mêmes secrets entre les déploiements peuvent empêcher les erreurs ou les comportements inattendus qui peuvent apparaître lors de la génération répétée de nouvelles valeurs. Pour créer un coffre de clés et stocker le secret généré dans celui-ci, utilisez le code Bicep ci-dessous. Vous pouvez afficher l’exemple de code complet de ces modules dans le dépôt GitHub de l’interface de ligne de commande Azure Developer.

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 de Bicep active le flux de travail suivant pour la gestion de vos secrets :

1. Si le secret spécifié existe, il est récupéré à partir de Key Vault à l’aide de la secretOrRandomPassword fonction.
2. Si le secret n’existe pas, un coffre de clés est créé et le secret généré de manière aléatoire est stocké à l’intérieur de celui-ci.
3. Lors des déploiements futurs, la secretOrRandomPassword méthode récupère le secret stocké maintenant qu’il existe dans Key Vault. Le coffre de clés ne sera pas recréé s’il existe déjà, mais la même valeur secrète sera stockée à nouveau pour l’exécution suivante.

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

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 d’affectation de noms aux ressources.

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

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

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

Ce nom doit être globalement unique. Sinon, vous recevrez une erreur ARM lors azd provision de sa tentative de création de la ressource.

La commande utilise des modèles Bicep, qui sont trouvés sous <your-project-directory-name>/infra pour approvisionner des ressources Azure.

Accédez à https://portal.azure.com votre groupe de ressources, puis rg-<your-environment-name>recherchez votre groupe de ressources.

Nous utilisons des modèles Bicep, qui sont trouvés sous <your-project-directory-name>/infra, pour approvisionner des ressources Azure. En cas de problème, nous incluons le message d’erreur dans la sortie CLI.

Vous pouvez également accéder à votre groupe de ressources, c’est-à-dire https://portal.azure.comrg-<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 Résoudre les erreurs courantes de déploiement Azure - Azure Resource Manager.

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

Oui.

Pendant le déploiement, azd découvre d’abord tous les groupes de ressources qui composent votre application en recherchant des groupes marqués avec azd-env-name et avec une valeur qui correspond au nom de votre environnement. Ensuite, elle énumère toutes les ressources de chacun de ces groupes de ressources, en recherchant une ressource marquée avec azd-service-name une valeur qui correspond au nom de votre service à partir de azure.yaml.

Bien que nous vous recommandons d’utiliser des étiquettes sur les ressources, vous pouvez également utiliser la resourceName propriété pour azure.yaml 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émentiel.

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

Un principal de service Azure est une identité créée pour une utilisation avec des applications, des services hébergés et des outils automatisés pour 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 vous pouvez accéder et à quel niveau. Pour plus d’informations sur l’authentification d’Azure vers GitHub, consultez Connecter GitHub et Azure | Microsoft Docs.

Non. La azd pipeline config commande s’occupe de la création du principal de service Azure et de l’exécution des étapes nécessaires pour stocker les secrets dans votre dépôt 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 accédant à 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.

Bien que OIDC soit pris en charge comme valeur 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, l’appel --auth-typefederated explicite entraîne une erreur.
• Pour Terraform :
  • S’il --auth-type n’est pas défini, il revient clientcredentials et entraîne un avertissement.
  • S’il --auth-type est défini federatedexplicitement sur , cela entraîne une erreur.

Accédez à , puis mettez à https://github.com/<your-GH-account>/<your-repo>settings/secrets/actionsjour AZURE_CREDENTIALS en copiant et en collant l’intégralité de l’objet JSON pour le nouveau principal de service. Par exemple :

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

Le chemin du 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.

Accédez à https://github.com/<your-GH-account>/<your-repo>/actions, puis reportez-vous au fichier journal dans l’exécution du flux de travail.

Lors de la création d’applications conteneur localement, vous devez exécuter azd auth login dans le conteneur pour que l’application fonctionne avec le AzureDeveloperCliCredential. Vous pouvez également configurer votre application pour qu’elle utilise un principal de service au lieu du AzureDeveloperCliCredential.