Sdílet prostřednictvím

Ř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í nápovědy 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.

Použití --debug 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 ostatním monitorovacím systémům přijímat nástroje pro ladění a může být také užitečný při hlášení problému na GitHubu.

Důležité

Nezapomeňte odstranit všechny citlivé informace při odesílání protokolů ladění na GitHub nebo při jejich ukládání 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. Nespouštějte příkazy Azure Developer CLI z domovského adresáře uživatele, který má nainstalované Azure CLI.

Nebyli jste přihlášeni do Azure nebo ve Visual Studio vypršela platnost tokenu

Po spuštění azd init -t <template-name> v sadě Visual Studio se objeví následující chyba: "Pro přístup k vzdálenému úložišti musíte znovu autorizovat aplikaci OAuth Visual Studio."

Ř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, tyto změny se nemusí 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 vypršet časový limit během dlouhého nasazení nebo jiných dlouhotrvajících úloh. Ujistěte se, aby sezení nezůstalo nečinné. Viz omezení využití Cloud Shellu.

Rozhraní Cloud Shellu

Cloud Shell je primárně rozhraní příkazového řádku a má 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 zajistili, že složka ~/bin je přítomna.
  2. Spusťte mkdir -p ~/azd a ujistěte se, že je k dispozici místní složka ~/azd.
  3. Spustit curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --install-folder ~/azd --symlink-folder ~/bin --version <version> (<version> by bylo ve výchozím nastavení, ale je možné zadat také konkrétní vydanou verzi jako stable).

Po instalaci má verze azd, která je symbolicky propojená v ~/bin, přednost před verzí azd, symbolicky propojenou v /usr/local/bin.

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

  1. Spusťte příkaz rm ~/bin/azd.
  2. Spusťte příkaz 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žadují nejnovější vydání 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: výstupní kód: 1, stdout: , stderr: warning: Nová verze Bicep je k dispozici: v0.4.1272."

Řešení

Původně byl Bicep nezbytným předpokladem 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 nefunguje

Věci se někdy mohou zvrtnout s azd up nebo azd provision. Mezi běžné chyby patří:

  • Nelze zřídit některé prostředky v oblasti Azure, protože v oblasti došla kapacita.
  • 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 webový portál Azure.

  2. Vyhledejte skupinu prostředků s názvem 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 na kartu Akce dotčeného úložiště GitHub a prozkoumejte soubor protokolu v běhu pipeline pro více informací.

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

azd init požaduje sudo

azd version = azure-dev-cli_0.2.0-beta.1 Předtím azdbyste 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 a pomocí azd opětovně vytvořte složku 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í.

I přes zprávu o úspěchu se statické webové aplikace nepodařilo nasadit.

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 GitHub akce. 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 přístupu k tajným klíčům v úložišti klíčů

Sdílení stejného názvu prostředí nebo skupiny prostředků při zřizování prostředků lokálně a v GitHub Actions může vést k chybě Does not have secrets get permission on key vault.. ve službě 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ě:

    Snímek obrazovky znázorňující chybu, která se zobrazila při spuštění konfigurace kanálu azd pomocí AzDo pro Javu ve 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 aktualizaci 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 v8-compile-cache, která se může pokusit načíst bajtový kód vytvořený pod 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: 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"}

Tato chyba souvisí s aktivací 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. Autorizujte GitHub vytvořením instančního objektu služby Azure, který bude uložen jako tajemství GitHubu s názvem AZURE_CREDENTIALS. Pro kroky vyberte svého hostitele Codespace:

  1. Ujistěte se, že používáte zařízení uvedené jako podporované v chybové zprávě.

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

    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. Spusťte curl '<pasted url>' (URL v uvozovkách) v novém terminálu Codespaces.

    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 .

Soubor Dockerfile uložený v mezipaměti místo aktuálního souboru Dockerfile

Při použití azd v místním vývojovém prostředí s Dockerem může Docker používat verzi souboru Dockerfile uloženou v mezipaměti místo aktuální verze. Výsledkem je nasazení pomocí kontejneru s nesprávnými informacemi.

Řešení

Pokud chcete nakonfigurovat místní instalaci Dockeru, kterou používá Azure Developer CLI k sestavení kontejneru, musíte Docker nakonfigurovat s následujícími proměnnými prostředí:

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

Můžete změnit azd up nastavení tak, aby zahrnovala tato nastavení:

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

podpora azd pipeline config

azd pipeline config v devContainers/VS Code Remote Containers se v současné době nepodporuje.

Podpora živých metrik pro Python

Živé metriky (azd monitor --live) se v současné době nepodporují pro aplikace v Pythonu. Další informace najdete v tématu Live Metrics: Monitorování a diagnostika s latencí 1 sekundy.

Vytvoření problému GitHubu s žádostí o pomoc

Obrázek loga GitHubu

Azure Developer CLI a rozšíření Visual Studio Code v Azure Developer CLI používají GitHub Issues ke sledování chyb a žádostí o funkce. Před vytvořením nových problémů vyhledejte existující problémy , abyste se vyhnuli duplicitám.

Pokud potřebujete pomoc nebo máte dotazy ohledně používání tohoto projektu, podívejte se na naše wiki pro používání Azure Developer CLI a náš dokument CONTRIBUTING, pokud chcete přispět.