Risolvere i problemi di Azure Developer CLI

  • Articolo

Questo articolo fornisce soluzioni ai problemi comuni che possono verificarsi quando si usa l'interfaccia della riga di comando per sviluppatori di Azure (azd).

Ottenere supporto e inviare commenti

Se non si riesce a trovare ciò che si sta cercando in questo articolo o si vuole fornire commenti e suggerimenti, è possibile inviare domande alle discussioni dell'interfaccia della riga di comando per sviluppatori di Azure.

È anche possibile segnalare i bug aprendo Problemi di GitHub nel repository GitHub dell'interfaccia della riga di comando per sviluppatori di Azure.

Uso dell'opzione --debug

Se si verifica un problema imprevisto durante l'uso di azd, eseguire di nuovo il comando con l'opzione per abilitare l'output --debug di debug e diagnostica aggiuntivo.

azd up --debug

È anche possibile inviare l'output di debug a un file di testo locale per migliorare l'usabilità. Questo approccio consente l'inserimento delle informazioni di debug da parte di altri sistemi di monitoraggio e può essere utile anche quando si invia un problema in GitHub.

Importante

Quando si inviano i log di debug in GitHub o si salvano in altri sistemi di diagnostica, assicurarsi di redigire eventuali informazioni riservate.

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

Directory .azure

L'interfaccia della riga di comando per sviluppatori di Azure presuppone che tutte le directory archiviate nella directory siano ambienti dell'interfaccia della .azure riga di comando per sviluppatori di Azure. Non eseguire i comandi dell'interfaccia della riga di comando per sviluppatori di Azure dalla home directory di un utente in cui è installata l'interfaccia della riga di comando di Azure.

Non è stato eseguito l'accesso ad Azure o il token è scaduto in Visual Studio

Dopo l'esecuzione azd init -t <template-name> in Visual Studio, viene visualizzato l'errore seguente: "Per accedere a remote: questo repository, è necessario riautorizzare l'applicazione Visual StudioOAuth ".

Soluzione

Eseguire azd auth login per aggiornare il token di accesso.

Le autorizzazioni dell'account Azure aggiornate non vengono aggiornate azd

Per impostazione predefinita, azd memorizza nella cache le credenziali e le autorizzazioni di Azure. Se all'account Azure vengono assegnati nuovi ruoli e autorizzazioni o vengono aggiunte a sottoscrizioni aggiuntive, queste modifiche potrebbero non essere immediatamente riflesse in azd. Per risolvere questo problema, disconnettersi e quindi accedere di nuovo a azd usando i comandi seguenti:

azd auth logout

azd auth login

Seguire le istruzioni del azd auth login comando per completare il processo di accesso e aggiornare le credenziali memorizzate nella cache.

Limitazioni di Cloud Shell per azd

Esistono alcune limitazioni per l'esecuzione azd in Cloud Shell:

Supporto di Docker in Cloud Shell

Cloud Shell non supporta l'esecuzione di docker build o run comandi perché il daemon Docker non è in esecuzione. Per altre informazioni, vedere Risoluzione dei problemi di Cloud Shell.

Timeout di Cloud Shell

Cloud Shell può verificarsi un timeout durante una distribuzione prolungata o altre attività a esecuzione prolungata. Assicurarsi che la sessione non diventi inattiva. Vedere Limiti di utilizzo di Cloud Shell.

Interfaccia di Cloud Shell

Cloud Shell è principalmente un'interfaccia della riga di comando e avrà meno funzionalità rispetto a un ambiente di sviluppo integrato come Visual Studio Code.

Impossibile connettersi al daemon Docker in Cloud Shell

Cloud Shell usa un contenitore per ospitare l'ambiente shell, quindi le attività che richiedono l'esecuzione del daemon Docker non sono consentite.

Installare una versione diversa di azd in Cloud Shell

In alcuni casi potrebbe essere necessario installare una versione diversa di azd quella già in uso in Cloud Shell. A tale scopo, in bash:

  1. Eseguire mkdir -p ~/bin per assicurarsi che la ~/bin cartella sia presente
  2. Eseguire mkdir -p ~/azd per assicurarsi che sia presente una cartella locale ~/azd
  3. Run curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --install-folder ~/azd --symlink-folder ~/bin --version <version> (<version> è stable per impostazione predefinita, ma è possibile specificare anche una versione rilasciata specifica come 1.0.0 può essere specificata).

Dopo l'installazione, la versione di azd collegata simbolicamente in ~/bin avrà la precedenza sulla versione di azd collegata simbolicamente in /usr/local/bin.

Per ripristinare l'uso della versione di azd già installata in Cloud Shell in bash:

  1. Eseguire rm ~/bin/azd
  2. Eseguire rm -rf ~/azd

Soluzione

Usare un altro host per eseguire attività che richiedono il daemon Docker. Un'opzione consiste nell'usare docker-machine, come descritto nella documentazione sulla risoluzione dei problemi di Cloud Shell.

Requisito dell'interfaccia della riga di comando di Azure Bicep

azd up e azd provision richiedono la versione più recente dell'interfaccia della riga di comando di Azure Bicep. È possibile che venga visualizzato il messaggio di errore seguente: "Errore: non è stato possibile compilare un modello bicep: errore durante l'esecuzione del modulo Az PowerShell bicep build: codice di uscita: 1, stdout: , stderr: AVVISO: è disponibile una nuova versione Bicep: v0.4.1272".

Soluzione

In precedenza, Bicep era un preqrequisite per l'installazione e l'uso di azd . azd ora installa automaticamente Bicep nell'ambito locale azd (non a livello globale) e questo problema dovrebbe ora essere risolto. Tuttavia, se si vuole usare una versione diversa, è possibile impostare la variabile di ambiente: AZD_BICEP_TOOL_PATH per puntare alla posizione della versione necessaria.

azd up o azd provision ha esito negativo

A volte le cose possono andare awry con azd up o azd provision. Di seguito sono riportati gli errori più comuni.

  • "Non è possibile effettuare il provisioning di determinate risorse in un'area di Azure perché l'area non è in capacità".
  • "Il provider di risorse pertinente non è presente in tale area".

I passaggi per la risoluzione dei problemi possono variare a seconda della causa radice.

Soluzione

  1. Vai al portale di Azure.

  2. Individuare il gruppo di risorse, ovvero rg-your-environment-name<>.

  3. Selezionare Distribuzioni per ottenere altre informazioni.

  4. Verificare di aver specificato un nome di ambiente identico al nome dell'ambiente.

  5. Passare a https://github.com/<your repo>/actionse quindi fare riferimento al file di log nell'esecuzione della pipeline per altre informazioni.

Per altre risorse, vedere Risolvere gli errori comuni di distribuzione di Azure - Azure Resource Manager.

azd init richiede sudo

Prima azd version = azure-dev-cli_0.2.0-beta.1di creare azd una .azd cartella con drw-r--r-- accesso.

Questo causerà un problema, perché l'uso di questa o qualsiasi versione precedente in qualsiasi configurazione linux (WSL, ssh-remote, devcontainer e così via) fornisce già una .azd cartella con modalità di sola lettura.

Soluzione

  1. Eliminare manualmente la cartella già specificata .azd :

    rm -r ~/.azd

  2. Eseguire azd init per azd creare di nuovo la cartella con i livelli di accesso corretti.

azd monitor per il contenitore di sviluppo

azd monitor non è attualmente supportato se si usa un contenitore di sviluppo come ambiente di sviluppo.

Impossibile eseguire l'autenticazione negli ambienti Codespaces

Se si verificano problemi di autenticazione in Codespaces, assicurarsi che il dockerfile del modello includa i sudo apt-get update && sudo apt-get install xdg-utils comandi. Il xdg-utils comando aprirà una scheda del browser che consente di accedere.

App Web statiche non è possibile eseguire la distribuzione nonostante il messaggio di esito positivo

Esiste un problema noto durante la distribuzione in App Web statiche di Azure in cui l'output predefinito azd up può indicare che l'azione è riuscita, ma le modifiche non sono state effettivamente distribuite. È possibile diagnosticare questo problema eseguendo il azd up comando con il --debug flag abilitato. Nei log di output è possibile che venga visualizzato il messaggio seguente:

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

È molto probabile che si verifichi questo problema quando azd viene eseguito da un'azione GitHub. Come soluzione alternativa, dopo aver compilato il sito, copiare staticwebapp.config.json nella cartella di compilazione. È possibile automatizzare questo passaggio usando un hook dei comandi prepacchetto o pre-distribuzione, che consente di eseguire script personalizzati in vari punti nei flussi di lavoro dei comandi azd.

Il team del prodotto sta lavorando per risolvere questo problema.

Errore di GitHub Actions : "Non dispone dell'autorizzazione per ottenere i segreti per l'insieme di credenziali delle chiavi"

La condivisione dello stesso nome di ambiente o gruppo di risorse durante il provisioning delle risorse in locale e in GitHub Actions può generare l'errore Does not have secrets get permission on key vault.. dal servizio Key Vault. Key Vault non supporta gli aggiornamenti incrementali delle autorizzazioni tramite Bicep, il che significa che il flusso di lavoro di GitHub Actions sovrascrive le autorizzazioni dei criteri di accesso dell'utente locale.

La soluzione consigliata a questo problema consiste nell'usare nomi di ambiente separati per i flussi di lavoro di sviluppo locale e GitHub Actions. Altre informazioni sull'uso di più ambienti con il azd env comando nella pagina Domande frequenti.

Supporto del browser basato su testo

I browser basati su testo non sono attualmente supportati da azd monitor.

azd pipeline config uso di AzDo per modelli Java in Windows

È possibile che si verifichi un errore durante l'esecuzione azd pipeline config con i modelli AzDo per Java in Windows. Ad esempio, hai:

  1. Eseguire quanto segue in Windows:

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

  2. È stato ricevuto l'errore seguente:

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

Soluzione

Questo è un problema noto Durante la gestione di questo problema, provare il comando seguente:

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 errore dopo l'aggiornamento azd in Apple Silicon (M1/M2)

In alcune situazioni, l'aggiornamento dalla versione x86_64 di azd a un file binario ARM64 può causare errori per i modelli compilati con la versione x86_64 di azd. Questo perché il modello usa una versione di v8-compile-cache che può provare a caricare bytecode compilata in x86_64 in un processo ARM64.

Per risolvere questo problema, aggiornare il v8-compile-cache pacchetto nel progetto interessato:

  1. Passare alla directory del servizio che non è riuscita (src/api nel caso di failed packaging service 'api')
  2. Eseguire npm upgrade v8-compile-cache
  3. Passare alla directory radice del repository ed eseguire di nuovo il azd comando (ad esempio azd package o azd up)

azd pipeline config errore dovuto ai criteri di accesso condizionale

Quando si esegue azd pipeline config, è possibile che venga visualizzato un errore simile al seguente:

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

Questo errore è correlato all'abilitazione del tenant di Microsoft Entra dei criteri di accesso condizionale. I criteri specifici richiedono l'accesso a una piattaforma di dispositivi supportata.

È anche possibile che venga visualizzato questo errore a causa dell'accesso tramite il meccanismo di codice del dispositivo, che impedisce a Microsoft Entra ID di rilevare correttamente la piattaforma del dispositivo.

Soluzione

Per configurare il flusso di lavoro, è necessario concedere a GitHub l'autorizzazione per la distribuzione in Azure per conto dell'utente. Autorizzare GitHub creando un'entità servizio di Azure archiviata in un segreto GitHub denominato AZURE_CREDENTIALS. Selezionare l'host Codespace per i passaggi seguenti:

  1. Assicurarsi di essere in esecuzione in un dispositivo elencato come supportato, in base al messaggio di errore.

  2. Rieseguire azd auth login con il flag --use-device-code=false aggiunto:

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

  3. È possibile che venga visualizzato un errore con messaggio localhost refused to connect dopo l'accesso. In tal caso:

    1. Copia l'URL.
    2. Eseguire curl '<pasted url>' (URL tra virgolette) in un nuovo terminale Codespaces.

    Nel terminale originale l'account di accesso dovrebbe avere esito positivo.

  4. Dopo l'accesso, eseguire azd pipeline configdi nuovo .