Perguntas frequentes sobre a CLI do desenvolvedor do Azure

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.

da CLI do Desenvolvedor do Azure (azd) e da CLI do Azure (az) são ferramentas de linha de comando, mas ajudam você a executar tarefas diferentes.

azd se concentra no fluxo de trabalho de desenvolvedor de alto nível. Além de provisionar/gerenciar recursos do Azure, azd ajuda a unir componentes de nuvem, configuração de desenvolvimento local e automação de pipeline em uma solução completa.

A CLI do Azure é uma ferramenta de plano de controle para criar e administrar a infraestrutura do Azure, como máquinas virtuais, redes virtuais e armazenamento. A CLI do Azure foi projetada em torno de comandos granulares para tarefas administrativas específicas.

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

├── .Azure                          [This directory displays after you run add 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 

Sim. Você pode configurar vários ambientes (por exemplo, desenvolvimento, teste, produção). Você pode usar azd env para gerenciar esses ambientes.

O caminho do arquivo .env é <your-project-directory-name>\.azure\<your-environment-name>\.env.

Na CLI do Desenvolvedor do Azure, os comandos azd referem-se ao arquivo .env para configuração do ambiente. Comandos como azd deploy também atualizam o arquivo .env com, por exemplo, a cadeia de conexão db e o ponto de extremidade do Azure Key Vault.

Sim. 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.

O arquivo azure.yaml descreve os aplicativos e tipos de recursos do Azure incluídos no modelo.

A função secretOrRandomPassword recupera um segredo do Cofre de Chaves do Azure se os parâmetros para o nome e o segredo do cofre de chaves forem fornecidos. 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 Cofre da Chave 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 do secretOrRandomPassword também deve ser salva no Cofre da Chave usando o Bicep para execuções futuras. 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 Cofre de Chaves e armazenar o segredo gerado nele, use o código Bicep abaixo. Você pode exibir o código de exemplo completo para esses módulos no repositório GitHub da CLI do desenvolvedor do Azure.

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 do Bicep permite o seguinte fluxo de trabalho para gerenciar seus segredos:

1. Se o segredo especificado existir, ele será recuperado do Cofre da Chave usando a função secretOrRandomPassword.
2. Se o segredo não existir, um Cofre de Chaves será criado e o segredo gerado aleatoriamente será armazenado dentro dele.
3. Em implantações futuras, o método secretOrRandomPassword recupera o segredo armazenado agora que ele existe no Cofre de Chaves. O Cofre da Chave não será recriado se já existir, mas o mesmo valor secreto será armazenado novamente para a próxima execução.

Sim, mas cada local do Azure só pode ter uma implantação. Se você já tiver usado o local do Azure selecionado, verá o erro de implantaçã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.

Você pode selecionar um local diferente do Azure para corrigir o problema.

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

Nossos modelos criados por '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. Você pode remover manualmente o grupo de recursos antigo usando o portal do Azure ou executar azd down para remover todas as implantaçõ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.

O comando usa modelos Bicep, que são encontrados em <your-project-directory-name>/infra para provisionar recursos do Azure.

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

Usamos modelos de Bicep, que são encontrados em <your-project-directory-name>/infra, para provisionar recursos do 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 obter outros recursos, consulte Solucionar erros comuns de implantação do Azure - Azure Resource Manager.

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

Sim.

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 o uso de tags em recursos, você também pode usar a propriedade resourceName em azure.yaml para fornecer um nome de recurso explícito. Nesse caso, a lógica acima não é executada.

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.

Sim. Usamos o modo de implantação incremental .

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

Uma entidade de serviço do Azure é uma identidade criada para uso com aplicativos, serviços hospedados e ferramentas automatizadas para acessar recursos do 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 obter mais informações sobre a autenticação do Azure para o GitHub, consulte conectar o GitHub e o Azure | O Microsoft Docs.

Não. O comando azd pipeline config cuida da criação da entidade de serviço do Azure e executa as etapas necessárias para armazenar os segredos em seu repositório GitHub.

O comando armazena quatro segredos no 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-GH-account>/<your-repo>/secrets/actions.

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

Embora o OIDC tenha suporte como padrão para Ações do GitHub e Pipeline do Azure (definido como federado), ele não é suportado para o Azure DevOps ou o Terraform.

• Para o Azure DevOps, chamar explicitamente --auth-type como federated resultará em um 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.

Vá para https://github.com/<your-GH-account>/<your-repo>settings/secrets/actionse, em seguida, atualize AZURE_CREDENTIALS copiando e colando todo o objeto JSON para a nova entidade de serviço. Por exemplo:

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

O caminho do arquivo GitHub Actions é <your-project-directory-name>\.github\workflows\azure-dev.yml.

Sim. Substitua run: azd up --no-prompt por run: azd deploy --no-prompt.

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

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, você pode configurar seu aplicativo para usar uma entidade de serviço em vez do AzureDeveloperCliCredential.