Partage via

Résoudre des problèmes liés à Azure Developer CLI

  • Article

Cet article fournit des solutions aux problèmes courants qui peuvent survenir lorsque vous utilisez Azure Developer CLI (azd).

Obtenir de l’aide et donner son avis

Si vous ne parvenez pas à trouver ce que vous recherchez dans cet article ou si vous souhaitez fournir des commentaires, vous pouvez publier des questions aux discussions de l’interface CLI pour développeurs Azure.

Vous pouvez également signaler des bogues en ouvrant des problèmes GitHub dans le dépôt GitHub de l’interface cli pour développeurs Azure.

Utilisation du --debug commutateur

Si vous rencontrez un problème inattendu lors de l’utilisation azd, réexécutez la commande avec le commutateur pour activer le débogage et la --debug sortie de diagnostic supplémentaires.

azd up --debug

Vous pouvez également envoyer la sortie de débogage à un fichier texte local pour améliorer l’utilisation. Cette approche permet aux informations de débogage d’être ingérées par d’autres systèmes de surveillance et peut également être utile lors du dépôt d’un problème sur GitHub.

Important

Veillez à réactez toutes les informations sensibles lors de l’envoi de journaux de débogage sur GitHub ou enregistrez-les dans d’autres systèmes de diagnostic.

azd deploy --debug > "<your-file-path>.txt"

Répertoire .azure

Azure Developer CLI part du principe que tous les répertoires stockés dans le .azure répertoire sont des environnements Azure Developer CLI. N’exécutez pas de commandes Azure Developer CLI à partir du répertoire d’accueil d’un utilisateur sur lequel Azure CLI est installé.

Non connecté à Azure ou au jeton expiré dans Visual Studio

Une fois que vous avez exécuté azd init -t <template-name> dans Visual Studio, vous obtenez l’erreur suivante : « Pour accéder à distance : ce référentiel, vous devez réauthoriser la Application OAuth lication Visual Studio».

Solution

Exécutez azd auth login pour actualiser le jeton d’accès.

Les autorisations de compte Azure mises à jour ne sont pas actualisées dans azd

Par défaut, azd met en cache vos informations d’identification et autorisations Azure. Si votre compte Azure reçoit de nouveaux rôles et autorisations, ou s’il est ajouté à des abonnements supplémentaires, ces modifications peuvent ne pas être immédiatement reflétées dans azd. Pour résoudre ce problème, déconnectez-vous, puis reconnectez-vous à azd l’aide des commandes suivantes :

azd auth logout

azd auth login

Suivez les invites de la azd auth login commande pour terminer le processus de connexion et mettre à jour vos informations d’identification mises en cache.

Limitations de Cloud Shell pour azd

Il existe certaines limitations à exécuter azd dans Cloud Shell :

Prise en charge de Docker dans Cloud Shell

Cloud Shell ne prend pas en charge l’exécution de docker build ou run de commandes, car le démon Docker n’est pas en cours d’exécution. Pour plus d’informations, consultez Résolution des problèmes de Cloud Shell.

Délai d’expiration cloud Shell

Cloud Shell peut expirer pendant un déploiement long ou d’autres tâches longues. Assurez-vous que la session ne devient pas inactive. Consultez les limites d’utilisation de Cloud Shell.

Interface Cloud Shell

Cloud Shell est principalement une interface de ligne de commande et a moins de fonctionnalités qu’un environnement de développement intégré comme Visual Studio Code.

Impossible de se connecter au démon Docker dans Cloud Shell

Cloud Shell utilise un conteneur pour héberger votre environnement shell, afin que les tâches nécessitant l’exécution du démon Docker ne soient pas autorisées.

Installer une autre version d’azd dans Cloud Shell

Dans certains cas, il peut être nécessaire d’installer une version différente de azd celle déjà utilisée dans Cloud Shell. Pour ce faire dans bash :

  1. Exécuter mkdir -p ~/bin pour vous assurer que le ~/bin dossier est présent
  2. Exécuter mkdir -p ~/azd pour vous assurer qu’un dossier local ~/azd est présent
  3. Exécuter curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --install-folder ~/azd --symlink-folder ~/bin --version <version> (<version> serait stable par défaut, mais une version publiée spécifique comme 1.0.0 peut également être spécifiée).

Une fois installée, la version d’un azd lien ~/bin symbolique est prioritaire sur la version de azd liaison symbolique dans /usr/local/bin.

Pour revenir à l’utilisation de azd la version déjà installée sur Cloud Shell dans bash :

  1. Exécutez rm ~/bin/azd
  2. Exécutez rm -rf ~/azd

Solution

Utilisez un autre hôte pour effectuer des tâches qui nécessitent le démon Docker. L’une des options consiste à utiliser docker-machine, comme décrit dans la documentation de résolution des problèmes de Cloud Shell.

Configuration requise pour Azure Bicep CLI

azd up et azd provision exiger la dernière version d’Azure Bicep CLI. Vous pouvez obtenir le message d’erreur suivant : « Erreur : échec de la compilation du modèle bicep : échec de l’exécution de la build bicep du module Az PowerShell : code de sortie : 1, stdout : , stderr : Avertissement : Une nouvelle version de Bicep est disponible : v0.4.1272 ».

Solution

Auparavant, Bicep était un preqrequisite pour l’installation et l’utilisation azd . azd installe désormais automatiquement Bicep dans l’étendue locale azd (pas globalement) et ce problème doit maintenant être résolu. Toutefois, si vous souhaitez utiliser une autre version, vous pouvez définir la variable d’environnement : AZD_BICEP_TOOL_PATH pour pointer vers l’emplacement de la version dont vous avez besoin.

azd up ou azd provision échoue

Les choses peuvent parfois aller mal avec azd up ou azd provision. Les erreurs courantes sont notamment :

  • « Impossible de provisionner certaines ressources dans une région Azure, car la région est hors capacité. »
  • « Le fournisseur de ressources approprié n’est pas présent dans cette région. »

Les étapes de résolution des problèmes peuvent différer en fonction de la cause racine.

Solution

  1. Accédez au portail Azure.

  2. Recherchez votre groupe de ressources, qui est rg-your-environment-name<>.

  3. Sélectionnez Déploiements pour obtenir plus d’informations.

  4. Vérifiez que vous avez spécifié un nom d’environnement identique à celui de votre nom d’environnement.

  5. Accédez à https://github.com/<your repo>/actions, puis reportez-vous au fichier journal dans l’exécution du pipeline pour plus d’informations.

Pour d’autres ressources, consultez Résoudre les erreurs courantes de déploiement Azure - Azure Resource Manager.

azd init nécessite sudo

Avant azd version = azure-dev-cli_0.2.0-beta.1, azd créez un .azd dossier avec drw-r--r-- accès.

Cela entraîne un problème, comme l’utilisation de cette version ou toute version antérieure sur n’importe quelle configuration Linux (WSL, ssh-remote, devcontainer, etc.) fournit déjà un .azd dossier en mode lecture seule.

Solution

  1. Supprimez manuellement le dossier déjà fourni .azd :

    rm -r ~/.azd

  2. Exécutez azd init pour azd créer à nouveau le dossier avec les niveaux d’accès appropriés.

azd monitor pour le conteneur de développement

azd monitor n’est actuellement pas pris en charge si vous utilisez un conteneur de développement comme environnement de développement.

Impossible de s’authentifier dans les environnements Codespaces

Si vous rencontrez des problèmes d’authentification dans Codespaces, vérifiez que le modèle Dockerfile inclut les sudo apt-get update && sudo apt-get install xdg-utils commandes. La xdg-utils commande ouvre un onglet de navigateur qui vous permet de vous connecter.

Static Web Apps ne parvient pas à déployer malgré le message de réussite

Un problème connu existe lors du déploiement sur Azure Static Web Apps dans lequel la sortie par défaut azd up peut indiquer que l’action a réussi, mais les modifications n’ont pas été réellement déployées. Vous pouvez diagnostiquer ce problème en exécutant la azd up commande avec l’indicateur --debug activé. Dans les journaux de sortie, vous pouvez voir le message suivant :

Preparing deployment. Please wait...
An unknown exception has occurred

Vous êtes le plus susceptible de rencontrer ce problème quand azd il est exécuté à partir d’une action GitHub. Pour contourner ce problème, après avoir créé votre site, copiez-le staticwebapp.config.json dans le dossier de build. Vous pouvez automatiser cette étape à l’aide d’un hook de commande de prépackage ou de prédéploiement, ce qui vous permet d’exécuter des scripts personnalisés à différents points dans les flux de travail de commande azd.

L’équipe produit travaille à résoudre ce problème.

Erreur GitHub Actions - « N’a pas d’autorisation d’obtention des secrets sur le coffre de clés »

Le partage du même nom d’environnement ou de groupe de ressources lors de l’approvisionnement de ressources localement et dans GitHub Actions peut générer l’erreur Does not have secrets get permission on key vault.. à partir du service Key Vault. Key Vault ne prend pas en charge les mises à jour des autorisations incrémentielles via Bicep, ce qui signifie efficacement que le flux de travail GitHub Actions remplace les autorisations de stratégie d’accès de l’utilisateur local.

La solution recommandée à ce problème consiste à utiliser des noms d’environnement distincts pour le développement local et les flux de travail GitHub Actions. En savoir plus sur l’utilisation de plusieurs environnements avec la azd env commande sur la page FAQ.

Prise en charge du navigateur basé sur du texte

Les navigateurs textuels ne sont actuellement pas pris en charge par azd monitor.

azd pipeline config utilisation de modèles AzDo pour Java sur Windows

Vous pouvez rencontrer un échec lors de l’exécution azd pipeline config avec AzDo pour les modèles Java sur Windows. Par exemple, vous avez :

  1. Exécutez ce qui suit sur Windows :

    azd init --template Azure-Samples/todo-java-mongo
azd pipeline config

  2. Nous avons reçu l’erreur suivante :

    Screenshot showing the error received when running azd pipeline config with AzDo for Java on Windows.

Solution

Il s’agit d’un problème connu. Pendant que nous avons résolu ce problème, essayez la commande suivante :

git update-index --chmod=+x src/api/mvnw && git commit -m "Fix executable bit permissions" && git push

failed packaging service 'api': failed invoking action 'package', failed to run NPM script build, signal: segmentation fault échec après la mise à niveau azd sur Apple Silicon (M1/M2)

Dans certains cas, la mise à niveau de la version x86_64 d’un azd binaire ARM64 peut entraîner des échecs pour les modèles qui ont été générés avec la version x86_64 de azd. Cela est dû au fait que le modèle utilise une version de laquelle peut essayer de v8-compile-cache charger le bytecode intégré sous x86_64 dans un processus ARM64.

Pour résoudre ce problème, mettez à niveau le v8-compile-cache package dans le projet concerné :

  1. Remplacez le répertoire par le service qui a échoué (src/api dans le cas de failed packaging service 'api')
  2. Exécutez npm upgrade v8-compile-cache
  3. Remplacez le répertoire par la racine du dépôt et réexécutez la azd commande (par exemple azd package , ou azd up)

azd pipeline config échec en raison d’une stratégie d’accès conditionnel

Lors de l’exécution azd pipeline config, vous pouvez recevoir une erreur semblable à ce qui suit :

ERROR: failed to create or update service principal: failed retrieving application list, failed executing request: http call(https://login.microsoftonline.com/common/oauth2/v2.0/token)(POST) error: reply status code was 400:
{"error":"invalid_grant","error_description":"AADSTS50005: User tried to log in to a device from a platform (Unknown) that's currently not supported through Conditional Access policy. Supported device platforms are: iOS, Android, Mac, and Windows flavors.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: 2022-12-16 21:10:37Z","error_codes":[50005],"timestamp":"2022-12-16 21:10:37Z","trace_id":"0000aaaa-11bb-cccc-dd22-eeeeee333333","correlation_id":"aaaa0000-bb11-2222-33cc-444444dddddd"}

Cette erreur est liée à l’activation de votre locataire Microsoft Entra des stratégies d’accès conditionnel. La stratégie spécifique nécessite que vous soyez connecté à une plateforme d’appareils prise en charge.

Vous recevez peut-être également cette erreur en raison d’une connexion à l’aide du mécanisme de code de l’appareil, ce qui empêche Microsoft Entra ID de détecter correctement votre plateforme d’appareil.

Solution

Pour configurer le workflow, vous devez accorder à GitHub l’autorisation de se déployer sur Azure en votre nom. Autoriser GitHub en créant un principal de service Azure stocké dans un secret GitHub nommé AZURE_CREDENTIALS. Sélectionnez votre hôte Codespace pour les étapes suivantes :

  1. Vérifiez que vous êtes en cours d’exécution sur un appareil répertorié comme pris en charge, conformément au message d’erreur.

  2. Réexécuter azd auth login avec l’indicateur --use-device-code=false ajouté :

    azd auth login --use-device-code=false

  3. Vous pouvez recevoir une erreur avec le message localhost refused to connect après vous être connecté. Si c’est le cas :

    1. Copiez l’URL.
    2. Exécutez curl '<pasted url>' (URL entre guillemets) dans un nouveau terminal Codespaces.

    Dans le terminal d’origine, la connexion doit maintenant réussir.

  4. Après la connexion, réexécutez azd pipeline config.