Compartilhar via

Ferramentas e ambiente de desenvolvimento CLI do Azure: Perguntas Frequentes

Este artigo fornece respostas a perguntas frequentes sobre as ferramentas, comandos e ambientes da Azure Developer CLI (azd).

Perguntas gerais

A secção seguinte foca-se em questões gerais azd de ferramentas e ambiente.

Como é que desinstalo a CLI do Azure Developer?

Existem diferentes opções para desinstalar azd dependendo de como você o instalou originalmente. Visite a página de instalação do para obter detalhes.

Qual é a diferença entre o Azure Developer CLI e o Azure CLI?

Azure Developer CLI (azd) e Azure CLI (az) são ambas ferramentas de linha de comandos, mas ajudam-te a fazer tarefas diferentes.

azd se concentra no fluxo de trabalho de desenvolvedor de alto nível. Para além de provisionar/gerir recursos Azure, o azd ajuda a unir componentes cloud, configuração de desenvolvimento local e automação de pipelines numa solução completa.

O Azure CLI é uma ferramenta de plano de controlo para criar e administrar infraestrutura Azure, como máquinas virtuais, redes virtuais e armazenamento. A Azure CLI é concebida em torno de comandos granulares para tarefas administrativas específicas.

Visite Azure Developer CLI vs Azure CLI para mais informações.

O que é um nome de ambiente?

Azure CLI de Developer usa um nome de ambiente para definir a variável de ambiente AZURE_ENV_NAME usada pelos templates de CLI de Azure Developer. AZURE_ENV_NAME também é usado para prefixar o nome do grupo de recursos Azure. Como cada ambiente tem o seu próprio conjunto de configurações, o Azure Developer CLI armazena todos os ficheiros de configuração em diretórios do ambiente.

├── .Azure                          [This directory displays after you run `azd init` or `azd up`]
│   ├── <your environment1>         [A directory to store all environment-related configurations]
│   │   ├── .env                    [Contains environment variables]
│   │   └── main.parameters.json    [A parameter file]
│   └── <your environment2>         [A directory to store all environment-related configurations]
│   │   ├── .env                    [Contains environment variables]
│   │   └── main.parameters.json    [A parameter file]
│   └──config.json

Para mais informações sobre fluxos de trabalho, veja azd init e azd up.

Posso configurar mais de um ambiente?

Yes. Você pode configurar vários ambientes (por exemplo, desenvolvimento, teste, produção). Podes usar azd env para gerir estes ambientes.

Onde o arquivo de configuração do ambiente (.env) é armazenado?

O caminho do arquivo .env é <your-project-directory-name>\.azure\<your-environment-name>\.env. Para mais informações, consulte Gerir variáveis de ambiente.

Como se utiliza o arquivo .env?

Na CLI Azure Developer, os comandos azd referem-se ao ficheiro .env para configuração do ambiente. Comandos como azd deploy também atualizam o ficheiro .env com, por exemplo, a cadeia de conexão da base de dados e o endpoint do Azure Key Vault.

Já corri azd up em Codespaces. Posso continuar o meu trabalho num ambiente de desenvolvimento local?

Yes. Você pode continuar o trabalho de desenvolvimento localmente.

  1. Execute azd init -t <template repo> para clonar o projeto de modelo para sua máquina local.
  2. Para puxar para baixo o env existente criado usando Codespaces, execute azd env refresh. Certifique-se de fornecer o mesmo nome de ambiente, assinatura e local que antes.

Como posso autenticar no Codespaces se o login do dispositivo tiver algum problema?

Se tiver problemas com a autenticação do código do dispositivo em Codespaces (por exemplo, pedidos ou erros recorrentes de 2FA), experimente a seguinte solução alternativa usando o VS Code Desktop:

  1. Abra o seu Codespace no VS Code Desktop usando um destes métodos:
    • Use a paleta de comandos (Ctrl+Shift+P no Windows ou Cmd+Shift+P no MacOs) e selecione Espaços de código: Abrir no VS Code Desktop.
    • Clique no canto inferior esquerdo do Codespace no navegador e selecione Abrir no VS Code Desktop).
  2. No terminal VS Code Desktop, execute o login de autenticação azd e complete a autenticação baseada no navegador.
  3. Depois de autenticado, feche o VS Code Desktop e volte ao seu Codespace no navegador. O estado de autenticação deve persistir.

Como se utiliza o arquivo azure.yaml?

O ficheiro azure.yaml descreve as aplicações e tipos de recursos de Azure incluídos no modelo.

Qual é o comportamento da secretOrRandomPassword função?

A função secretOrRandomPassword recupera um segredo de Azure Key Vault se forem fornecidos parâmetros para o nome do cofre de chaves e o segredo. Se esses parâmetros não forem fornecidos ou um segredo não puder ser recuperado, a função retornará uma senha gerada aleatoriamente para ser usada.

O exemplo a seguir demonstra um caso de uso comum do secretOrRandomPassword em um arquivo main.parameters.json. As variáveis ${AZURE_KEY_VAULT_NAME} e sqlAdminPassword são passadas como parâmetros para os nomes do Key Vault e do segredo. Se o valor não puder ser recuperado, uma senha aleatória será gerada.

"sqlAdminPassword": {
    "value": "$(secretOrRandomPassword ${AZURE_KEY_VAULT_NAME} sqlAdminPassword)"
}

A saída de secretOrRandomPassword também deve ser guardada no Key Vault utilizando o Bicep para futuras execuções. Recuperar e reutilizar os mesmos segredos em implantações pode evitar erros ou comportamentos não intencionais que podem surgir ao gerar repetidamente novos valores. Para criar um Key Vault e armazenar o segredo gerado nele, use o código Bicep abaixo. Pode ver o código de exemplo completo destes módulos no repositório Azure Developer CLI GitHub.

module keyVault './core/security/keyvault.bicep' = {
name: 'keyvault'
scope: resourceGroup
params: {
    name: '${take(prefix, 17)}-vault'
    location: location
    tags: tags
    principalId: principalId
}
}

module keyVaultSecrets './core/security/keyvault-secret.bicep' = {
name: 'keyvault-secret-sqlAdminPassword'
scope: resourceGroup
params: {
    keyVaultName: keyVault.outputs.name
    name: 'sqlAdminPassword'
    secretValue: sqlAdminPassword
}
}]

Esta configuração Bicep permite o seguinte fluxo de trabalho para gerir os seus segredos:

  1. Se o segredo especificado existir, é recuperado de Key Vault usando a função secretOrRandomPassword.
  2. Se o segredo não existir, cria-se um Key Vault, e o segredo gerado aleatoriamente é armazenado dentro dele.
  3. Em implementações futuras, o método secretOrRandomPassword recupera o segredo armazenado agora que existe em Key Vault. O Key Vault não será recriado se já existir, mas o mesmo valor secreto será guardado novamente para a próxima corrida.

Posso usar a Subscrição Gratuita do Azure?

Sim, mas cada localização Azure só pode ter uma implementação. Se já usou a localização Azure selecionada, verá o erro de implementação:

InvalidTemplateDeployment: The template deployment '<env_name>' isn't valid according to the validation procedure. The tracking ID is '<tracking_id>'. See inner errors for details.

Pode selecionar uma localização diferente no Azure para resolver o problema.

A minha aplicação alojada com o Azure App Service está a ativar um aviso de "Site enganador à frente". Como posso corrigi-lo?

Isso pode acontecer devido ao nosso método de nomear recursos.

Os nossos templates criados pelo 'Azure Dev' permitem configurar o nome do recurso. Para fazer isso, você pode adicionar uma entrada ao main.parameters.json na pasta infra. Por exemplo:

"webServiceName": {
    "value": "my-unique-name"
}

Esta entrada cria um novo recurso chamado "my-unique-name" em vez de um valor aleatório como "app-web-aj84u2adj" na próxima vez que você provisionar seu aplicativo. Podes remover manualmente o grupo de recursos antigo usando o portal Azure ou executar azd down para remover todas as implementações anteriores. Depois de remover os recursos, execute azd provision para criá-los novamente com o novo nome.

Esse nome precisará ser globalmente exclusivo, caso contrário, você receberá um erro ARM durante azd provision quando ele tentar criar o recurso.

Posso trabalhar em múltiplos arrendatários do Azure?

Yes. Para autenticar com um tenant específico, use o --tenant-id parâmetro com o azd auth login comando.

azd auth login --tenant-id <tenant-id>

Alternativamente, se quiser azd ter acesso a todos os seus inquilinos, pode tratar primeiro dos desafios de Autenticação Multifator (MFA) no navegador:

  1. Abra o Azure Portal no seu navegador.
  2. Alterna para cada um dos teus arrendatários um a um. Esta ação ativa quaisquer desafios de MFA necessários e atualiza os seus tokens.
  3. Execute azd auth login no seu terminal. azd Vai usar os tokens de sessão e acesso existentes do navegador, que agora são válidos para todos os inquilinos que visitou.

Posso correr azd up várias vezes?

Yes. Usamos o modo de implantação incremental. Para mais informações, veja azd up.

Provisioning

A secção seguinte foca-se no azd processo de provisionamento.

Posso correr azd provision várias vezes?

Yes. Usamos o modo de implantação incremental. Para mais informações, veja disposição azd.

Como é que o azd provision comando sabe que recursos deve fornecer?

O comando utiliza templates Bicep, que se encontram sob <your-project-directory-name>/infra para provisionar Azure recursos.

Onde posso encontrar que recursos estão provisionados no Azure?

Aceda a https://portal.azure.com e, em seguida, procure o seu grupo de recursos, que é rg-<your-environment-name>.

Como posso encontrar mais informações sobre erros no Azure?

Usamos modelos Bicep, que se encontram em <your-project-directory-name>/infra, para fornecer recursos Azure. Se houver problemas, incluímos a mensagem de erro na saída da CLI.

Você também pode ir para https://portal.azure.com e, em seguida, procurar seu grupo de recursos, que é rg-<your-environment-name>. Se alguma das implantações falhar, selecione o link de erro para obter mais informações.

Para outros recursos, consulte Resolver erros comuns de implementação no Azure - Gestor de Recursos do Azure.

Existe algum ficheiro de registo para azd provision?

Brevemente. Este recurso está planejado para uma versão futura.

Implementação

A seção seguinte concentra-se no processo de azd implantação.

Posso correr azd deploy várias vezes?

Yes. Consulte o azd deploy para mais informações.

Como é que o azd encontra o recurso do Azure para implementar o meu código?

Durante a implantação, azd primeiro descobre todos os grupos de recursos que compõem seu aplicativo procurando grupos marcados com azd-env-name e com um valor que corresponda ao nome do seu ambiente. Em seguida, ele enumera todos os recursos em cada um desses grupos de recursos, procurando um recurso marcado com azd-service-name com um valor que corresponda ao nome do seu serviço de azure.yaml.

Embora recomendemos usar etiquetas nos recursos, também pode usar a propriedade resourceName no azure.yaml para fornecer um nome de recurso explícito. Nesse caso, a lógica acima não é executada.

Como faço para implantar serviços específicos no meu projeto enquanto ignoro outros?

Ao implantar seu projeto, você pode optar por implantar serviços específicos especificando o nome do serviço no comando (ou seja, azd deploy api) ou navegando até uma subpasta que contenha apenas o(s) serviço(s) que você deseja implantar. Ao fazer isso, todos os outros serviços serão listados como - Skipped.

Se não quiser ignorar nenhum serviço, execute o comando a partir da pasta raiz ou adicione o sinalizador --all ao comando.

Configuração do pipeline

A seguinte secção foca-se na configuração do pipeline CI/CD.

O que é um principal de serviço do Azure?

Um principal de serviço Azure é uma identidade criada para ser usada com aplicações, serviços alojados e ferramentas automatizadas para aceder a recursos Azure. Esse acesso é restrito pelas funções atribuídas à entidade de serviço, o que lhe dá controle sobre quais recursos podem ser acessados e em que nível. Para mais informações sobre autenticação de Azure para GitHub, veja Connect GitHub e Azure | Microsoft Docs.

Devo criar um principal de serviço Azure antes de executar azd pipeline config?

Não. O comando azd pipeline config trata de criar o principal de serviço Azure e de executar os passos necessários para armazenar os segredos no seu repositório de GitHub.

Quais são todos os segredos armazenados no GitHub?

O comando armazena quatro segredos em GitHub: AZURE_CREDENTIALS, AZURE_ENV_NAME, AZURE_LOCATION e AZURE_SUBSCRIPTION_ID. Você pode substituir o valor de cada segredo indo para https://github.com/<your-github-account>/<your-repo>/secrets/actions.

O que é OpenID Connect (OIDC) e é suportado?

Com OpenID Connect, os seus fluxos de trabalho podem trocar tokens de curta duração diretamente de Azure.

Embora o OIDC seja suportado como padrão para GitHub Actions e Azure Pipeline (definido como federated), não é suportado para Azure DevOps ou Terraform.

  • Para Azure DevOps, chamar explicitamente --auth-type como federated resultará num erro.
  • Para Terraform:
    • Se --auth-type não for definido, ele voltará para clientcredentials e resultará em um aviso.
    • Se --auth-type estiver explicitamente definido como federated, resultará em um erro.

Como posso redefinir o princípio de serviço do Azure que está armazenado no GitHub Actions?

Vá para https://github.com/<your-github-account>/<your-repo>settings/secrets/actions, em seguida, atualize AZURE_CREDENTIALS copiando e cole todo o objeto JSON para o novo principal de serviço. Por exemplo:

{
"clientId": "<GUID>",
"clientSecret": "<GUID>",
"subscriptionId": "<GUID>",
"tenantId": "<GUID>",
(...)
}

Onde está armazenado o ficheiro GitHub Actions?

O caminho do ficheiro GitHub Actions é <your-project-directory-name>\.github\workflows\azure-dev.yml. Para mais informações, consulte Quickstart: Criar um princípio de serviço e executar uma GitHub Ação.

No arquivo azure-dev.yml, posso implantar apenas o código na etapa de compilação?

Yes. Substituir run: azd up --no-prompt por run: azd deploy --no-prompt.

Onde posso encontrar o registo do trabalho GitHub Actions que ativei quando executei azd pipeline config?

Vá para https://github.com/<your-github-account>/<your-repo>/actionse, em seguida, consulte o arquivo de log na execução do fluxo de trabalho.

Criando um aplicativo de contêiner localmente

Por que não consigo executar localmente o aplicativo de contêiner que estou criando?

Ao criar aplicativos de contêiner localmente, você precisa executar azd auth login no contêiner para que o aplicativo funcione com o AzureDeveloperCliCredential. Como alternativa, pode configurar a sua aplicação para usar uma entidade de serviço em vez do AzureDeveloperCliCredential.

  • Last updated on