Partage via

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

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 issues GitHub dans le répertoire GitHub de l’Azure Developer CLI.

Utilisation du --debug commutateur

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

azd up --debug

Vous pouvez également envoyer la sortie de débogage à un fichier texte local pour améliorer l’utilisation. Cette approche permet à d’autres systèmes de surveillance d’ingérer le débogage et peut également être utile lors du classement d’un problème sur GitHub.

Importante

Veillez à retirer 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"

Le 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 le jeton a 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 l’application Visual StudioOAuth ».

Solution

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

Les autorisations mises à jour du compte Azure ne se rafraîchissent pas 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é à d’autres abonnements, 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 en utilisant les 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 s'interrompre pendant des tâches longues, comme un déploiement prolongé. Assurez-vous que la session ne devient pas inactive. Consultez les limites d’utilisation de Cloud Shell.

Interface de 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é, la version de azd liée symboliquement dans ~/bin prend le pas sur la version de azd liée symboliquement dans /usr/local/bin.

Pour revenir à la version de azd 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 nécessitent la dernière version de l'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 une condition préalable pour l’installation et l’utilisation de 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 les suivantes :

  • « 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-<nom-de-votre-environnement>.

  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 à l’onglet Actions du dépôt GitHub concerné et examinez le fichier journal dans l’exécution du pipeline pour plus d’informations.

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

azd init Exige sudo

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

Cela provoque 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 afin de recréer le dossier avec les niveaux d’accès appropriés.

azd monitor pour un 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 fichier Dockerfile du modèle 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 résultats, 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 lorsque azd 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’une commande de hook 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 des commandes azd.

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

Erreur GitHub Actions - « N’a pas l’autorisation d’accès aux secrets sur un 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 incrémentielles des autorisations 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 textuel

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 les éléments suivants :

  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 :

    Capture d’écran montrant l’erreur reçue lors de l’exécution d’azd pipeline config avec AzDo pour Java sur 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

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

Dans certains cas, la mise à niveau de la version x86_64 de azd vers un binaire ARM64 peut entraîner des échecs pour les modèles qui ont été construits avec la version x86_64 de azd. Cela est dû au fait que le modèle utilise une version de v8-compile-cache qui peut essayer de charger le bytecode intégré sous x86_64 dans le 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 des stratégies d’accès conditionnel par votre abonné Microsoft Entra. La stratégie concernée vous impose d’être 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. Veillez à utiliser un appareil répertorié comme pris en charge, selon le 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.

Fichier Dockerfile mis en cache utilisé au lieu du fichier Dockerfile actuel

Lorsque vous utilisez azd dans votre environnement de développement local avec Docker, Docker peut utiliser la version mise en cache de votre fichier Dockerfile au lieu de la version actuelle. Cela entraîne le déploiement à l’aide d’un conteneur avec des informations incorrectes.

Solution

Pour configurer votre installation Docker locale, utilisée par Azure Developer CLI pour générer le conteneur, vous devez configurer Docker avec les variables d’environnement suivantes :

DOCKER_BUILDKIT=1
DOCKER_BUILD_ARGS="--no-cache"

Vous pouvez modifier vos azd up paramètres pour inclure ces paramètres :

DOCKER_BUILDKIT=1 DOCKER_BUILD_ARGS="--no-cache" azd up

azd pipeline config soutien

azd pipeline config n’est actuellement pas pris en charge dans les conteneurs distants DevContainers/VS Code.

Erreurs de la fonctionnalité de composition

La azd fonctionnalité de composition est disponible uniquement pour des types de projet spécifiques. Si vous essayez d’utiliser des commandes compose comme azd add ou azd infra gen dans un contexte non pris en charge, vous pouvez rencontrer les erreurs suivantes.

Projet incompatible

Si vous voyez un ERROR: incompatible project message lors de l’exécution de la azd add commande, vérifiez le type de projet avec lequel vous travaillez. La azd add commande n’est pas prise en charge pour les projets .NET Aspire ou pour azd les modèles qui ont déjà un infra dossier défini. La tentative d’utilisation azd add avec ces types de projet entraîne des erreurs telles que :

  • ERREUR : projet incompatible : hôte d’application Aspire trouvé

  • ERREUR : Projet incompatible : répertoire infrastructure détecté et azure.yaml sans ressources

    Capture d’écran montrant l’erreur de projet .NET Aspire incompatible.

    Capture d’écran montrant l’erreur d’infrastructure de projet incompatible.

Le projet ne contient pas l'infrastructure nécessaire pour générer

L’erreur ERROR: this project does not contain any infrastructure to generate se produit lorsque :

  • Vous exécutez azd infra gen sans ressources de composition définies dans votre projet.
  • Dans les projets Aspire .NET, cette erreur peut également apparaître si azd elle ne peut pas détecter un hôte d’application Aspire dans le répertoire actif.

Pour résoudre cette erreur, utilisez cette option azd add pour ajouter de nouvelles ressources avant d’exécuter azd infra gen ou de vérifier que votre projet Aspire .NET est structuré correctement.

Capture d’écran montrant l’erreur d’infrastructure.

Erreur lors de la résolution de la ressource Azure

La commande azd show <name> peut échouer avec l’erreur : ERROR: resolving '<name>': AZURE_RESOURCE_<NAME>_ID is not set as an output variable. Cela peut se produire pour plusieurs raisons :

  • La ressource <name> n'existe pas dans azure.yaml sous le nœud des ressources.
  • La ressource <name> n’a pas encore été provisionnée.

Capture d’écran montrant l’erreur de ressource Azure.

Solution

Exécutez azd up pour provisionner les ressources. Vous devrez peut-être d’abord exécuter azd infra gen pour générer le Bicep mis à jour, y compris la ressource <name>, puis exécuter azd up.

Prise en charge des métriques en temps réel pour Python

Les métriques actives (azd monitor --live) ne sont actuellement pas prises en charge pour les applications Python. Pour plus d’informations, consultez Métriques en direct : superviser et diagnostiquer avec une latence de 1 seconde.

Créer un problème GitHub pour demander de l’aide

Image du logo GitHub.

Azure Developer CLI et l’extension Azure Developer CLI Visual Studio Code utilisent GitHub Issues pour suivre les bogues et les demandes de fonctionnalités. Recherchez les problèmes existants avant de déposer de nouveaux problèmes pour éviter les doublons.

Pour obtenir de l’aide et des questions sur l’utilisation de ce projet, consultez notre wiki pour utiliser Azure Developer CLI et notre document CONTRIBUTING si vous souhaitez contribuer.

  • Last updated on