Partager via

FAQ sur les outils CLI et l’environnement du développeur Azure

Cet article fournit des réponses aux questions fréquemment posées sur les outils, commandes et environnements Azure Developer CLI (azd).

Questions générales

La section suivante se concentre sur les questions générales azd concernant les outils et environnements.

Comment désinstaller Azure Developer CLI ?

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.

Quelle est la différence entre l'interface CLI Azure développeur et la Azure CLI ?

Azure CLI développeur (azd) et Azure CLI (az) sont les deux 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 Azure infrastructure, comme les machines virtuelles, les réseaux virtuels et le stockage. Le Azure CLI est conçu autour de commandes granulaires pour des tâches administratives spécifiques.

Pour plus d’informations, consultez Azure Developer CLI par rapport à Azure CLI.

Qu’est-ce qu’un nom d’environnement ?

Azure Developer CLI utilise un nom d'environnement pour définir la variable d'environnement AZURE_ENV_NAME utilisée par Azure modèles CLI développeur. 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 l’interface CLI développeur stocke tous les fichiers de configuration dans les répertoires d’environnement.

├── .Azure                          [This directory displays after you run `azd 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

Pour plus d’informations sur les flux de travail, consultez azd init et azd up.

Puis-je configurer plusieurs environnements ?

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

Où est stocké le fichier de configuration de l’environnement (.env) ?

Le chemin du fichier .env est <your-project-directory-name>\.azure\<your-environment-name>\.env. Pour plus d’informations, consultez Gérer les variables d’environnement.

Comment le fichier .env est-il utilisé ?

Dans Azure interface CLI développeur, 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 la base de données et le point de terminaison Azure Key Vault.

J’ai exécuté azd up dans Codespaces. Puis-je poursuivre mon travail dans un environnement de développement local ?

Yes. 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 supprimer l'environnement existant créé à 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.

Comment m’authentifier dans Codespaces si la connexion de l’appareil rencontre un problème ?

Si vous rencontrez des problèmes d’authentification par code d’appareil dans Codespaces (par exemple, des requêtes ou des erreurs périodiques 2FA), essayez la solution de contournement suivante à l’aide de VS Code Desktop :

  1. Ouvrez votre Codespace dans VS Code Desktop à l’aide de l’une des méthodes suivantes :
    • Utilisez la palette de commandes (Ctrl+Maj+P sur Windows ou Cmd+Maj+P sur MacOs) et sélectionnez Codespaces : Ouvrir dans VS Code Desktop.
    • Cliquez sur le coin inférieur gauche de Codespace dans le navigateur, puis sélectionnez Ouvrir dans VS Code Desktop).
  2. Dans le terminal VS Code Desktop, exécutez azd auth login et complétez l'authentification via le navigateur.
  3. Une fois authentifié, fermez VS Code Desktop et revenez à votre espace de code dans le navigateur. L’état d’authentification doit être conservé.

Comment le fichier azure.yaml est-il utilisé ?

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

Quel est le comportement de la secretOrRandomPassword fonction ?

La fonction secretOrRandomPassword récupère un secret à partir de 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 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. 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 Key Vault 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 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 active le flux de travail suivant pour gérer 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 Key Vault 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 Key Vault 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.

Puis-je utiliser Azure abonnement gratuit ?

Oui, mais chaque emplacement Azure ne peut avoir qu’un seul déploiement. Si vous avez déjà utilisé l'emplacement de 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.

Mon application hébergée avec Azure App Service déclenche un avertissement « Site trompeur à venir ». Comment puis-je le corriger ?

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.

Puis-je travailler avec plusieurs locataires Azure ?

Yes. Pour vous authentifier auprès d’un locataire spécifique, utilisez le --tenant-id paramètre avec la azd auth login commande.

azd auth login --tenant-id <tenant-id>

Sinon, si vous souhaitez azd avoir accès à tous vos locataires, vous pouvez gérer les défis MFA (Multi-Factor Authentication) dans le navigateur en premier :

  1. Ouvrez le Azure Portal dans votre navigateur.
  2. Basculez vers chacun de vos locataires un par un. Cette action déclenche tous les défis MFA nécessaires et actualise vos jetons.
  3. Exécutez azd auth login dans votre terminal. azd utilisera la session et les jetons d’accès existants du navigateur, qui sont désormais valides pour tous les locataires que vous avez visités.

Puis-je exécuter azd up plusieurs fois ?

Yes. Nous utilisons le mode de déploiement incrémentiel . Pour plus d’informations, consultez azd up.

Provisioning

La section suivante se concentre sur le processus d’approvisionnement azd .

Puis-je exécuter azd provision plusieurs fois ?

Yes. Nous utilisons le mode de déploiement incrémentiel . Pour plus d’informations, consultez azd provision.

Comment la azd provision commande sait-elle quelles ressources approvisionner ?

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

Où puis-je trouver les ressources approvisionnées dans Azure ?

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

Comment trouver plus d’informations sur les erreurs de Azure ?

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 de déploiement Azure courantes - Azure Resource Manager.

Existe-t-il un fichier journal pour azd provision?

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

Déploiement

La section suivante se concentre sur le processus de déploiement azd.

Puis-je exécuter azd deploy plusieurs fois ?

Yes. Pour plus d’informations, consultez azd deploy .

Comment azd trouve-t-il la ressource Azure pour déployer mon code ?

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 les ressources, vous pouvez également utiliser la resourceName propriété dans azure.yaml pour fournir un nom de ressource explicite. Dans ce cas, la logique ci-dessus n’est pas exécutée.

Comment déployer des services spécifiques dans mon projet tout en ignorant d’autres ?

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.

Configuration du pipeline

La section suivante met l’accent sur la configuration du pipeline CI/CD.

Qu’est-ce qu’un principal de service Azure ?

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 permettant 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 vous pouvez accéder et à quel niveau. Pour plus d’informations sur l’authentification de Azure à GitHub, consultez Connect GitHub et Azure | Microsoft Docs.

Dois-je créer un principal de service Azure avant d’exécuter azd pipeline config ?

Non. La commande azd pipeline config s’occupe de créer le principal de service Azure et d’effectuer les étapes nécessaires pour stocker les secrets dans votre dépôt GitHub.

Quels sont tous les secrets stockés dans 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-github-account>/<your-repo>/secrets/actions.

Qu’est-ce qu’OpenID Connect (OIDC) et est-il pris en charge ?

Avec OpenID Connect, vos flux de travail peuvent échanger des jetons de courte durée directement à partir de Azure.

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

  • Pour Azure DevOps, l’appel explicite --auth-type comme 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.

Comment réinitialiser le principal de service Azure stocké dans GitHub Actions ?

Accédez à https://github.com/<your-github-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>",
(...)
}

Où est stocké le fichier GitHub Actions ?

Le chemin du fichier GitHub Actions est <your-project-directory-name>\.github\workflows\azure-dev.yml. Pour plus d’informations, consultez Quickstart : Créer un principal de service et exécuter une action de GitHub.

Dans le fichier azure-dev.yml, puis-je déployer uniquement le code à l’étape de génération ?

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

Où puis-je trouver le journal du travail de GitHub Actions que j’ai déclenché quand j’ai exécuté azd pipeline config ?

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

Génération d’une application conteneur localement

Pourquoi suis-je incapable d’exécuter localement l’application conteneur que je crée ?

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.

  • Last updated on