Resolver problemas do Azure Developer CLI

Este artigo fornece soluções para problemas comuns que podem surgir quando você está usando a CLI do Desenvolvedor do Azure (azd).

Obter ajuda e enviar comentários

Se você não conseguir encontrar o que está procurando neste artigo ou quiser fornecer comentários, poderá postar perguntas nas Discussões da CLI do Desenvolvedor do Azure.

Você também pode relatar bugs abrindo Problemas do GitHub no repositório GitHub da CLI do Desenvolvedor do Azure.

Utilização do interruptor --debug

Se você encontrar um problema inesperado ao trabalhar com azdo , execute novamente o comando com o switch para habilitar a depuração adicional e a --debug saída de diagnóstico.

azd up --debug

Você também pode enviar a saída de depuração para um arquivo de texto local para melhorar a usabilidade. Essa abordagem permite que as informações de depuração sejam ingeridas por outros sistemas de monitoramento e também pode ser útil ao registrar um problema no GitHub.

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

O .azure diretório

A CLI do Desenvolvedor do Azure pressupõe que todos os diretórios armazenados no diretório sejam ambientes da CLI do .azure Desenvolvedor do Azure. Não execute comandos da CLI do Azure Developer a partir do diretório base de um usuário que tenha a CLI do Azure instalada.

Não conectado ao Azure ou token expirou no Visual Studio

Depois de executar azd init -t <template-name> no Visual Studio, você recebe o seguinte erro: "Para acessar remoto: este repositório, você deve autorizar novamente o aplicativo Visual StudioOAuth."

Solução

Execute azd auth login para atualizar o token de acesso.

As permissões atualizadas da conta do Azure não são atualizadas azd

Por padrão, azd armazena em cache suas credenciais e permissões do Azure. Se a sua conta do Azure receber novas funções e permissões ou for adicionada a assinaturas adicionais, essas alterações podem não ser refletidas imediatamente no azd. Para resolver este problema, termine sessão e, em seguida, inicie sessão novamente utilizando azd os seguintes comandos:

azd auth logout

azd auth login

Siga as instruções do azd auth login comando para concluir o processo de entrada e atualizar suas credenciais armazenadas em cache.

Limitações do Cloud Shell para azd

Existem algumas limitações para executar azd no Cloud Shell:

Suporte ao Docker no Cloud Shell

O Cloud Shell não suporta a execução de docker build ou run comandos porque o daemon do docker não está em execução. Para obter mais informações, consulte Solução de problemas do Cloud Shell.

Tempo limite do Cloud Shell

O Cloud Shell pode atingir o tempo limite durante uma implementação longa ou outras tarefas de longa execução. Certifique-se de que a sessão não fica ociosa. Consulte Limites de uso do Cloud Shell.

Interface do Cloud Shell

O Cloud Shell é principalmente uma interface de linha de comando e terá menos recursos do que um ambiente de desenvolvimento integrado como o Visual Studio Code.

Não é possível conectar-se ao daemon do Docker no Cloud Shell

O Cloud Shell usa um contêiner para hospedar seu ambiente de shell, portanto, tarefas que exigem a execução do daemon do Docker não são permitidas.

Instalar versão diferente do azd no Cloud Shell

Em alguns casos, pode ser necessário instalar uma versão diferente da azd versão já em uso no Cloud Shell. Para fazer isso em bash:

1. Execute mkdir -p ~/bin para garantir que a ~/bin pasta está presente
2. Executar mkdir -p ~/azd para garantir que uma pasta local ~/azd esteja presente
3. Executar curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --install-folder ~/azd --symlink-folder ~/bin --version <version> (<version> seria stable por padrão, mas uma versão lançada específica como 1.0.0 também pode ser especificada).

Uma vez instalada, a versão do azd simbolicamente ligado em ~/bin terá precedência sobre a versão do azd simbolicamente ligado em /usr/local/bin.

Para voltar a usar a versão do azd já instalada no Cloud Shell no bash:

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

Solução

Use outro host para executar tarefas que exigem o daemon docker. Uma opção é usar o docker-machine, conforme descrito na documentação de solução de problemas do Cloud Shell.

Requisito da CLI do Azure Bicep

azd up e azd provision exigem a versão mais recente da CLI do Azure Bicep. Você pode receber a seguinte mensagem de erro: "Erro: falha ao compilar o modelo bicep: falha ao executar o módulo Az PowerShell bicep build: exit code: 1, stdout: , stderr: AVISO: Uma nova versão do Bicep está disponível: v0.4.1272."

Solução

Anteriormente, o Bicep era um pré-requisito para instalar e usar o azd . azd agora instala automaticamente o Bicep dentro do escopo local azd (não globalmente) e esse problema agora deve ser resolvido. No entanto, se você quiser usar uma versão diferente, você pode definir a variável de ambiente: AZD_BICEP_TOOL_PATH para apontar para o local da versão que você precisa.

azd up ou azd provision falha

Às vezes, as coisas podem dar errado com azd up ou azd provision. Os erros comuns incluem:

• "Não é possível provisionar determinados recursos em uma região do Azure porque a região está fora de capacidade."
• "O provedor de recursos relevante não está presente nessa região."

As etapas de solução de problemas podem ser diferentes, dependendo da causa raiz.

Solução

1. Aceda ao portal do Azure.

2. Localize seu grupo de recursos, que é rg-your-environment-name<>.

3. Selecione Implantações para obter mais informações.

4. Verifique se você especificou um nome de ambiente igual ao nome do ambiente.

5. Vá para https://github.com/<your repo>/actionse consulte o arquivo de log na execução do pipeline para obter mais informações.

Para obter outros recursos, consulte Solucionar erros comuns de implantação do Azure - Azure Resource Manager.

azd init requer sudo

Antes azd version = azure-dev-cli_0.2.0-beta.1, azd criaria uma .azd pasta com drw-r--r-- acesso.

Isso causará um problema, pois usar esta ou qualquer versão anterior em qualquer configuração do Linux (WSL, ssh-remote, devcontainer, etc.) já fornece uma .azd pasta com modo somente leitura.

Solução

1. Exclua manualmente a pasta já fornecida .azd :

   rm -r ~/.azd
   

2. Execute azd init para azd criar a pasta novamente com os níveis de acesso corretos.

azd monitor para contêiner de desenvolvimento

azd monitor atualmente não é suportado se você usar um contêiner de desenvolvimento como seu ambiente de desenvolvimento.

Não é possível autenticar em ambientes do Codespaces

Se você estiver enfrentando problemas de autenticação no Codespaces, verifique se o Dockerfile de modelo inclui os sudo apt-get update && sudo apt-get install xdg-utils comandos. O xdg-utils comando abrirá uma guia do navegador que permite que você faça login.

Falha na implantação de aplicativos Web estáticos apesar da mensagem de sucesso

Existe um problema conhecido ao implantar em Aplicativos Web Estáticos do Azure no qual a saída padrão azd up pode indicar que a ação foi bem-sucedida, mas as alterações não foram realmente implantadas. Você pode diagnosticar esse problema executando o azd up comando com o --debug sinalizador habilitado. Nos logs de saída, você pode ver a seguinte mensagem:

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

É mais provável que você encontre esse problema quando azd é executado a partir de uma ação do GitHub. Como solução alternativa, depois de criar seu site, copie staticwebapp.config.json para a pasta de compilação. Você pode automatizar essa etapa usando um gancho de comando prepackage ou predeploy, que permite executar scripts personalizados em vários pontos nos fluxos de trabalho do comando azd.

A equipe de produto está trabalhando para resolver esse problema.

Erro de ações do GitHub - "Não tem segredos obter permissão no cofre de chaves"

Compartilhar o mesmo ambiente ou nome de grupo de recursos ao provisionar recursos localmente e em Ações do GitHub pode produzir o erro Does not have secrets get permission on key vault.. do serviço Cofre de Chaves. O Cofre da Chave não suporta atualizações de permissões incrementais por meio do Bicep, o que efetivamente significa que o fluxo de trabalho Ações do GitHub substitui as permissões da Política de Acesso do usuário local.

A solução recomendada para esse problema é usar nomes de ambiente separados para fluxos de trabalho de desenvolvimento local e Ações do GitHub. Leia mais sobre como usar vários ambientes com o azd env comando na página de perguntas frequentes.

Suporte a navegador baseado em texto

Atualmente, os navegadores baseados em texto não são suportados pelo azd monitor.

azd pipeline config usando modelos AzDo para Java no Windows

Você pode encontrar uma falha ao executar azd pipeline config com modelos AzDo for Java no Windows. Por exemplo, você:

1. Execute o seguinte no Windows:

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

2. Recebeu o seguinte erro:

   

Solução

Trata-se de um problema conhecido. Enquanto abordamos esse problema, tente o seguinte comando:

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 falha após a atualização azd no Apple Silicon (M1/M2)

Em algumas situações, a atualização da versão x86_64 para azd um binário ARM64 pode resultar em falhas para modelos que foram criados com a versão x86_64 do azd. Isso ocorre porque o modelo usa uma versão da v8-compile-cache qual pode tentar carregar bytecode construído sob x86_64 em um processo ARM64.

Para corrigir esse problema, atualize o v8-compile-cache pacote no projeto afetado:

1. Alterar diretório para o serviço que falhou (src/api no caso de failed packaging service 'api')
2. Executar npm upgrade v8-compile-cache
3. Altere o diretório para a raiz do repositório e execute o azd comando (por exemplo, azd package ou azd up) novamente

azd pipeline config falha devido à Política de Acesso Condicional

Ao executar azd pipeline configo , você pode receber um erro como o seguinte:

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

Este erro está relacionado com a ativação das Políticas de Acesso Condicional pelo inquilino do Microsoft Entra. A política específica requer que você esteja conectado a uma plataforma de dispositivo compatível.

Você também pode estar recebendo esse erro devido a estar conectado usando o mecanismo de código do dispositivo, o que impede que o Microsoft Entra ID detete a plataforma do dispositivo corretamente.

Solução

Para configurar o fluxo de trabalho, tem de conceder permissão ao GitHub para implementar no Azure em seu nome. Autorize o GitHub criando uma Entidade de Serviço do Azure armazenada em um segredo do GitHub chamado AZURE_CREDENTIALS. Selecione seu host Codespace para as etapas: