Azure 开发人员 CLI 常见问题解答

卸载 azd 有不同的选项，具体取决于最初安装的方式。 有关详细信息，请访问 安装页。

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

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

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

Azure 开发人员 CLI 使用环境名称设置 Azure 开发人员 CLI 模板使用的 AZURE_ENV_NAME 环境变量。 AZURE_ENV_NAME还用于为 Azure 资源组名称添加前缀。 由于每个环境都有自己的配置集，因此 Azure 开发人员 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 文件。 例如，azd deploy 等命令还会使用 db 连接字符串和 Azure Key Vault 终结点更新 .env 文件。

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

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

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

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

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

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

对于将来的运行，还应使用 Bicep 将 secretOrRandomPassword 的输出保存到 Key Vault。 跨部署检索和重用相同机密可能会阻止在重复生成新值时出现的错误或意外行为。 若要创建 Key Vault 并将生成的机密存储在其中，请使用下面的 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 函数从 Key Vault 中检索它。
2. 如果机密不存在，则会创建 Key Vault，并且随机生成的机密存储在其中。
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 开发”创作模板允许配置资源的名称。 为此，可以将条目添加到 infra 文件夹中的 main.parameters.json。 例如：

  "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>资源组。

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

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

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

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

是的。

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

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

部署项目时，可以选择通过在命令（即 azd deploy api）中指定服务名称或导航到仅包含要部署的服务的子文件夹来部署特定服务。 执行此操作时，所有其他服务将列为 - Skipped。

如果不想跳过任何服务，请确保从根文件夹运行命令，或将 --all 标志添加到命令。

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

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

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。