你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 Tanzu 的应用程序配置服务

项目
04/01/2024

注意

Azure Spring Apps 是 Azure Spring Cloud 服务的新名称。虽然该服务有新名称，但一些地方仍会使用旧名称，我们仍在更新屏幕截图、视频和图形等资产。

本文适用于：❌ 基本版/标准版 ✔️ 企业版

本文介绍如何将 VMware Tanzu 的应用程序配置服务与 Azure Spring Apps 企业计划配合使用。

VMware Tanzu 的应用程序配置服务是商业 VMware Tanzu 组件之一。它可以管理从一个或多个 Git 存储库中定义的属性填充的 Kubernetes 本机 ConfigMap 资源。

使用应用程序配置服务，可以集中管理所有环境中应用程序的外部属性。若要了解基本和标准计划中 Spring Cloud 配置服务器的差异，请参阅将 Azure Spring Apps 基本计划或标准计划实例迁移到企业计划中的将应用程序配置服务用于外部配置部分。

应用程序配置服务提供两个版本：Gen1 和 Gen2。 Gen1 版本主要服务现有客户，出于后向兼容的目的，仅支持到 2024 年 4 月 30 日。新服务实例应使用 Gen2。 Gen2 版本使用 flux 作为后端与 Git 存储库进行通信，并且与 Gen1 相比提供了更好的性能。

下表显示了子组件关系：

应用程序配置服务代系	子组件
Gen1	`application-configuration-service`
Gen2	`application-configuration-service` `flux-source-controller`

下表列出了一些基准数据，供你参考。然而，Git 存储库的大小是对性能数据产生重大影响的关键因素。建议在 Git 存储库中仅存储必要的配置文件，让其保持较小的规模。

应用程序配置服务代系	刷新不到 100 种模式的持续时间	刷新不到 250 种模式的持续时间	刷新不到 500 种模式的持续时间
Gen1	330 秒	840 秒	1500 秒
Gen2	13 秒	100 秒	378 秒

连接到远程 Git 存储库时，Gen2 还提供更多安全验证。如果使用 HTTPS，Gen2 需要安全连接，并在使用 SSH 连接时验证主机密钥和主机算法是否正确。

创建 Azure Spring Apps 企业服务实例时，可以选择应用程序配置服务的版本。默认版本为 Gen1。也可以在实例创建完后升级到 Gen2，但不支持降级。升级时不停机，但我们仍然建议你在迁移到生产环境之前在过渡环境中进行测试。

先决条件

已启用应用程序配置服务的已预配 Azure Spring Apps 企业计划实例。有关详细信息，请参阅快速入门：使用企业计划生成应用并将其部署到 Azure Spring Apps。

管理应用程序配置服务设置

应用程序配置服务支持使用 Azure DevOps、GitHub、GitLab 和 Bitbucket 来存储配置文件。

若要管理服务设置，请打开“设置”部分。在本部分中，可以配置以下关键方面：

代系：升级服务代系。
刷新间隔：调整服务从 Git 存储库检查更新的频率。
存储库：添加新条目或修改现有条目。此函数让你可以控制服务监视器用于拉取数据的存储库。

如果你当前的服务代系为 Gen1，则可以升级到 Gen2 以提高性能。有关详细信息，请参阅“从 Gen1 升级到 Gen2”部分。

刷新间隔指定了检查存储库中的更新的频率（以秒为单位）。最小值为 0，这会禁用自动刷新。为了获得最佳性能，请将此间隔设置为最小值 60 秒。

下表描述了每个存储库条目的属性：

properties	必需？	说明
`Name`	是	标记每个 Git 存储库的唯一名称。
`Patterns`	是	在 Git 存储库中进行搜索的模式。对于每种模式，请使用 {application} 或 {application}/{profile} 之类的格式，而不要使用 {application}-{profile}.yml。使用逗号分隔模式。有关详细信息，请参阅本文的模式部分。
`URI`	是	Git URI（例如，`https://github.com/Azure-Samples/piggymetrics-config` 或 `git@github.com:Azure-Samples/piggymetrics-config`）
`Label`	是	在 Git 存储库中进行搜索的分支名称。
`Search path`	否	可选搜索路径（以逗号分隔），用于搜索 Git 存储库的子目录。

模式

使用在模式中定义的内容从 Git 后端拉取配置。模式是 {application}/{profile} 的组合，如以下指导中所述。

{application} - 要检索其配置的应用程序的名称。值 application 被视为默认应用程序，包括跨多个应用程序共享的配置信息。任何其他值表示特定的应用程序，包括该特定应用程序的属性和默认应用程序的共享属性。
{profile} - 可选。你可以检索其属性的配置文件的名称。空值或值 default 包括在不同配置文件之间共享的属性。非默认值包括指定配置文件的属性和默认配置文件的属性。

身份验证

以下屏幕截图显示了应用程序配置服务支持的三种类型的存储库身份验证。

以下列表描述了三种身份验证类型：

公共存储库。

使用公共存储库时，不需要任何额外的身份验证配置。在“身份验证”窗体中选择“公共”。

下表显示了可用于设置公共 Git 存储库的可配置属性：

properties 必需？说明

CA certificate 否仅当自签名证书用于 Git 存储库 URL 时才需要。

properties	必需？	说明
`CA certificate`	否	仅当自签名证书用于 Git 存储库 URL 时才需要。

使用基本身份验证的专用存储库。

下表显示了可用于设置使用基本身份验证的专用 Git 存储库的可配置属性：

properties	必需？	说明
`username`	是	用于访问存储库的用户名。
`password`	是	用于访问存储库的密码。
`CA certificate`	否	仅当自签名证书用于 Git 存储库 URL 时才需要。

使用 SSH 身份验证的专用存储库。

下表显示了可用于设置使用 SSH 的专用 Git 存储库的可配置属性：

properties	必需？	说明
`Private key`	是	标识 Git 用户的私钥。不支持密码加密的私钥。
`Host key`	对 Gen1 来说为“否” 对 Gen2 来说为“是”	Git 服务器的主机密钥。如果在命令行上通过 Git 连接到服务器，则主机密钥位于 .ssh/known_hosts 文件中。不要包含算法前缀，因为它在 `Host key algorithm` 中指定。
`Host key algorithm`	对 Gen1 来说为“否” 对 Gen2 来说为“是”	`hostKey` 的算法：`ssh-dss`、`ssh-rsa`、`ecdsa-sha2-nistp256`、`ecdsa-sha2-nistp384` 和 `ecdsa-sha2-nistp521` 之一。（如果提供 `Host key`，则为必需项）。
`Strict host key checking`	否	可选值，指示在使用提供的 `Host key` 时，如果遇到错误，是否应忽略后端。有效值为 `true` 和 `false`。默认值为 `true`。

若要验证对目标 URI 的访问，请选择“验证”。验证成功完成后，选择“应用”以更新配置设置。

从 Gen1 升级到 Gen2

与 Gen1 相比，应用程序配置服务 Gen2 提供更好的性能，尤其是有大量配置文件时。建议使用 Gen2，特别是因为 Gen1 即将停用。从 Gen1 升级到 Gen2 时不停机，但我们仍然建议你在迁移到生产环境之前在过渡环境中进行测试。

使用 SSH 身份验证时，Gen2 需要比 Gen1 更多的配置属性。需要更新应用程序中的配置属性，以使其能够与 Gen2 配合使用。下表显示了使用 SSH 身份验证时 Gen2 所需的属性：

properties	说明
`Host key`	Git 服务器的主机密钥。如果在命令行上通过 Git 连接到服务器，则主机密钥位于 .ssh/known_hosts 文件中。不要包含算法前缀，因为它在 `Host key algorithm` 中指定。
`Host key algorithm`	`hostKey` 的算法：`ssh-dss`、`ssh-rsa`、`ecdsa-sha2-nistp256`、`ecdsa-sha2-nistp384` 或 `ecdsa-sha2-nistp521` 中的一个。

使用以下步骤从 Gen1 升级到 Gen2：

在 Azure 门户中，导航到 Azure Spring Apps 服务实例的“应用程序配置服务”页。
选择“设置”部分，然后在“代系”下拉菜单中选择“Gen2”。
选择“验证”以验证对目标 URI 的访问。验证成功完成后，选择“应用”以更新配置设置。

多语言支持

应用程序配置服务与 Spring Boot 应用程序无缝协作。服务生成的属性作为外部配置由 Spring Boot 导入并注入到 bean 中。无需编写额外的代码。可以使用通过 Spring 的环境抽象进行访问的 @Value 注释来使用这些值，也可以使用 @ConfigurationProperties 注释将它们绑定到结构化对象。

应用程序配置服务还支持多语言应用，例如 dotNET、Go、Python 等。若要访问你指定在应用的多语言应用部署期间加载的配置文件，请尝试访问可通过名称的环境变量检索的文件路径，例如 AZURE_SPRING_APPS_CONFIG_FILE_PATH。可以访问该路径下所有预期的配置文件。若要访问配置文件中的属性值，请使用应用的现有读/写文件库。

刷新策略

在 Git 存储库中修改和提交配置时，需要执行几个步骤，然后这些更改才会反映在应用程序中。此过程虽然是自动化的，但涉及以下不同的阶段和组件，每个阶段和组件都有自己的时机和行为：

应用程序配置服务轮询：应用程序配置服务定期轮询后端 Git 存储库以检测任何更改。此轮询以设置的频率进行，由刷新间隔定义。检测到更改后，应用程序配置服务会更新 Kubernetes ConfigMap。
ConfigMap 更新并与 kubelet 缓存交互：在 Azure Spring Apps 中，这个 ConfigMap 缓存作为数据卷装载到相关应用程序。但是，由于 kubelet 刷新缓存以识别 ConfigMap 中的更改的频率，此过程存在天然延迟。
应用程序读取更新的配置：在 Azure Spring Apps 环境中运行的应用程序可以访问更新的配置值。 Spring Context 中现有的 bean 不会自动刷新以使用更新的配置。

下图汇总了这些阶段：

可以调整应用程序配置服务的轮询刷新间隔，以满足特定需求。若要在应用程序中应用更新的配置，需要重启或刷新操作。

在 Spring 应用程序中，属性在 Spring Context 中保留或引用为 bean。若要加载新配置，请考虑使用以下方法：

重新启动应用程序。重启应用程序始终会加载新配置。
通过 Spring Actuator 调用在配置客户端上公开的 /actuator/refresh 终结点。

若要使用此方法，请将以下依赖项添加到配置客户端的 pom.xml 文件中。
```
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
```
还可通过添加以下配置来启用执行器终结点：
```
management.endpoints.web.exposure.include=refresh, bus-refresh, beans, env
```
通过调用 /actuator/refresh 终结点重新加载属性源后，具有注释 @RefreshScope 的 Bean 中与 @Value 绑定的属性将会刷新。
```
@Service
@Getter @Setter
@RefreshScope
public class MyService {
   @Value
   private Boolean activated;
}
```
将 curl 与应用程序终结点配合使用以刷新新配置，如以下示例所示：
```
curl -X POST http://{app-endpoint}/actuator/refresh
```
使用 FileSystemWatcher 监视文件更改并按需刷新上下文。 FileSystemWatcher 是一个附带 spring-boot-devtools 的类，用于监视特定目录的文件更改，你也可以使用另一个具有类似函数的实用工具。上一个选项要求用户主动启动刷新，而后者可以监视文件更改，并在检测到更新时自动调用刷新。可以使用环境变量 AZURE_SPRING_APPS_CONFIG_FILE_PATH 检索文件路径，如 Polyglot 支持部分所述。

使用以下步骤配置应用程序配置服务：

选择“应用程序配置服务”。
选择“概述”以查看分配给应用程序配置服务的运行状态和资源。
选择“设置”并在“存储库”部分添加一个包含 Git 后端信息的新条目。
选择“验证”以验证对目标 URI 的访问。验证成功完成后，选择“应用”以更新配置设置。

使用以下命令配置应用程序配置服务：

az spring application-configuration-service git repo add \
    --name <entry-name> \
    --patterns <patterns> \
    --uri <git-backend-uri> \
    --label <git-branch-name>

配置 TLS 证书以使用 Gen2 的自签名证书访问 Git 后端

此步骤是可选的。如果对 Git 后端使用自签名证书，则必须配置 TLS 证书才能访问 Git 后端。

需要先将证书上传到 Azure Spring Apps。有关详细信息，请参阅在 Azure Spring Apps 的应用程序中使用 TLS/SSL 证书的导入证书部分。

Azure 门户
Azure CLI

使用以下步骤配置 TLS 证书：

导航到服务资源，然后选择“应用程序配置服务”。
选择“设置”并在“存储库”部分添加或更新一个包含 Git 后端信息的新条目。

使用以下命令配置 TLS 证书：

az spring application-configuration-service git repo add \
    --name <entry-name> \
    --patterns <patterns> \
    --uri <git-backend-uri> \
    --label <git-branch-name> \
    --ca-cert-name <ca-certificate-name>

将应用程序配置服务与应用程序配合使用

将应用程序配置服务与 Git 后端配合使用并使用集中化配置时，必须将应用绑定到应用程序配置服务。

Azure 门户
Azure CLI

通过以下步骤将应用程序配置服务与应用程序配合使用：

打开“应用绑定”选项卡。
选择“绑定应用”，然后从下拉列表中选择一个应用。选择“应用”以绑定。

注意

更改绑定/取消绑定状态时，必须重启或重新部署应用才能使绑定生效。
在导航菜单中，选择“应用”以查看所有应用的列表。
为 name 列选择用于配置模式的目标应用。
在导航窗格中，选择“配置”，然后选择“常规设置”。
在“配置文件模式”下拉列表中，从列表中选择一个或多个模式。有关详细信息，请参阅模式部分。
选择“保存”。

通过以下命令将应用程序配置服务与应用程序配合使用：

az spring application-configuration-service bind --app <app-name>
az spring app deploy \
    --name <app-name> \
    --artifact-path <path-to-your-JAR-file> \
    --config-file-pattern <config-file-pattern>

将应用绑定到应用程序配置服务

现在，你可以选择在创建新应用时将应用程序绑定到应用程序配置服务。

Azure 门户
Azure CLI

使用以下步骤创建新应用并将其绑定到应用程序配置服务：

在导航窗格中，选择“应用”以查看所有应用。
选择 创建应用 以创建新应用。
输入新应用的名称。
选择“绑定”选项卡，然后从下拉列表中选择“应用程序配置服务”。
选择“创建”以完成应用的创建并将其绑定到应用程序配置服务。

使用以下命令创建新应用并将其绑定到应用程序配置服务：

az spring app create \ 
    --resource-group <resource-group> \ 
    --service <service-name> \ 
    --name <app-name> \ 
    --bind-application-configuration-service

在创建服务后启用/禁用应用程序配置服务

可以在创建服务后使用 Azure 门户或 Azure CLI 启用和禁用应用程序配置服务。在禁用应用程序配置服务之前，需要取消所有应用与它的绑定。

Azure 门户
Azure CLI

使用以下步骤启用或禁用应用程序配置服务：

导航到服务资源，然后选择“应用程序配置服务”。
选择“管理”。
选择或取消选择“启用应用程序配置服务”，然后选择“保存”。
现在可以在“应用程序配置服务”页上查看应用程序配置服务的状态。

使用以下命令启用或禁用应用程序配置服务：

az spring application-configuration-service create \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-service-instance-name>

az spring application-configuration-service delete \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-service-instance-name>

检查 ConfigMap 中的配置文件

以下部分演示如何检查应用程序配置服务从相关 Kubernetes ConfigMap 中的上游 Git 存储库拉取的配置文件的内容。有关详细信息，请参阅本文的刷新策略部分。

分配 Azure 角色

首先，必须为自己分配 Azure 角色 Azure Spring Apps Application Configuration Service Config File Pattern Reader Role。

Azure 门户
Azure CLI

使用以下步骤分配 Azure 角色：

打开 Azure 门户并转到 Azure Spring Apps 服务实例。
在导航窗格中，选择“访问控制(IAM)”。
在“访问控制(IAM)”页上选择“添加”，然后选择“添加角色分配”。
在“添加角色分配”页上的“名称”列表中，搜索并选择目标角色，然后选择“下一步”。
选择“成员”，然后搜索并选择你的用户名。
选择“查看 + 分配”。

使用以下命令分配 Azure 角色：

az role assignment create \
    --role "Azure Spring Apps Application Configuration Service Config File Pattern Reader Role" \
    --scope "<service-instance-resource-id>" \
    --assignee "<your-identity>"

使用 Azure CLI 检查配置文件

使用以下命令按模式查看配置文件的内容：

az spring application-configuration-service config show \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --config-file-pattern <pattern>

此命令会生成类似于以下示例的 JSON 输出：

{
  "configurationFiles": {
    "application.properties": [
      "example.property.application.name: example-service",
      "example.property.cloud: Azure"
    ]
  },
  "metadata": {
    "gitRevisions": "[{\"url\":\"{gitRepoUrl}\",\"revision\":\"{revisionInfo}\"}]"
  }
}

注意

metadata 和 gitRevisions 属性不适用于应用程序配置服务的 Gen1 版本。

还可以将此命令与 --export-path {/path/to/target/folder} 参数结合使用，将配置文件导出到指定的文件夹。它支持相对路径和绝对路径。如果未指定路径，则命令默认使用当前目录的路径。

检查应用程序中的配置文件

将应用程序绑定到应用程序配置服务并设置应用程序部署的模式后，如本文的将应用程序配置服务与应用程序结合使用部分所述，包含该模式配置文件的 ConfigMap 应装载到应用程序容器。使用以下步骤检查应用程序部署的每个实例中的配置文件：

连接到其中一个应用程序实例。有关详细信息，请参阅连接到应用实例进行故障排除。

使用 echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH 命令查找包含配置文件的文件夹。位置列表以逗号分隔，如以下示例所示：

  $ echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH
  /etc/azure-spring-cloud/configmap/acs-default-payment-default-e9d46,/etc/azure-spring-cloud/configmap/acs-default-catalog-default-616f4

使用命令（例如 cat）检查配置文件的内容。

注意

应用中不提供 Git 修订信息。

检查日志

以下部分介绍如何使用 Azure CLI 或 Azure 门户查看应用程序日志。

使用实时日志流式处理

可以使用 Azure CLI 实时流式处理日志。有关详细信息，请参阅实时流式处理 Azure Spring Apps 托管组件日志。以下示例演示如何使用 Azure CLI 命令持续流式处理 application-configuration-service 和 flux-source-controller 子组件的新日志。

使用以下命令流式处理 application-configuration-service 的日志：

az spring component logs \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name application-configuration-service \
    --all-instances \
    --follow

使用以下命令流式处理 flux-source-controller 的日志：

az spring component logs \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name flux-source-controller \
    --all-instances \
    --follow

使用 Log Analytics

以下部分介绍如何使用 Log Analytics 启用并查看系统日志。

Log Analytics 的诊断设置

在查询应用程序配置服务的日志之前，必须启用系统日志并将日志发送到 Log Analytics 实例。若要在 Azure 门户中启用系统日志，请使用以下步骤：

打开 Azure Spring Apps 实例。
在导航窗格中，选择“诊断设置”。
选择“添加诊断设置”或为现有设置选择“编辑设置”。
在“日志”部分，选择“系统日志”类别。
在“目标详细信息”部分，选择“发送到 Log Analytics 工作区”，然后选择你的工作区。
选择“保存”以更新设置。

在 Log Analytics 中检查日志

若要使用 Azure 门户检查 application-configuration-service 和 flux-source-controller 的日志，请使用以下步骤：

确保启用了“系统日志”。有关详细信息，请参阅 Log Analytics 的诊断设置部分。
打开 Azure Spring Apps 实例。
在导航菜单中选择“日志”，然后选择“概述”。

在查询编辑窗格中使用以下示例查询。调整时间范围，然后选择“运行”以搜索日志。

若要查看 application-configuration-service 的日志，请使用以下查询：

AppPlatformSystemLogs
| where LogType in ("ApplicationConfigurationService")
| project TimeGenerated , ServiceName , LogType, Log , _ResourceId
| limit 100

若要查看 flux-source-controller 的日志，请使用以下查询：

AppPlatformSystemLogs
| where LogType in ("Flux")
| project TimeGenerated , ServiceName , LogType, Log , _ResourceId
| limit 100

注意

日志在 Log Analytics 中可用之前可能会有几分钟的延迟。

排查已知问题

如果应用程序中未反映最新的更改，请根据刷新策略部分检查以下项：

通过检查以下项确认 Git 存储库已正确更新：
- 确认所需的配置文件更改的分支已更新。
- 确认应用程序配置服务中配置的模式与更新后的配置文件匹配。
- 确认应用程序绑定到了应用程序配置服务。
确认包含应用程序使用的模式配置文件的 ConfigMap 已更新，如本文的检查 ConfigMap 中的配置文件部分所述。如果未更新，请提交票证。
确认 ConfigMap 已作为文件装载到应用程序，如本文检查应用程序中的配置文件部分所述。如果文件未更新，请等待 Kubernetes 刷新间隔（1 分钟），或通过重启应用程序强制刷新。

检查这些项后，应用程序应该能够读取更新后的配置。如果应用程序仍未更新，请提交票证。

Azure Spring Apps