Apereo CAS 配置服务器（Spring Cloud Configuration Server）完整指南：部署、安全、客户端接入与多源配置

导读

本文围绕 Apereo CAS 的 Spring Cloud 配置服务器（Configuration Server） 展开，系统讲解如何将 CAS 部署中的状态与设置外置到一台集中式配置服务器上，从文件系统、Git/SVN 仓库、MongoDB、Vault 等多种来源统一获取配置。读完本文，你将掌握配置服务器 Overlay 的部署方式、内置端点的安全与调用方法、CAS Web 应用作为配置客户端的 bootstrap.properties 接入细节，以及通过 Native、Git、SVN 等多 Profile 组合与 overrides 覆盖机制管理多环境配置的完整实战方案。

提示：CAS 在配置管理上有两大策略，默认采用 Standalone（独立模式），而本文介绍的 Spring Cloud 是外部化策略，专为云化、分布式部署设计。两者详细对比可参考 Configuration Server。

为什么需要 Spring Cloud 配置服务器

CAS 能够通过一个外部的、集中的配置服务器来获取运行状态与全部设置。对 CAS（以及所有其他客户端应用）而言，配置服务器提供了一个高度抽象的途径，使其可以从文件系统、git 或 svn 仓库、MongoDB 数据库、Vault 等多种来源获取配置。

这套方案的精妙之处在于：对 CAS Web 应用服务器来说，设置来自哪里并不重要，它完全不知道底层属性源（property source）的细节——它只需要与配置服务器通信、定位设置并继续运行即可。

从安全角度看，这也是一种非常优秀的策略：

将配置集中托管，可以确保配置设置不会散落在各个部署环境中，从而让部署更加安全。配置服务器无需暴露给外部世界，可以安全地隐藏在网络防火墙之后，只允许像 CAS 服务器 Web 应用这样的授权客户端访问。

关于配置管理整体策略、配置安全性（加密）以及配置热加载能力，可分别参阅 Configuration Management、Configuration Properties Security 与 Configuration Management Reload。

Spring Cloud 配置服务器 Overlay 部署

配置服务器本身与 CAS 类似，可以通过 CAS Initializr 以 Overlay 方式部署，对应的模块为 org.apereo.cas:cas-server-webapp-config-server。该模块构建的是一个 WAR 包，其入口类在仓库中为 org.apereo.cas.CasConfigurationServerWebApplication（见 CasConfigurationServerWebApplication.java）：

@SpringBootApplication(proxyBeanMethods = false)
@EnableConfigServer
public class CasConfigurationServerWebApplication {
    public static void main(final String[] args) {
        new SpringApplicationBuilder(CasConfigurationServerWebApplication.class)
            .banner(new CasConfigurationServerBanner())
            .bannerMode(Banner.Mode.CONSOLE)
            .web(WebApplicationType.SERVLET)
            .logStartupInfo(true)
            .run(args);
    }
}

可以看到，它通过 @EnableConfigServer 启用 Spring Cloud Config Server 能力，并以 Servlet（内嵌 Tomcat）方式启动，构建配置见 build.gradle。

配置加载顺序

除了 Configuration Management 中概述的策略外，配置服务器可以按以下顺序与机制加载 CAS 设置与属性：

1. 包外、Profile 专属的应用程序属性（application-{profile}.properties|yml）
2. 包内、Profile 专属的应用程序属性（application-{profile}.properties|yml）
3. 包外的应用程序属性（application.properties|yml）
4. 包内的应用程序属性（application.properties|yml）

默认运行行为

配置服务器的行为由其自身的 src/main/resources/bootstrap.properties 控制。仓库中该文件的实际内容如下（见 bootstrap.properties）：

spring.application.name=casconfigserver
spring.profiles.active=native
spring.cloud.config.server.native.search-locations=file:///etc/cas/config

spring.jmx.default-domain=casconfigserver

spring.cloud.config.server.encrypt.enabled=true

encrypt.key-store.location=file:///etc/cas/casconfigserver.jks
encrypt.key-store.password=changeit
encrypt.key-store.alias=cas
encrypt.key-store.secret=changeit

默认情况下，配置服务器：

• 运行在 内嵌 Apache Tomcat 中，端口为 8888，上下文路径为 /casconfigserver（见 application.properties）；
• 端点通过 Basic 认证保护，默认用户名为 casuser，密码为 application.properties 中定义的自动生成密码（仓库示例中注释了 spring.security.user.password=Mellon，即默认口令可自行指定）；
• 默认激活 native Profile，其细节见下文"Native Profile"部分。

该 WAR 还同时配置了 TLS（server.ssl.key-store 等）与 Actuator 端点暴露（management.endpoints.web.exposure.include=env,info,health），供生产环境启用 HTTPS 与运维监控。

配置服务器暴露的端点

配置服务器暴露并保护以下端点：

端点	说明
/encrypt	接受 POST 请求，用于加密 CAS 配置设置
/decrypt	接受 POST 请求，用于解密 CAS 配置设置
/actuator/refresh	接受 POST 请求，尝试刷新配置服务器的内部状态
/actuator/env	接受 GET 请求，描述配置服务器的所有配置来源
/actuator/cas/default	描述配置服务器对 default 设置 Profile 的认知
/actuator/cas/native	描述配置服务器对 native 设置 Profile 的认知

验证部署是否成功

部署好配置服务器后，假设用于保护配置服务器的凭据与下面的示例一致，可以观察其设置集合：

curl -u casuser:Mellon https://config.server.url:8888/casconfigserver/cas/native

假设配置中启用了 Actuator 端点，还可以观察为配置服务器提供设置的属性源集合：

curl -u casuser:Mellon https://config.server.url:8888/casconfigserver/actuator/env

注意：Actuator 端点通常带有 /actuator 前缀。若配置服务器启用了 HTTPS，上述示例中请使用 https 协议。

Actuator 端点

CAS 为配置服务器提供以下 Actuator 端点：

• health：健康检查端点，其中包含 refresh 与 configServerHealthIndicator 健康指示器；
• casConfig：CAS 配置端点。

与配置服务器健康相关的属性以 spring.cloud.config.server.health 为前缀（第三方属性），可在 CAS 属性文档中检索到完整清单。

Spring Cloud 配置服务器客户端（CAS Web 应用接入）

要让 CAS 服务器 Web 应用（或其他任何客户端）与配置服务器通信，需要在 CAS 自己的 src/main/resources/bootstrap.properties 中应用以下设置。配置 CAS Web 应用作为配置服务器客户端的属性，必须在引导（bootstrap）阶段、在其余应用配置从配置服务器读取之前被读取，这一点至关重要。

spring.application.name=cas
spring.profiles.active=native
spring.cloud.config.uri=https://config.server.url:8888/casconfigserver
spring.cloud.config.username=casuser
spring.cloud.config.password=Mellon

其中 spring.cloud.config.* 一族的属性即为客户端接入配置（完整清单可在 CAS 属性文档中以 spring.cloud.config 前缀检索）。

配置来源的路径绑定规则

请记住，配置服务器向应用提供 /{name}/{profile}/{label} 形式的属性源，客户端应用中的默认绑定如下：

"name"    = ${spring.application.name}
"profile" = ${spring.profiles.active}
"label"   = "master"

三者都可以通过设置 spring.cloud.config.*（其中 * 为 name、profile 或 label）来覆盖：

• label 对回滚到之前的配置版本非常有用；在默认的 Config Server 实现中，它可以是 git 标签、分支名或 commit id；
• label 还可以提供逗号分隔的列表，此时列表中的条目会按顺序逐个尝试，直到某一个成功为止。这在处理特性分支时尤其有用——例如你希望让配置 label 与自己的分支对齐，但又允许失败回退：

spring.cloud.config.label=myfeature,develop

关于 CAS 如何允许你重新加载配置变更，请参阅 Configuration Management Reload。

Spring Cloud 配置服务器配置源（Profiles）

存在多种配置 Profile，用于决定配置服务器应该如何获取属性与设置：

• Default
• Native
• REST
• Amazon S3
• Amazon Secret Manager
• Amazon SSM
• Azure KeyVault
• DynamoDb
• Etcd
• HashiCorp Consul
• HashiCorp Vault
• JDBC
• MongoDb
• ZooKeeper
• GCP Secret Manager

Native Profile（默认）

配置服务器默认配置为从外部位置 /etc/cas/config 加载 cas.(properties|yml) 文件（详见 Configuration Server Management SpringCloud Native）：

• 该位置会被服务器持续监控以检测外部变更；
• 该目录必须存在，但不需要特殊权限或结构；
• 放入该目录的配置文件名必须与 spring.application.name 匹配（即 cas.properties）。

如需使用额外的配置文件，其命名必须形如 application-<profile>.(properties|yml)。application.(properties|yml) 文件默认会被包含。Profile 专属文件可以通过 spring.profiles.include 配置选项激活，该选项由 src/main/resources/bootstrap.properties 控制：

spring.profiles.active=native
spring.cloud.config.server.native.search-locations=file:///etc/cas/config
spring.profiles.include=profile1,profile2

外部 .properties 文件示例：

cas.server.name=...

你完全可以使用 cas.yml 文件来承载这些配置。注意默认 Profile 通过 spring.profiles.active=native 激活。

配置服务器内直接使用云配置模块

上述云配置模块也可以原样（verbatim）用于 CAS 服务器 Overlay 内部。请记住，这些模块的主要目标是从某个来源获取设置与属性：

• 它们在 Spring Cloud 配置服务器内部激活时最为常用，并且可以设置以尊重 Profile 等；
• 但它们同样可以直接在 CAS 服务器 Overlay 内使用，以独立（standalone）模式直接从某个来源获取设置。

在这种场景下，所有配置来源（无论格式或语法如何）都会协同工作以获取设置，你可以按照自己的需要自由地混合搭配。

Composite Sources：组合多个配置仓库

在某些场景下，你可能希望从多个环境仓库拉取配置数据。为此，只需在配置服务器的 application 属性或 YAML 文件中启用多个 Profile 即可。例如，如果你想同时从 Git 仓库和 SVN 仓库拉取配置数据，可以为配置服务器设置以下属性：

spring:
  profiles:
    active: git, svn
  cloud:
    config:
      server:
        svn:
          uri: file:///path/to/svn/repo
          order: 2
        git:
          uri: file:///path/to/git/repo
          order: 1

除了为每个仓库指定 uri 之外，还可以指定 order 属性。order 属性允许你为所有仓库指定优先级顺序：

• order 的数值越小，优先级越高；
• 仓库的优先级顺序有助于解决多个仓库包含同一属性值时的潜在冲突。

Property Overrides：配置服务器强制覆盖

配置服务器具有"覆盖（overrides）"特性，允许运维人员向所有应用提供配置属性，且这些属性无法被应用通过常规的变更事件与钩子意外修改。要声明覆盖，只需向 spring.cloud.config.server.overrides 添加一个键值对映射即可。

例如：

spring:
  cloud:
    config:
      server:
        overrides:
          foo: bar

这将导致 CAS 服务器（作为配置服务器的客户端）独立于自身配置地读取到 foo=bar。

小结

本文从部署、安全、客户端接入与多源配置四个维度完整介绍了 Apereo CAS 的 Spring Cloud 配置服务器：

1. 部署：通过 CAS Initializr 以 cas-server-webapp-config-server Overlay 构建，默认运行于 8888//casconfigserver，由 bootstrap.properties 控制加载顺序与默认 native Profile；
2. 安全：Basic 认证（casuser + 自动生成密码）保护全部端点，/encrypt 与 /decrypt 支持配置值加解密，服务器可隐藏于防火墙之后仅暴露给授权客户端；
3. 客户端接入：CAS 在自身 bootstrap.properties 中通过 spring.cloud.config.* 系列属性连接配置服务器，/name/profile/label 路径绑定与 label 回滚机制保障了多环境与版本化配置；
4. 多源配置：通过激活多个 Profile 实现 Composite Sources 组合（如 Git + SVN），通过 overrides 实现运维级强制覆盖，Native/Default/REST/云厂商等十余种 Profile 可灵活选用。

这套集中式外部化配置方案，是 CAS 从开发、测试走向生产、从单机走向集群与云部署时管理配置一致性与安全性的核心基础设施。