Perguntas frequentes sobre a CLI do Desenvolvedor do Azure

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

CLI do Desenvolvedor do Azure (azd) e CLI do Azure (az) são ferramentas de linha de comando, mas ajudam você a realizar 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 de 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 no computador local.
2. Para efetuar pull do env existente criado usando codespaces, execute azd env refresh. Certifique-se de fornecer o mesmo nome de ambiente, assinatura e localização 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 para usar.

O exemplo a seguir demonstra um caso de uso comum do secretOrRandomPassword em um arquivo de 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 salva no Key Vault usando o Bicep para execuções futuras. A recuperação e a reutilização dos mesmos segredos entre implantações podem 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. Você pode exibir o código de exemplo completo desses módulos no do 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 Key Vault 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 Key Vault. O Key Vault não será recriado se ele 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 selecionado do Azure, 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.

Nossos modelos de criação do '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 quando tentar criar o recurso.

O comando usa modelos 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 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 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 Solucionar problemas comuns de erros de implantação do Azure –do Azure Resource Manager.

Em breve. Esse 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 corresponde ao nome do serviço de azure.yaml.

Embora seja recomendável usar marcas 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 contém apenas os serviços que você deseja implantar. Ao fazer isso, todos os outros serviços serão listados como - Skipped.

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

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

Em breve. Esse 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 fornece controle sobre quais recursos podem 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 executar as etapas necessárias para armazenar os segredos em seu repositório do 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 do OpenID Connect, seus fluxos de trabalho podem trocar tokens de curta duração diretamente do Azure.

Embora o OIDC tenha suporte como o padrão para o GitHub Actions e o Azure Pipeline (definido como federados), não há suporte para o Azure DevOps ou o Terraform.

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

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