Azure Developer CLI FAQ

根据最初安装的安装方式，有不同的卸载 azd 选项。 有关详细信息， 请访问安装页 。

Azure 开发人员 CLI （azd） 和 Azure CLI （az） 都是命令行工具，但它们可帮助你执行不同的任务。

azd 重点介绍高级开发人员工作流。 除了预配/管理 Azure 资源外， azd 还有助于将云组件、本地开发配置和管道自动化组合到一个完整的解决方案中。

Azure CLI 是用于创建和管理 Azure 基础结构（例如虚拟机、虚拟网络和存储）的控制平面工具。 Azure CLI 围绕特定管理任务的精细命令进行设计。

Azure Developer CLI 使用环境名称来设置 Azure Developer CLI 模板使用的 AZURE_ENV_NAME 环境变量。 AZURE_ENV_NAME 还可用于为 Azure 资源组名称添加前缀。 由于每个环境都有自己的一组配置，Azure Developer CLI 将所有配置文件存储在环境目录中。

├── .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 

是的。 可以设置各种环境（例如开发、测试、生产）。 可以使用 azd env 来管理这些环境。

.env 文件路径为 <your-project-directory-name>\.azure\<your-environment-name>\.env。

在 Azure 开发人员 CLI 中 azd ，命令引用环境配置的 .env 文件。 例如，使用 db 连接字符串 和 Azure 密钥库 终结点更新 .env 文件等azd deploy命令。

是的。 可以在本地继续开发工作。

1. 运行 azd init -t <template repo> 以将模板项目克隆到本地计算机。
2. 若要拉取使用 Codespaces 创建的现有 env，请运行 azd env refresh。 请确保提供与以前相同的环境名称、订阅和位置。

azure.yaml 文件描述模板中包含的 Azure 资源的应用和类型。

如果提供了密钥保管库名称和机密的参数，该secretOrRandomPassword函数将从 Azure 密钥库检索机密。 如果未提供这些参数或无法检索机密，函数将改为返回随机生成的密码以改用。

以下示例演示文件中的secretOrRandomPasswordmain.parameters.json常见用例。 将${AZURE_KEY_VAULT_NAME}变量sqlAdminPassword作为参数传递给密钥库和机密的名称。 如果无法检索该值，则会生成随机密码。

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

还应将 的secretOrRandomPassword输出保存到使用 Bicep 进行将来运行的密钥库。 跨部署检索和重用相同机密可能会阻止在重复生成新值时出现的错误或意外行为。 若要创建密钥库并将生成的机密存储在其中，请使用下面的 Bicep 代码。 可以在 Azure 开发人员 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
  }
}]

此 Bicep 设置启用以下工作流来管理机密：

1. 如果指定的机密存在，则使用函数secretOrRandomPassword从密钥库检索它。
2. 如果机密不存在，则会创建一个密钥库，并且随机生成的机密存储在其中。
3. 在将来的部署中，该方法secretOrRandomPassword会检索存储在密钥库中的机密。 如果密钥库已存在，则不会重新创建该密钥库，但下次运行时将再次存储相同的机密值。

是的，但每个 Azure 位置只能有一个部署。 如果已使用所选 Azure 位置，将看到部署错误：

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.

可以选择其他 Azure 位置来解决此问题。

这可能是因为我们用于命名资源的方法。

我们的“Azure 开发”创作模板允许配置资源的名称。 为此，可以向文件夹中添加一个条目main.parameters.jsoninfra。 例如：

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

该条目会在下次预配应用程序时创建名为“my-unique-name”的新资源，而不是随机值，例如“app-web-aj84u2adj”。 可以使用 Azure 门户手动删除旧资源组，也可以运行 azd down 以删除所有以前的部署。 删除资源后，请运行 azd provision 以使用新名称再次创建它们。

此名称需要全局唯一，否则在尝试创建资源期间 azd provision 会收到 ARM 错误。

该命令使用 Bicep 模板，该模板可用于 <your-project-directory-name>/infra 预配 Azure 资源。

转到 https://portal.azure.com 并查找资源组，即 rg-<your-environment-name>。

我们使用 Bicep 模板（位于该模板下 <your-project-directory-name>/infra）来预配 Azure 资源。 如果出现问题，我们会在 CLI 输出中包含错误消息。

还可以转到 https://portal.azure.com ，然后查找资源组，即 rg-<your-environment-name>。 如果任一部署失败，请选择错误链接以获取详细信息。

有关其他资源，请参阅排查常见的 Azure 部署错误 - Azure 资源管理器。

即将推出。 此功能已计划在将来的版本中推出。

是的。

在部署期间， azd 首先通过查找标记的 azd-env-name 组以及与环境名称匹配的值来发现构成应用程序的所有资源组。 然后，它枚举每个资源组中的所有资源，查找使用 azd-service-name 与服务 azure.yaml名称匹配的值标记的资源。

虽然我们建议对资源使用标记，但也可以使用 resourceName 该 azure.yaml 属性来提供显式资源名称。 在这种情况下，上述逻辑未运行。

是的。 我们使用 增量部署模式。

即将推出。 此功能已计划在将来的版本中推出。

Azure 服务主体是创建用于应用、托管服务和自动化工具以访问 Azure 资源的标识。 此访问受分配给服务主体的角色的限制，该角色可让你控制可以访问的资源和级别。 有关从 Azure 到 GitHub 进行身份验证的详细信息，请参阅 连接 GitHub 和 Azure |Microsoft Docs。

不是。 该 azd pipeline config 命令负责创建 Azure 服务主体并执行必要的步骤，将机密存储在 GitHub 存储库中。

此命令在 GitHub 中存储四个机密：AZURE_CREDENTIALS、AZURE_ENV_NAME、AZURE_LOCATION和AZURE_SUBSCRIPTION_ID。 可以转到 https://github.com/<your-GH-account>/<your-repo>/secrets/actions 来替代每个机密的值。

借助 OpenID Connect，工作流可以直接从 Azure 交换生存期较短的令牌。

虽然 OIDC 作为 GitHub Actions 和 Azure Pipeline（设置为 联合）的默认值受支持，但 Azure DevOps 或 Terraform 不支持它。

• 对于 Azure DevOps，显式调用--auth-typefederated将导致错误。
• 对于 Terraform：
  • 如果未 --auth-type 定义，它将回退并 clientcredentials 导致警告。
  • 如果 --auth-type 显式设置为 federated，则会导致错误。

转到 https://github.com/<your-GH-account>/<your-repo>settings/secrets/actions，然后通过复制并粘贴新服务主体的整个 JSON 对象进行更新 AZURE_CREDENTIALS 。 例如：

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

GitHub Actions 文件路径为 <your-project-directory-name>\.github\workflows\azure-dev.yml.

是的。 将 run: azd up --no-prompt 替换为 run: azd deploy --no-prompt。

转到 https://github.com/<your-GH-account>/<your-repo>/actions，然后引用工作流运行中的日志文件。

在本地生成容器应用程序时，需要在容器中运行 azd auth login ，以便应用程序能够使用 AzureDeveloperCliCredential。 或者，可以将应用程序配置为使用服务主体而不是 AzureDeveloperCliCredential服务主体。