FAQ sobre o Azure Developer CLI

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

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

azd Concentra-se no fluxo de trabalho do desenvolvedor de alto nível. Além de provisionar/gerenciar recursos do Azure, ajuda a unir componentes de nuvem, azd 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.

O Azure Developer CLI utiliza um nome de ambiente para definir a variável de ambiente AZURE_ENV_NAME que é utilizada pelos modelos doe Azure Developer CLI. AZURE_ENV_NAME também é utilizado para prefixar o nome do grupo de recursos do Azure. Uma vez que 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 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). Pode utilizar azd env para gerir esses ambientes.

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

Na CLI do Azure Developer, os comandos referem-se ao arquivo .env para configuração do azd ambiente. Comandos como azd deploy também atualizar 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 secretOrRandomPassword função 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 usar.

O exemplo a seguir demonstra um caso de uso comum do secretOrRandomPassword em um main.parameters.json arquivo. As ${AZURE_KEY_VAULT_NAME} variáveis e são passadas como parâmetros para os nomes do Cofre de Chaves e sqlAdminPassword 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 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 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 de Chaves usando a secretOrRandomPassword função.
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 recupera o secretOrRandomPassword segredo armazenado agora que ele existe no Cofre da Chave. 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 para o main.parameters.json na infra pasta. 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 a tentativa de 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 o 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 obter outros recursos, consulte Solucionar erros comuns de implantação do Azure - Azure Resource Manager.

Disponível 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 e com azd-env-name 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 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 resourceName propriedade in 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.

Disponível 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 | Documentos Microsoft.

Não O azd pipeline config comando cuida de criar a entidade de serviço do Azure e executar 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 o OpenID Connect, os fluxos de trabalho podem trocar tokens de curta duração diretamente a partir 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 Terraform.

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

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

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

O caminho do arquivo de ações do GitHub é <your-project-directory-name>\.github\workflows\azure-dev.yml.

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