Řešení potíží s Azure Developer CLI

Tento článek obsahuje řešení běžných problémů, ke kterým může dojít, když používáte Azure Developer CLI (azd).

Získání pomoci a poskytnutí zpětné vazby

Pokud v tomto článku nemůžete najít, co hledáte, nebo chcete poskytnout zpětnou vazbu, můžete do diskuzí v Azure Developer CLI publikovat otázky.

Chyby můžete také hlásit tak, že otevřete Problémy GitHubu v úložišti Azure Developer CLI na GitHubu.

--debug Použití přepínače

Pokud při práci azdnarazíte na neočekávaný problém, spusťte příkaz znovu s --debug přepínačem a povolte další ladění a diagnostický výstup.

azd up --debug

Můžete také odeslat výstup ladění do místního textového souboru, aby se zlepšila použitelnost. Tento přístup umožňuje ingestování informací o ladění jinými monitorovacími systémy a může být také užitečné při vytváření problému na GitHubu.

Důležité

Při odesílání protokolů ladění na GitHubu nezapomeňte všechny citlivé informace znovu upravit nebo je uložit do jiných diagnostických systémů.

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

Adresář .azure

Azure Developer CLI předpokládá, že všechny adresáře uložené v .azure adresáři jsou prostředí Azure Developer CLI. Nespousívejte příkazy Azure Developer CLI z domovského adresáře uživatele, který má nainstalované Rozhraní příkazového řádku Azure CLI.

V sadě Visual Studio nevypršela platnost přihlášení k Azure nebo tokenu

Po spuštění azd init -t <template-name> v sadě Visual Studio se zobrazí následující chyba: "Přístup ke vzdálenému úložišti: toto úložiště je nutné znovu ověřit aplikaci Visual StudioOAuth."

Řešení

Spusťte azd auth login aktualizaci přístupového tokenu.

Aktualizovaná oprávnění účtu Azure se neaktualizují v azd

Ve výchozím nastavení azd ukládá vaše přihlašovací údaje a oprávnění Azure do mezipaměti. Pokud je vašemu účtu Azure přiřazeny nové role a oprávnění nebo se přidají do dalších předplatných, nemusí se tyto změny okamžitě promítnout do azd. Pokud chcete tento problém vyřešit, odhlaste se a pak se znovu přihlaste pomocí azd následujících příkazů:

azd auth logout

azd auth login

Podle pokynů z azd auth login příkazu dokončete proces přihlášení a aktualizujte přihlašovací údaje uložené v mezipaměti.

Omezení Cloud Shellu pro azd

V Cloud Shellu azd platí určitá omezení:

Podpora Dockeru v Cloud Shellu

Cloud Shell nepodporuje spouštění dockeru build nebo run příkazů, protože démon Dockeru není spuštěný. Další informace najdete v tématu Řešení potíží s Cloud Shellem.

Časový limit Cloud Shellu

Cloud Shell může během dlouhého nasazení nebo jiných dlouhotrvajících úloh časový limit časového limitu. Ujistěte se, že relace není nečinná. Viz omezení využití Cloud Shellu.

Rozhraní Cloud Shellu

Cloud Shell je primárně rozhraní příkazového řádku a bude mít méně funkcí než integrované vývojové prostředí, jako je Visual Studio Code.

Nejde se připojit k démonu Dockeru v Cloud Shellu

Cloud Shell používá k hostování prostředí kontejner, takže úlohy, které vyžadují spuštění démona Dockeru, nejsou povolené.

Instalace jiné verze AZD v Cloud Shellu

V některých případech může být nutné nainstalovat jinou verzi azd , než je verze, která se už používá v Cloud Shellu. Postup v Bash:

  1. Spusťte, mkdir -p ~/bin abyste měli jistotu ~/bin , že složka existuje.
  2. Spusťte a ujistěte mkdir -p ~/azd se, že je k dispozici místní ~/azd složka.
  3. Spustit curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --install-folder ~/azd --symlink-folder ~/bin --version <version> (<version> ve výchozím nastavení by bylo stable možné zadat také konkrétní vydanou verzi 1.0.0 ).

Po instalaci bude mít verze symbolicky propojených azd in ~/bin přednost před verzí symbolicky propojených azd v /usr/local/bin.

Pokud se chcete vrátit k používání verze azd už nainstalované v Cloud Shellu v Bash:

  1. Spuštěním příkazu rm ~/bin/azd
  2. Spuštěním příkazu rm -rf ~/azd

Řešení

K provádění úloh, které vyžadují démona Dockeru, použijte jiného hostitele. Jednou z možností je použít docker-machine, jak je popsáno v dokumentaci k řešení potíží s Cloud Shellem .

Požadavek rozhraní příkazového řádku Azure Bicep

azd up a azd provision vyžadovat nejnovější verzi Rozhraní příkazového řádku Azure Bicep. Může se zobrazit následující chybová zpráva: Chyba: Nepodařilo se zkompilovat šablonu bicep: spuštění sestavení bicep modulu Az PowerShell: exit code: 1, stdout: , stderr: WARNING: Nová verze Bicep je k dispozici: v0.4.1272."

Řešení

Dříve byl Bicep preqrequisite pro instalaci a použití azd . azd Teď automaticky nainstaluje Bicep do místního azd oboru (ne globálně) a tento problém by se teď měl vyřešit. Pokud ale chcete použít jinou verzi, můžete proměnnou prostředí nastavit tak AZD_BICEP_TOOL_PATH , aby odkazovat na umístění verze, kterou potřebujete.

azd up nebo azd provision selže

Věci se někdy můžou přepsat azd up nebo azd provision. Mezi běžné chyby patří:

  • V oblasti Azure nejde zřídit určité prostředky, protože oblast je mimo kapacitu.
  • V této oblasti není k dispozici relevantní poskytovatel prostředků.

Postup řešení potíží se může lišit v závislosti na původní příčině.

Řešení

  1. Přejděte na Azure Portal.

  2. Vyhledejte skupinu prostředků, což je rg-your-environment-name<>.

  3. Další informace získáte výběrem možnosti Nasazení .

  4. Ověřte, že jste zadali název prostředí, který je stejný jako název vašeho prostředí.

  5. Přejděte do https://github.com/<your repo>/actionsčásti a pak se podívejte na soubor protokolu ve spuštění kanálu, kde najdete další informace.

Další prostředky najdete v tématu Řešení běžných chyb nasazení Azure – Azure Resource Manager.

azd init Vyžaduje sudo

azd Předtím azd version = azure-dev-cli_0.2.0-beta.1byste vytvořili .azd složku s drw-r--r-- přístupem.

To způsobí problém, protože použití této nebo jakékoli předchozí verze v jakémkoli nastavení Linuxu (WSL, ssh-remote, devcontainer atd.) již poskytuje .azd složku s režimem jen pro čtení.

Řešení

  1. Ručně odstraňte již zadanou .azd složku:

    rm -r ~/.azd
    
  2. Spusťte azd init příkaz pro azd opětovné vytvoření složky se správnými úrovněmi přístupu.

azd monitor pro vývojový kontejner

azd monitor v současné době se nepodporuje, pokud jako vývojové prostředí používáte vývojový kontejner.

V prostředích Codespaces nejde provést ověření

Pokud v Codespaces dochází k problémům s ověřováním, ujistěte se, že šablona Dockerfile obsahuje sudo apt-get update && sudo apt-get install xdg-utils příkazy. Příkaz xdg-utils otevře kartu prohlížeče, která umožňuje přihlášení.

Statické webové aplikace se nepovedlo nasadit bez ohledu na zprávu o úspěchu

Při nasazování do Azure Static Web Apps existuje známý problém, ve kterém může výchozí azd up výstup uvést, že akce byla úspěšná, ale změny se ve skutečnosti nenasadily. Tento problém můžete diagnostikovat spuštěním azd up příkazu s povoleným příznakem --debug . Ve výstupních protokolech se může zobrazit následující zpráva:

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

S největší pravděpodobností narazíte na tento problém při azd spuštění z akce GitHubu. Alternativním řešením je, že po sestavení webu zkopírujte staticwebapp.config.json do složky buildu. Tento krok můžete automatizovat pomocí předpřipraveného nebo předem připraveného háku příkazů, který umožňuje spouštět vlastní skripty v různých bodech v pracovních postupech příkazů azd.

Produktový tým pracuje na vyřešení tohoto problému.

Chyba GitHub Actions – Nemá oprávnění k získání tajných kódů pro trezor klíčů

Sdílení stejného prostředí nebo názvu skupiny prostředků při místním zřizování prostředků a v GitHub Actions může způsobit chybu Does not have secrets get permission on key vault.. ze služby Key Vault. Key Vault nepodporuje přírůstkové aktualizace oprávnění prostřednictvím Bicep, což znamená, že pracovní postup GitHub Actions přepíše oprávnění zásad přístupu místního uživatele.

Doporučeným řešením tohoto problému je použití samostatných názvů prostředí pro místní vývoj a pracovní postupy GitHub Actions. Přečtěte si další informace o používání více prostředí pomocí azd env příkazu na stránce Nejčastější dotazy.

Podpora textového prohlížeče

Textové prohlížeče nejsou v současné době podporovány azd monitor.

azd pipeline config Použití šablon AzDo pro Javu ve Windows

Při spouštění azd pipeline config šablon AzDo pro Javu ve Windows může dojít k selhání. Máte například:

  1. Ve Windows spusťte následující příkaz:

    azd init --template Azure-Samples/todo-java-mongo
    azd pipeline config
    
  2. Došlo k následující chybě:

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

Řešení

Jedná se o známý problém. Při řešení tohoto problému zkuste použít následující příkaz:

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 selhání po upgradu azd na Apple Silicon (M1/M2)

V některých situacích může upgrade z x86_64 verze azd na binární soubor ARM64 vést k chybám šablon, které byly vytvořeny pomocí x86_64 verze azd. Důvodem je to, že šablona používá verzi, která v8-compile-cache se může pokusit načíst bajtové kódy integrované v rámci x86_64 do procesu ARM64.

Pokud chcete tento problém vyřešit, upgradujte v8-compile-cache balíček v ovlivněném projektu:

  1. Změňte adresář na službu, která selhala (src/api v případě failed packaging service 'api')
  2. Spusťte příkaz npm upgrade v8-compile-cache.
  3. Změňte adresář na kořen úložiště a spusťte azd příkaz (např. azd package nebo azd up) znovu.

azd pipeline config selhání kvůli zásadám podmíněného přístupu

Při spuštění azd pipeline configse může zobrazit chyba podobná následující:

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"}

Tato chyba souvisí s povolením tenanta Microsoft Entra pro zásady podmíněného přístupu. Konkrétní zásady vyžadují, abyste se přihlásili k podporované platformě zařízení.

Tato chyba se může zobrazit také z důvodu přihlášení pomocí mechanismu kódu zařízení, který brání správnému zjištění platformy zařízení v Microsoft Entra ID.

Řešení

Pokud chcete nakonfigurovat tento pracovní postup, musíte GitHubu udělit oprávnění k nasazení do Azure za vás. Autorizovat GitHub vytvořením instančního objektu Azure uloženého v tajném kódu GitHubu s názvem AZURE_CREDENTIALS. Pro kroky vyberte svého hostitele Codespace:

  1. Ujistěte se, že na zařízení, které je uvedené jako podporované, zkontrolujte podle chybové zprávy.

  2. Znovu spusťte azd auth login příznak s připojeným příznakem --use-device-code=false :

    azd auth login --use-device-code=false
    
  3. Po přihlášení se může zobrazit chyba se zprávou localhost refused to connect . Pokud ano:

    1. Zkopírujte adresu URL.
    2. V novém terminálu Codespaces spusťte curl '<pasted url>' (v uvozovkách) adresu URL.

    V původním terminálu by teď mělo být přihlášení úspěšné.

  4. Po přihlášení spusťte azd pipeline configznovu .