Perguntas frequentes da Azure Developer CLI

Existem diferentes opções para desinstalar o azd, dependendo da instalação original. Visite a página de instalação para obter detalhes.

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

azd concentra-se no fluxo de trabalho do desenvolvedor de alto nível. Além de provisionar/gerenciar os recursos do Azure, o 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 painel 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.

O Azure Developer CLI usa um nome de ambiente para configurar a variável de ambiente AZURE_ENV_NAME usada por modelos do Azure Developer CLI. AZURE_ENV_NAME também é usado como prefixo no nome do grupo de recursos do Azure. Como cada ambiente tem seu próprio conjunto de configurações, o Azure Developer CLI 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 do azd referem-se ao arquivo .env para configuração do ambiente. Comandos como azd deploy também atualizam o arquivo .env, por exemplo, com 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 no computador local.
2. Para extrair o ambiente existente criado com o Codespaces, execute azd env refresh. Forneça o mesmo nome de ambiente, assinatura e local de antes.

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

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

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 transmitidas 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 salva no Key Vault 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 novos valores repetidamente. Para criar um cofre de chaves e armazenar o segredo gerado nele, use o código do 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
  }
}]

Essa configuração do Bicep permite o seguinte fluxo de trabalho para gerenciar seus segredos:

1. Se o segredo especificado existir, ele será recuperado do Key Vault 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 existe no cofre de chaves. O cofre de chaves 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 nomenclatura de recursos.

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

Essa 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 do ARM durante azd provision ao tentar criar o recurso.

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

Vá para https://portal.azure.com e procure seu grupo de recursos, que é rg-<your-environment-name>.

Usamos modelos do Bicep, que são encontrados em <your-project-directory-name>/infra, para provisionar recursos do Azure. Se houver problemas, incluiremos a mensagem de erro na saída da CLI.

Você também pode acessar https://portal.azure.com e 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, confira Solução de erros comuns de implantação do Azure - Azure Resource Manager.

em breve. Esse recurso está previsto para uma versão futura.

Sim.

Durante a implantação, azd primeiro detecta 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 em azure.yaml.

Embora seja recomendável usar 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.

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

em breve. Esse recurso está previsto 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 os recursos do Azure. Esse acesso é restrito pelas funções atribuídas à entidade de serviço, que oferece controle sobre quais recursos poderão ser acessados e em qual nível. Para obter mais informações sobre como autenticar do Azure para o GitHub, consulte Conectar o GitHub e o Azure | Microsoft Docs.

Não. O comando azd pipeline config cuida da criação da entidade de serviço do Azure e realiza 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 acessando https://github.com/<your-GH-account>/<your-repo>/secrets/actions.

Com o 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 o GitHub Actions e Azure Pipeline (definido como federado), ele não tem suporte o para Azure DevOps ou Terraform.

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

Vá para https://github.com/<your-GH-account>/<your-repo>settings/secrets/actions e 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 do 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>/actions e 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.