FAQ sur l’interface CLI pour développeurs Azure

Il existe différentes options pour désinstaller azd en fonction de la façon dont vous l’avez installé à l’origine. Consultez la page d’installation pour plus d’informations.

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

azd se concentre sur le flux de travail des développeurs 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 les 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 a son propre ensemble de configurations, Azure Developer CLI stocke tous les fichiers de configuration dans les 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 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 de base de données et le point de terminaison Azure Key Vault.

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

1. Exécutez azd init -t <template repo> pour cloner 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 fonction secretOrRandomPassword 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 un mot de passe généré de manière aléatoire à utiliser à la place.

L’exemple suivant illustre un cas d’usage courant de l'secretOrRandomPassword dans un fichier main.parameters.json. Les variables ${AZURE_KEY_VAULT_NAME} et sqlAdminPassword 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 secretOrRandomPassword doit également être enregistrée dans Key Vault à l’aide de 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 référentiel GitHub de l’interface de ligne de commande azure développeur 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
  }
}]

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 fonction secretOrRandomPassword.
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 méthode secretOrRandomPassword 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.json dans le dossier infra. 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 azd provision pour les recréer avec le nouveau nom.

Ce nom doit être globalement unique. Sinon, vous recevrez une erreur ARM pendant azd provision lorsqu’il tente de créer la ressource.

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

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

Nous utilisons des modèles Bicep, qui se trouvent 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 à 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 Résoudre les erreurs courantes de déploiement Azure - Azure Resource Manager.

À venir. Cette fonctionnalité est prévue pour une prochaine version.

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, il énumère toutes les ressources de chacun de ces groupes de ressources, en recherchant une ressource marquée avec azd-service-name avec une valeur qui correspond au nom de votre service à partir de azure.yaml.

Bien que nous vous recommandons d’utiliser des balises sur des 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.

Lors du déploiement de votre projet, vous pouvez choisir de déployer des services spécifiques en spécifiant le nom du service dans la commande (par exemple, azd deploy api) ou en accédant à un sous-dossier qui contient uniquement le ou les services que vous souhaitez déployer. Dans ce cas, tous les autres services sont répertoriés en tant que - Skipped.

Si vous ne souhaitez pas ignorer les services, veillez à exécuter votre commande à partir du dossier racine ou à ajouter l’indicateur --all à votre commande.

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

À venir. Cette fonctionnalité est prévue pour une prochaine version.

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 commande azd pipeline config 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 flux de travail peuvent échanger des jetons de courte durée directement à partir d’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 explicite --auth-type en tant que federated entraîne une erreur.
• Pour Terraform :
  • Si --auth-type n’est pas définie, elle revient à clientcredentials et entraîne un avertissement.
  • Si --auth-type est explicitement défini sur federated, une erreur se produit.

Accédez à https://github.com/<your-GH-account>/<your-repo>settings/secrets/actions, puis mettez à jour 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 génération 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 utiliser un principal de service au lieu de la AzureDeveloperCliCredential.