Felsöka Azure Developer CLI

  • Artikel

Den här artikeln innehåller lösningar på vanliga problem som kan uppstå när du använder Azure Developer CLI (azd).

Få hjälp och ge feedback

Om du inte hittar det du letar efter i den här artikeln eller om du vill ge feedback kan du skicka frågor till Azure Developer CLI-diskussioner.

Du kan också rapportera buggar genom att öppna GitHub-problem på Azure Developer CLI GitHub-lagringsplatsen.

Använda växeln --debug

Om du stöter på ett oväntat problem när du arbetar med azdkör du kommandot igen med växeln --debug för att aktivera ytterligare felsökning och diagnostiska utdata.

azd up --debug

Du kan också skicka felsökningsutdata till en lokal textfil för bättre användbarhet. Med den här metoden kan felsökningsinformationen matas in av andra övervakningssystem och kan också vara användbar när du skickar in ett problem på GitHub.

Viktigt!

Se till att redigera känslig information när du skickar felsökningsloggar på GitHub eller sparar dem i andra diagnostiksystem.

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

Katalogen .azure

Azure Developer CLI förutsätter att alla kataloger som lagras i .azure katalogen är Azure Developer CLI-miljöer. Kör inte Azure Developer CLI-kommandon från hemkatalogen för en användare som har Azure CLI installerat.

Inte inloggad i Azure eller token har upphört att gälla i Visual Studio

När du har kört azd init -t <template-name> i Visual Studio får du följande fel: "Om du vill komma åt fjärrlagringsplatsen: den här lagringsplatsen måste du auktorisera OAuth-programmet Visual Studioigen."

Lösning

Kör azd auth login för att uppdatera åtkomsttoken.

Uppdaterade Azure-kontobehörigheter uppdateras inte i azd

Som standard azd cachelagrar dina autentiseringsuppgifter och behörigheter för Azure. Om ditt Azure-konto tilldelas nya roller och behörigheter, eller läggs till i ytterligare prenumerationer, kanske dessa ändringar inte återspeglas omedelbart i azd. Lös problemet genom att logga ut och sedan logga in igen med azd hjälp av följande kommandon:

azd auth logout

azd auth login

Följ anvisningarna från azd auth login kommandot för att slutföra inloggningsprocessen och uppdatera dina cachelagrade autentiseringsuppgifter.

Cloud Shell-begränsningar för azd

Det finns vissa begränsningar för att köra azd i Cloud Shell:

Docker-stöd i Cloud Shell

Cloud Shell har inte stöd för att köra docker build eller run kommandon eftersom docker-daemonen inte körs. Mer information finns i Cloud Shell-felsökning.

Tidsgräns för Cloud Shell

Cloud Shell kan överskrida tidsgränsen under en lång distribution eller andra tidskrävande uppgifter. Kontrollera att sessionen inte blir inaktiv. Se Användningsgränser för Cloud Shell.

Cloud Shell-gränssnitt

Cloud Shell är främst ett kommandoradsgränssnitt och har färre funktioner än en integrerad utvecklingsmiljö som Visual Studio Code.

Det går inte att ansluta till Docker-daemonen i Cloud Shell

Cloud Shell använder en container som värd för din gränssnittsmiljö, så uppgifter som kräver att docker-daemon körs tillåts inte.

Installera en annan version av azd i Cloud Shell

I vissa fall kan det vara nödvändigt att installera en annan version av azd än den version som redan används i Cloud Shell. Så här gör du i bash:

  1. Kör mkdir -p ~/bin för att se till att ~/bin mappen finns
  2. Kör mkdir -p ~/azd för att säkerställa att en lokal ~/azd mapp finns
  3. Kör curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --install-folder ~/azd --symlink-folder ~/bin --version <version> (<version> skulle vara stable som standard men en specifik version som 1.0.0 kan också anges).

När den har installerats har den symboliskt länkade ~/bin versionen azd företräde framför den symboliskt länkade versionen azd i /usr/local/bin.

Så här återgår du till att använda den version av azd som redan har installerats på Cloud Shell i bash:

  1. Kör rm ~/bin/azd
  2. Kör rm -rf ~/azd

Lösning

Använd en annan värd för att utföra uppgifter som kräver docker-daemon. Ett alternativ är att använda docker-machine enligt beskrivningen i dokumentationen för Cloud Shell-felsökning .

Azure Bicep CLI-krav

azd up och azd provision kräver den senaste versionen av Azure Bicep CLI. Du kan få följande felmeddelande: "Fel: det gick inte att kompilera bicep-mallen: Det gick inte att köra Az PowerShell-modulen bicep build: exit code: 1, stdout: , stderr: WARNING: En ny Bicep-version är tillgänglig: v0.4.1272."

Lösning

Tidigare var Bicep en förutsättning för att installera och använda azd . azd installerar nu automatiskt Bicep inom det lokala azd omfånget (inte globalt) och det här problemet bör nu lösas. Men om du vill använda en annan version kan du ange miljövariabeln: AZD_BICEP_TOOL_PATH så att den pekar på platsen för den version du behöver.

azd up eller azd provision misslyckas

Saker kan ibland gå snett med azd up eller azd provision. Vanliga fel är:

  • "Det går inte att etablera vissa resurser i en Azure-region eftersom regionen har slut på kapacitet."
  • "Relevant resursprovider finns inte i den regionen."

Felsökningsstegen kan variera beroende på rotorsaken.

Lösning

  1. Gå till Azure-portalen.

  2. Leta upp resursgruppen, som är rg-your-environment-name<>.

  3. Välj Distributioner för att få mer information.

  4. Kontrollera att du har angett ett miljönamn som är samma som ditt miljönamn.

  5. Gå till https://github.com/<your repo>/actionsoch referera sedan till loggfilen i pipelinekörningen för mer information.

Andra resurser finns i Felsöka vanliga Azure-distributionsfel – Azure Resource Manager.

azd init Kräver sudo

azd Före azd version = azure-dev-cli_0.2.0-beta.1skulle skapa en .azd mapp med drw-r--r-- åtkomst.

Detta orsakar ett problem, eftersom användning av den här eller någon tidigare version på alla Linux-konfigurationer (WSL, ssh-remote, devcontainer osv.) redan tillhandahåller en .azd mapp med skrivskyddat läge.

Lösning

  1. Ta bort den redan angivna .azd mappen manuellt:

    rm -r ~/.azd

  2. Kör azd init för för azd att skapa mappen igen med rätt åtkomstnivåer.

azd monitor för utvecklingscontainer

azd monitor stöds för närvarande inte om du använder en utvecklingscontainer som utvecklingsmiljö.

Det går inte att autentisera i Codespaces-miljöer

Om du har autentiseringsproblem i Codespaces kontrollerar du att dockerfile-mallen sudo apt-get update && sudo apt-get install xdg-utils innehåller kommandona. Kommandot xdg-utils öppnar en webbläsarflik som gör att du kan logga in.

Static Web Apps kan inte distribueras trots lyckat meddelande

Det finns ett känt problem när du distribuerar till Azure Static Web Apps där standardutdata azd up kan ange att åtgärden lyckades, men ändringarna har inte distribuerats. Du kan diagnostisera det här problemet genom att azd up köra kommandot med --debug flaggan aktiverad. I utdataloggarna kan följande meddelande visas:

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

Det är troligt att du stöter på det här problemet när azd det körs från en GitHub-åtgärd. Som en lösning kopierar staticwebapp.config.json du till byggmappen när du har skapat din webbplats. Du kan automatisera det här steget genom att använda en förpaketerings- eller fördistribueringskommandokrok, som gör att du kan köra anpassade skript på olika platser i azd-kommandoarbetsflödena.

Produktteamet arbetar med att lösa det här problemet.

GitHub Actions-fel – "Har inte behörighet att hämta hemligheter i nyckelvalvet"

Om du delar samma miljö eller resursgruppsnamn när du etablerar resurser lokalt och i GitHub Actions kan felet Does not have secrets get permission on key vault.. uppstå från Key Vault-tjänsten. Key Vault stöder inte inkrementella behörighetsuppdateringar via Bicep, vilket i praktiken innebär att GitHub Actions-arbetsflödet skriver över behörigheterna för åtkomstprincip för den lokala användaren.

Den rekommenderade lösningen på det här problemet är att använda separata miljönamn för lokal utveckling och GitHub Actions-arbetsflöden. Läs mer om hur du använder flera miljöer med azd env kommandot på sidan Vanliga frågor och svar.

Stöd för textbaserade webbläsare

Textbaserade webbläsare stöds för närvarande inte av azd monitor.

azd pipeline config använda AzDo för Java-mallar i Windows

Du kan stöta på ett fel när du kör azd pipeline config med AzDo för Java-mallar i Windows. Du har till exempel:

  1. Kör följande i Windows:

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

  2. Följande fel har mottagits:

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

Lösning

Detta är ett känt problem. Försök med följande kommando när vi åtgärdar det här problemet:

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 fel efter uppgradering azd på Apple Silicon (M1/M2)

I vissa fall kan uppgradering från den x86_64 versionen av azd till en ARM64-binär fil resultera i fel för mallar som har skapats med den x86_64 versionen av azd. Det beror på att mallen använder en version som v8-compile-cache kan försöka läsa in bytekod som skapats under x86_64 till en ARM64-process.

Åtgärda problemet genom att v8-compile-cache uppgradera paketet i det berörda projektet:

  1. Ändra katalog till den tjänst som misslyckades (src/api om det gäller failed packaging service 'api')
  2. Kör npm upgrade v8-compile-cache
  3. Ändra katalogen till lagringsplatsens rot och kör azd kommandot (t.ex. azd package eller azd up) igen

azd pipeline config fel på grund av princip för villkorsstyrd åtkomst

När du kör azd pipeline configkan du få ett felmeddelande som liknar följande:

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: be3438c1-42fc-4c37-96d8-0e723ac54f01\r\nCorrelation ID: f535565f-9f3c-4014-ad65-403f514bf892\r\nTimestamp: 2022-12-16 21:10:37Z","error_codes":[50005],"timestamp":"2022-12-16 21:10:37Z","trace_id":"be3438c1-42fc-4c37-96d8-0e723ac54f01","correlation_id":"f535565f-9f3c-4014-ad65-403f514bf892"}

Det här felet gäller aktivering av principer för villkorsstyrd åtkomst i Microsoft Entra-klientorganisationen. Den specifika principen kräver att du är inloggad på en enhetsplattform som stöds.

Du kan också få det här felet på grund av att du har loggat in med hjälp av mekanismen för enhetskod, vilket hindrar Microsoft Entra-ID från att identifiera din enhetsplattform korrekt.

Lösning

För att konfigurera arbetsflödet måste du ge GitHub behörighet att distribuera till Azure för din räkning. Auktorisera GitHub genom att skapa ett Azure Service Principal som lagras i en GitHub-hemlighet med namnet AZURE_CREDENTIALS. Välj din Codespace-värd för steg:

  1. Kontrollera att du kör på en enhet som anges som stöds enligt felmeddelandet.

  2. azd auth login Kör igen med flaggan --use-device-code=false bifogad:

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

  3. Du kan få ett felmeddelande när localhost refused to connect du har loggat in. I så fall:

    1. Kopiera URL.
    2. Kör curl '<pasted url>' (URL med citattecken) i en ny Codespaces-terminal.

    I den ursprungliga terminalen ska inloggningen nu lyckas.

  4. När du har loggat in kör azd pipeline configdu igen .