Azure Developer CLI FAQ

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

Azure Developer 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 Developer CLI 中，azd 命令引用 .env 文件进行环境配置。 诸如 azd deploy 之类的命令也会使用例如 db 连接字符串和 Azure 密钥保管库终结点来更新 .env 文件。

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

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

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

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

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

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

还应使用 Bicep 将 secretOrRandomPassword 的输出保存到密钥保管库中，以便将来运行。 跨部署检索和重用相同机密可以防止在重复生成新值时出现错误或意外行为。 若要创建密钥保管库并将生成的机密存储在其中，请使用下面的 Bicep 代码。 可以在 Azure Developer 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 Dev”创作模板允许配置资源的名称。 为此，你可以向 infra 文件夹中的 main.parameters.json 添加一个条目。 例如：

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

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

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

该命令使用位于 <your-project-directory-name>/infra 下的 Bicep 模板来预配 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 中的服务名称匹配。

虽然建议对资源使用标记，但也可以使用 azure.yaml 中的 resourceName 属性来提供明确的资源名称。 在这种情况下，上述逻辑不会运行。

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

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

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-type 调用为 federated 将导致错误。
• 对于 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。