1.3.8.RELEASE
Spring Cloud Config为分布式系统中的外部化配置提供服务器和客户端支持。通过Config Server，您可以在所有环境中管理应用程序的外部属性。客户端和服务器的概念与Spring Environment和PropertySource抽象一致，所以它们非常适合Spring应用程序，当然运行任何语言中的任何应用程序也可以使用Spring Cloud Config。随着应用程序从开发环境到测试环境到生产环境，您可以管理这些环境之间的配置，并确保应用程序在转移时具有所需的所有内容。后端的Server存储的默认实现使用git，因此它可以轻松支持configuration environments的标签版本，并且这个Server可以被管理内容的广泛的工具访问。使用Spring配置很容易添加替代实现并将其插入。
4. Quick Start
Start the server:
$ cd spring-cloud-config-server $ ../mvnw spring-boot:run
服务器是Spring Boot应用程序，所以如果您愿意，您可以从IDE运行它（主要类是ConfigServerApplication）。然后尝试一个客户端：
$ curl localhost:8888/foo/development
{"name":"foo","label":"master","propertySources":[
{"name":"https://github.com/scratches/config-repo/foo-development.properties","source":{"bar":"spam"}},
{"name":"https://github.com/scratches/config-repo/foo.properties","source":{"foo":"bar"}}
]}
定位属性源的默认策略是克隆git仓库（在spring.cloud.config.server.git.uri）并使用它来初始化一个小型的SpringApplication。迷你应用程序的Environment用于枚举属性源并通过JSON端点发布它们。
HTTP服务具有以下形式的资源：
/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
在上面的例子中，“application”是SpringApplication中的spring.config.name（常规Spring Boot应用程序中通常是“application”），“profile”是active profile（或逗号分隔的properties list），和“label”是一个可选的git标签（默认为“master”）。
Spring Cloud Config Server从git仓库（必须提供）中为远程客户端提取配置：
spring: cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo
4.1 Client Side Usage
要在应用程序中使用这些功能，只需将其构建为依赖于spring-cloud-config-client的Spring Boot应用程序（例如，see the test cases for the config-client, or the sample app）。添加依赖项的最方便的方法是通过一个Spring Boot starter org.springframework.cloud:spring-cloud-starter-config。对于Maven用户还有一个父pom和BOM（spring-cloud-starter-parent）。示例Maven配置：
pom.xml.
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.10.RELEASE</version> <relativePath /> <!-- lookup parent from repository --> </parent> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Edgware.SR2</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> <!-- repositories also needed for snapshots and milestones -->
然后你可以创建一个标准的Spring Boot应用程序，就像这个简单的HTTP服务器一样
@SpringBootApplication
@RestController
public class Application {
@RequestMapping("/")
public String home() {
return "Hello World!";
}
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
运行时，它将从端口8888上的默认本地配置服务器接收外部配置（如果它正在运行）。要修改启动行为，可以使用bootstrap.properties（like application.properties but for the bootstrap phase of an application contex）来更改配置服务器的location，例如，
spring.cloud.config.uri: http://myconfigserver.com
bootstrap properties 将作为高优先级属性源显示在/ env端点中，例如，
$ curl localhost:8080/env
{
"profiles":[],
"configService:https://github.com/spring-cloud-samples/config-repo/bar.properties":{"foo":"bar"},
"servletContextInitParams":{},
"systemProperties":{...},
...
}名为“
configService:<URL of remote repository>/<file name>的属性源包含
{"foo":"bar"}
并且这个属性源优先级最高。
属性源名称中的URL是git存储库而不是配置服务器URL。
5. Spring Cloud Config Server
服务器为外部配置（name-value pairs, or equivalent YAML content）提供了一个HTTP，resource-based的API。服务器可以使用@EnableConfigServer注解轻松嵌入到Spring Boot应用程序中。所以下面的程序是一个配置服务器：
ConfigServer.java.
@SpringBootApplication @EnableConfigServer public class ConfigServer { public static void main(String[] args) { SpringApplication.run(ConfigServer.class, args); } }
与所有Spring Boot应用程序一样，它默认在端口8080上运行，但您可以通过各种方式将其切换到常规端口8888。最简单的方法，也是设置默认的configuration repository，方法是使用spring.config.name=configserver启动server（这样配置后，server会使用Config Server jar的默认的configserver.yml）。另一种方法是使用自己的application.properties，例如
application.properties.
server.port: 8888 spring.cloud.config.server.git.uri: file://${user.home}/config-repo
其中$ {user.home} / config-repo是一个包含YAML和properties文件的git存储库。
在Windows中，如果驱动器前缀是绝对路径，则在文件URL中需要额外的“/”，例如，file:///${user.home}/config-repo
这里有一个在上面的例子中创建git仓库的方法：
$ cd $HOME $ mkdir config-repo $ cd config-repo $ git init . $ echo info.foo: bar > application.properties $ git add -A . $ git commit -m "Add application.properties"
使用本地文件系统为您的git存储库仅用于测试。生产中应该使用服务器来托管配置存储库。
如果只保存储文本文件，配置库的初始克隆将快速高效。如果您存储二进制文件，尤其是大型文件，则可能会在第一次请求配置时遇到延迟，and/or服务器内存不足错误。
5.1 Environment Repository
你想把配置服务器的配置数据存放在哪里？控制这种行为的策略是为Environment objects提供EnvironmentRepository。这个Environment是Spring Environment中domain的shallow copy（包括propertySources作为主要特性）。Environment resources通过三个变量进行参数化：
{application}maps to "spring.application.name" on the client side;{profile}maps to "spring.profiles.active" on the client (comma separated list); and{label}which is a server side feature labelling a "versioned" set of config files.
使用Repository后，Spring Boot应用程序从“spring.config.name”参数值表示的路径加载配置文件，这个值相当于{application}，还有，也会从“spring.profiles.active”参数表示的路径加载配置文件，这个值相当于{profiles}。profile的优先级规则也与常规Boot应用程序中的规则相同：active profile优先于默认的profile，并且如果有多个profile采用最后一个profile（例如向Map添加条目）。
例如：客户端应用程序具有此bootstrap configuration：
bootstrap.yml.
spring: application: name: foo profiles: active: dev,mysql
（像通常的Spring Boot应用程序一样，这些属性也可以设置为环境变量或命令行参数）。
如果repository是基于文件的，服务器将从application.yml（所有客户端共享）和foo.yml（优先使用foo.yml）创建一个Environment。如果YAML文件内有指向Spring profiles的内容，那么这些文件将会有更高的优先级（按列出的profiles的顺序），并且如果存在profile-specific 的YAML（或properties）文件，则这些文件的优先级应高于默认值。更高的优先级转换为Environment中先列出的PropertySource。（这些规则与独立的Spring Boot应用程序中的规则相同。）
5.1.1 Git Backend
EnvironmentRepository的默认实现使用Git后端，这对于管理升级和物理环境以及审核更改非常方便。要更改存储库的位置，可以在config server中设置“spring.cloud.config.server.git.uri”配置属性（例如，在application.yml中）。如果使用file：前缀进行设置，它应该从本地存储库中运行，这样您就可以在没有配置服务器的情况下快速轻松地启动服务器，但在这种情况下，服务器直接在本地存储库上运行而不克隆它（不要紧它不是光秃秃的，因为配置服务器永远不会更改“远程”存储库）。要扩展配置服务器并使其高度可用，您需要将服务器的所有实例指向同一个存储库，因此只有共享文件系统才能工作。即使在这种情况下，最好对共享文件系统存储库使用ssh:协议，以便配置服务器可以克隆它并使用本地工作副本作为缓存。
这个存储库实现将HTTP resources的{label}参数映射到一个git标签（commit id, branch name or tag）。如果git分支或tag名称包含斜线（“/”），则应该使用特殊字符串“（_）”来指定HTTP URL中的label（以避免与其他URL路径混淆）。例如，如果label是foo / bar，则替换斜杠将导致看起来像foo（_）bar的label。特殊字符串“（_）”也可以应用于{application}参数。如果您使用的是像curl这样的命令行客户端，请小心URL中的括号（例如，使用引号'将它们从shell中转义出来）。
Placeholders in Git URI
如果您需要，Spring Cloud Config Server支持带有{application}和{profile}（和{label}）占位符的git存储库URL，但请记住该label仅作为git标签应用。因此，您可以轻松地支持“one repo per application”的策略：
spring: cloud: config: server: git: uri: https://github.com/myorg/{application}
或使用类似模式但使用{profile}的“one repo per profile”策略。
此外，在{application}参数中使用特殊字符串“（_）”可以支持多个organizations：
spring: cloud: config: server: git: uri: https://github.com/{application}
这里{application}在请求时以“organization(_)application”格式提供。
Pattern Matching and Multiple Repositories
还有对 application and profile名称进行模式匹配的更复杂要求的支持。模式格式是带有通配符的{application} / {profile}名称的逗号分隔列表（其中可能需要引用以通配符开头的模式）。例：
spring: cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo repos: simple: https://github.com/simple/config-repo special: pattern: special*/dev*,*special*/dev* uri: https://github.com/special/config-repo local: pattern: local* uri: file:/home/configsvc/config-repo
如果{application} / {profile}与任何模式都不匹配，它将使用在“spring.cloud.config.server.git.uri”下定义的默认URI。在上面的示例中，对于“simple”存储库，它的pattern是 simple/ *（即它只匹配所有profiles中application的名字为“simple”应用）。“local”存储库匹配所有profiles中的application名称以“local”开头的所有应用程序（/ *后缀会自动添加到任何没有profile matcher的pattern）。
上述“simple”示例中使用的“one-liner”快捷方式只能在要设置的唯一属性是URI的情况下使用。如果您需要设置其他任何内容（credentials, pattern, etc），则需要使用完整的形式。
repo中的pattern属性实际上是一个数组，因此您可以使用YAML数组（or [0], [1], etc. suffixes in properties files）绑定到多个pattern。如果您要使用多个配置文件运行应用程序，则可能需要执行此操作。例：
spring: cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo repos: development: pattern: - '*/development' - '*/staging' uri: https://github.com/development/config-repo staging: pattern: - '*/qa' - '*/production' uri: https://github.com/staging/config-repo
Spring Cloud会猜测，包含一个不以* 结尾的profile的pattern意味着您实际上想匹配以此pattern开头的profiles列表（因此*/staging是["*/staging", "*/staging,*"]的简写形式）。例如，您需要使用本地的“development”profile运行应用程序，同时也想使用远程的“cloud” profile。
每个存储库还可以选择将配置文件存储在子目录中，并且可以将搜索这些目录的patterns指定为searchPaths。例如在top level：
spring: cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo searchPaths: foo,bar*
在这个例子中，服务器搜索top level和“foo /”子目录中的配置文件，以及名称以“bar”开头的任何子目录。
默认情况下，服务器在首次请求配置时克隆远程存储库。可以将服务器配置为在启动时克隆存储库。例如在top level：
spring: cloud: config: server: git: uri: https://git/common/config-repo.git repos: team-a: pattern: team-a-* cloneOnStart: true uri: http://git/team-a/config-repo.git team-b: pattern: team-b-* cloneOnStart: false uri: http://git/team-b/config-repo.git team-c: pattern: team-c-* uri: http://git/team-a/config-repo.git
在这个例子中，服务器在接受任何请求之前，在启动时克隆team-a的config-repo。除非请求存储库中的配置，否则所有其他存储库都不会被克隆。
在配置服务器启动时设置要克隆的存储库可以帮助快速识别错误配置的配置源（例如，无效的存储库URI）。使用cloneOnStart未启用配置源时，配置服务器可能会以错误配置或无效的配置源成功启动，并且在应用程序从该配置源请求配置之前检测不到错误。
Authentication
要在远程存储库上使用HTTP基本认证，单独添加“用户名”和“密码”属性（不在URL中），例如
spring: cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo username: trolley password: strongpassword
即时您不使用HTTPS和user credentials，当您将keys存储在默认目录（〜/ .ssh）并且uri指向SSH location（例如，“git@github.com:configuration/cloud-configuration”，SSH也能开箱即用。〜/ .ssh / known_hosts文件中存在Git服务器的条目，并且它是ssh-rsa格式，这一点很重要。其他格式（如ecdsa-sha2-nistp256）不受支持。为了避免出现意外，您应该确保Git服务器的known_hosts文件中只有一个条目存在，并且它与您提供给配置服务器的URL匹配。如果您在URL中使用了主机名，则您希望在known_hosts文件中具有完全相同的名称，而不是IP。该存储库是使用JGit访问的，因此您找到的任何文档都应该适用。可以在〜/ .git / config中设置HTTPS代理设置，也可以通过系统属性（-Dhttps.proxyHost和-Dhttps.proxyPort）以与其他任何JVM进程相同的方式设置HTTPS代理设置。
如果您不知道您的〜/ .git目录在哪里，请使用git config --global来操作设置（例如，git config --global http.sslVerify false）。
Authentication with AWS CodeCommit
略
Git SSH configuration using properties
默认情况下，当使用SSH URI连接到Git存储库时，Spring Cloud Config Server使用的JGit 使用SSH配置文件，例如〜/ .ssh / known_hosts和/ etc / ssh / ssh_config。在Cloud Foundry等云环境中，本地文件系统可能是暂时的或不易访问的。对于这些情况，可以使用Java属性设置SSH配置。为了激活基于属性的SSH配置，必须将spring.cloud.config.server.git.ignoreLocalSshSettings属性设置为true。例：
spring: cloud: config: server: git: uri: git@gitserver.com:team/repo1.git ignoreLocalSshSettings: true hostKey: someHostKey hostKeyAlgorithm: ssh-rsa privateKey: | -----BEGIN RSA PRIVATE KEY----- MIIEpgIBAAKCAQEAx4UbaDzY5xjW6hc9jwN0mX33XpTDVW9WqHp5AKaRbtAC3DqX IXFMPgw3K45jxRb93f8tv9vL3rD9CUG1Gv4FM+o7ds7FRES5RTjv2RT/JVNJCoqF ol8+ngLqRZCyBtQN7zYByWMRirPGoDUqdPYrj2yq+ObBBNhg5N+hOwKjjpzdj2Ud 1l7R+wxIqmJo1IYyy16xS8WsjyQuyC0lL456qkd5BDZ0Ag8j2X9H9D5220Ln7s9i oezTipXipS7p7Jekf3Ywx6abJwOmB0rX79dV4qiNcGgzATnG1PkXxqt76VhcGa0W DDVHEEYGbSQ6hIGSh0I7BQun0aLRZojfE3gqHQIDAQABAoIBAQCZmGrk8BK6tXCd fY6yTiKxFzwb38IQP0ojIUWNrq0+9Xt+NsypviLHkXfXXCKKU4zUHeIGVRq5MN9b BO56/RrcQHHOoJdUWuOV2qMqJvPUtC0CpGkD+valhfD75MxoXU7s3FK7yjxy3rsG EmfA6tHV8/4a5umo5TqSd2YTm5B19AhRqiuUVI1wTB41DjULUGiMYrnYrhzQlVvj 5MjnKTlYu3V8PoYDfv1GmxPPh6vlpafXEeEYN8VB97e5x3DGHjZ5UrurAmTLTdO8 +AahyoKsIY612TkkQthJlt7FJAwnCGMgY6podzzvzICLFmmTXYiZ/28I4BX/mOSe pZVnfRixAoGBAO6Uiwt40/PKs53mCEWngslSCsh9oGAaLTf/XdvMns5VmuyyAyKG ti8Ol5wqBMi4GIUzjbgUvSUt+IowIrG3f5tN85wpjQ1UGVcpTnl5Qo9xaS1PFScQ xrtWZ9eNj2TsIAMp/svJsyGG3OibxfnuAIpSXNQiJPwRlW3irzpGgVx/AoGBANYW dnhshUcEHMJi3aXwR12OTDnaLoanVGLwLnkqLSYUZA7ZegpKq90UAuBdcEfgdpyi PhKpeaeIiAaNnFo8m9aoTKr+7I6/uMTlwrVnfrsVTZv3orxjwQV20YIBCVRKD1uX VhE0ozPZxwwKSPAFocpyWpGHGreGF1AIYBE9UBtjAoGBAI8bfPgJpyFyMiGBjO6z FwlJc/xlFqDusrcHL7abW5qq0L4v3R+FrJw3ZYufzLTVcKfdj6GelwJJO+8wBm+R gTKYJItEhT48duLIfTDyIpHGVm9+I1MGhh5zKuCqIhxIYr9jHloBB7kRm0rPvYY4 VAykcNgyDvtAVODP+4m6JvhjAoGBALbtTqErKN47V0+JJpapLnF0KxGrqeGIjIRV cYA6V4WYGr7NeIfesecfOC356PyhgPfpcVyEztwlvwTKb3RzIT1TZN8fH4YBr6Ee KTbTjefRFhVUjQqnucAvfGi29f+9oE3Ei9f7wA+H35ocF6JvTYUsHNMIO/3gZ38N CPjyCMa9AoGBAMhsITNe3QcbsXAbdUR00dDsIFVROzyFJ2m40i4KCRM35bC/BIBs q0TY3we+ERB40U8Z2BvU61QuwaunJ2+uGadHo58VSVdggqAo0BSkH58innKKt96J 69pcVH/4rmLbXdcmNYGm6iu+MlPQk4BUZknHSmVHIFdJ0EPupVaQ8RHT -----END RSA PRIVATE KEY-----
Table 5.1. SSH Configuration properties
| Property Name | Remarks |
|---|---|
ignoreLocalSshSettings | If true, use property based SSH config instead of file based. Must be set at as |
privateKey | Valid SSH private key. Must be set if |
hostKey | Valid SSH host key. Must be set if |
hostKeyAlgorithm | One of |
strictHostKeyChecking |
|
knownHostsFile | Location of custom .known_hosts file |
preferredAuthentications | Override server authentication method order. This should allow evade login prompts if server has keyboard-interactive authentication before |
Placeholders in Git Search Paths
如果需要，Spring Cloud Config Server还支持包含{application}和{profile}（和{label}）占位符的search path。例：
spring: cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo searchPaths: '{application}'
searches the repository for files in the same name as the directory (as well as the top level).。通配符在带占位符的搜索路径中也是有效的（任何匹配的目录都会被搜索）。
Force pull in Git Repositories
如前所述，Spring Cloud Config Server对远程git存储库进行了克隆，并且如果本地副本以某种方式变脏（例如文件夹内容，因操作系统进程而异），Spring Cloud Config Server无法从远程存储库更新本地副本。
为了解决这个问题，如果本地副本很脏，会有一个force-pull属性，使Spring Cloud Config Server从远程存储库强制拉取。例：
spring: cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo force-pull: true
如果您有多个存储库配置，则可以配置每个存储库的force-pull属性。例：
spring: cloud: config: server: git: uri: https://git/common/config-repo.git force-pull: true repos: team-a: pattern: team-a-* uri: http://git/team-a/config-repo.git force-pull: true team-b: pattern: team-b-* uri: http://git/team-b/config-repo.git force-pull: true team-c: pattern: team-c-* uri: http://git/team-a/config-repo.git
|
Deleting untracked branches in Git Repositories
由于Spring Cloud Config Server在检出分支到本地仓库后（例如通过label获取properties）就拥有了远程git存储库的克隆，它将永久保留此分支或直到下一次服务器重新启动（这会创建新的本地仓库）。所以可能会出现这样的情况：远程分支被删除，但它的本地副本仍然可用于获取。如果Spring Cloud Config Server客户端服务以--spring.cloud.config.label=deletedRemoteBranch,master开头，那么server将从deletedRemoteBranch本地分支fetch属性，而不是从master获取属性。
为了保持本地存储库分支清洁并和远程分支保持一致，可以设置deleteUntrackedBranches属性。这将使Spring Cloud Config Server强制从本地存储库中删除未trace的分支。例：
spring: cloud: config: server: git: uri: https://github.com/spring-cloud-samples/config-repo deleteUntrackedBranches: trueThe default value for
deleteUntrackedBranches
property is
false
.
5.1.2 Version Control Backend Filesystem Use
将基于VCS（git，svn）的文件检出或克隆到本地文件系统。默认情况下，它们被放在系统临时目录中，前缀为config-repo-。在linux上，例如它可能是/ tmp / config-repo- <randomid>。一些操作系统会定期清理临时目录。这可能会导致意外的行为，例如缺少属性。要避免此问题，请通过将spring.cloud.config.server.git.basedir或spring.cloud.config.server.svn.basedir设置为不驻留在系统临时结构中的目录。
5.1.3 File System Backend
在配置服务器中有一个不使用Git的“native” profile，只是从local classpath or file system中加载配置文件（可以通过“spring.cloud.config.server.native.searchLocations”配置任何静态URL）。要使用native profile，只需使用“spring.profiles.active = native”启动配置服务器即可。
请记住如果是文件资源使用file：前缀（没有前缀的缺省通常是classpath）。与任何Spring Boot配置一样，您可以嵌入$ {}样式的environment占位符，但请记住，Windows中的绝对路径需要额外的“/”，例如，file:///${user.home}/config-repo
searchLocations的默认值与本地的Spring Boot应用程序相同（所以[classpath:/, classpath:/config, file:./, file:./config]）。这不会把application.properties从服务器公开到所有客户端，因为服务器中存在的任何property sources在发送到客户端之前都会被删除。
文件系统后端非常适合快速入门和测试。要在生产环境中使用它，您需要确保文件系统可靠，并在Config Server的所有实例中共享。
The search locations可以包含{application}，{profile}和{label}占位符。通过这种方式，您可以分隔路径中的目录，并选择一种对您有意义的策略（例如，每个application的子目录或每个profile的子目录）。
如果您在search locations中未使用占位符，则此存储库默认会将HTTP资源的{label}参数附加到搜索路径的后缀中，所以properties files会被从每个search locations和与label名称相同的子目录中加载（ Spring Environment中的labelled properties优先）。因此，没有占位符的默认行为与添加以/ {label} /结尾的search locations相同。例如file:/tmp/config与file:/tmp/config,file:/tmp/config/{label}相同。这个行为可以通过设置spring.cloud.config.server.native.addLabelLocations = false来禁用。
5.1.4 Vault Backend
Spring Cloud Config Server也支持Vault作为后端。
Vault是安全访问secrets的工具。secrets就是你想要严格控制访问的任何东西，比如API keys, passwords, certificates, and more。Vault为任何secret提供统一的接口，同时提供严格的访问控制并记录详细的审计日志。
有关Vault的更多信息，请参阅Vault quickstart guide。
要使配置服务器能够使用Vault后端，您可以使用Vault profile运行配置服务器。例如在你的配置服务器的application.properties中，你可以添加spring.profiles.active = vault。
默认情况下，配置服务器将假定您的Vault服务器运行在http://127.0.0.1:8200。它还会假设后端的名称是secret，key是application。所有这些默认值都可以在你的配置服务器的application.properties中配置。以下是可配置的Vault属性表。所有属性都以spring.cloud.config.server.vault为前缀。
| Name | Default Value |
|---|---|
host | 127.0.0.1 |
port | 8200 |
scheme | http |
backend | secret |
defaultKey | application |
profileSeparator |
所有可配置的属性都可以在org.springframework.cloud.config.server.environment.VaultEnvironmentRepository中找到。
运行配置服务器后，您可以向服务器发出HTTP请求以从Vault后端检索值。要做到这一点，您需要一个用于Vault服务器的令牌。首先将一些数据放入您的Vault中。例如
$ vault write secret/application foo=bar baz=bam $ vault write secret/myapp foo=myappsbar
现在将HTTP请求发送到您的配置服务器以检索值。
$ curl -X "GET" "http://localhost:8888/myapp/default" -H "X-Config-Token: yourtoken"
在发送上述要求后，您应该看到与此类似的响应。
{ "name":"myapp", "profiles":[ "default" ], "label":null, "version":null, "state":null, "propertySources":[ { "name":"vault:myapp", "source":{ "foo":"myappsbar" } }, { "name":"vault:application", "source":{ "baz":"bam", "foo":"bar" } } ] }
Multiple Properties Sources
使用Vault时，您可以为您的应用程序提供多个属性来源。例如，假设您已将数据写入Vault中的以下路径。
secret/myApp,dev secret/myApp secret/application,dev secret/application写入 secret/application的属性可被所有应用程序访问。名称为myApp的应用程序可以访问任何写入secret / myApp和的secret / application路径的属性。当myApp应用具有对应的profile时，写入所有上述路径的属性都可以访问，列表中第一个路径的属性优先于其他路径。
5.1.5 Sharing Configuration With All Applications
File Based Repositories
使用基于文件的（即git，svn和native）存储库，文件名称为application*的resources（如application.properties，application.yml，application-*.properties等）将在所有客户端应用程序之间共享。您可以使用具有这些文件名的资源来配置全局默认值，并根据需要使用它们覆盖特定于应用程序的文件。
#_property_overrides[property overrides] 特性也可用于设置全局默认值，并且通过使用占位符应用程序可以在本地覆盖它们。
使用“native” profile（local file system backend），建议您使用不属于服务器自身配置的显式搜索位置。否则，将删除默认搜索位置中的application* resources，因为它们是服务器配置的一部分。
Vault Server
将Vault用作后端时，可以通过将配置置于secret/application目录中来实现所有应用程序共享配置。例如，如果您运行此Vault命令
$ vault write secret/application foo=bar baz=bam所有使用此配置服务器的应用程序都可以访问foo和baz属性。
5.1.6 JDBC Backend
Spring Cloud Config Server支持JDBC（关系数据库）作为配置属性的后端。您可以通过将spring-jdbc添加到类路径中，并使用“jdbc” profile或添加JdbcEnvironmentRepository类型的bean来启用此功能。如果您在类路径中包含正确的依赖关系，Spring Boot将自动配置data source（有关更多详细信息，请参阅用户指南）。
数据库需要有一个名为“PROPERTIES”的表，其中包含“APPLICATION”，“PROFILE”，“LABEL”（具有通常的Environment含义），以及对应Properties样式中的键值对的“KEY”和“VALUE”字段。所有字段都是Java中的String类型，因此您可以将它们设置为您需要的任何长度的VARCHAR。属性值的行为方式与它们来自名为{application}-{profile}.properties的Spring Boot属性文件相同，包括所有加密和解密，这些文件将作为后处理步骤应用（即不在仓库实施直接）。
5.1.7 Composite Environment Repositories
在某些情况下，您可能希望从多个环境存储库中提取配置数据。为此，您可以在配置服务器的application properties or YAML file中启用多个multiple profiles。例如，如果您想要从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
除了每个repo指定一个URI之外，您还可以指定一个order属性。order属性允许您为所有存储库指定优先顺序。order属性的数值越低，它所拥有的优先级越高。存储库的优先顺序将有助于解决包含相同属性值的存储库之间的任何潜在冲突。
从environment repositoy检索值时发生任何类型的故障都会导致整个composite environment(组合环境)出现故障。
在使用composite environment时，重要的是所有仓库包含相同的label(s)。如果您的环境类似于上述环境，并且您使用标签master请求配置数据，但SVN仓库不包含称为master的分支，则整个请求将失败。
Custom Composite Environment Repositories
除了使用Spring cloud environment存储库之外，还可以提供自己的EnvironmentRepository bean作为组合环境的一部分。要做到这一点，你的bean必须实现EnvironmentRepository接口。如果您想要在复合环境中控制自定义EnvironmentRepository的优先级，则还应实现Ordered接口并覆盖getOrdered方法。如果你没有实现Ordered接口，那么你的EnvironmentRepository将被赋予最低的优先级。
5.1.8 Property Overrides
配置服务器具有“overrides”功能，允许操作员为所有应用程序提供配置属性，而这些配置属性不能使用普通的Spring Boot hook意外更改。要声明overrides，只需将key-value对的映射添加到spring.cloud.config.server.overrides。例如
spring: cloud: config: server: overrides: foo: bar
将导致是配置客户端的所有应用程序独立于自己的配置读取foo = bar。（当然，应用程序可以以任何喜欢的方式使用Config服务器中的数据，因此覆盖可以不强制执行，但如果它们是Spring Cloud Config客户端，这样做确实提供了有用的默认行为。）
一般情况下，具有“$ {}”的SpringEnvironment占位符可以通过使用反斜杠（“\”）来转义“$”或“{”，例如\${app.foo:bar}解析为“bar”，除非应用程序提供自己的“app.foo”。请注意，在YAML中，当您在服务器上配置overrides时，您不需要转义反斜杠本身，而是在属性文件中进行转义。
您可以通过在远程存储库中设置spring.cloud.config.overrideNone=true将客户端中所有overrides的优先级更改为default values，从而允许应用程序在环境变量或系统属性中提供自己的值。
5.2 Health Indicator
配置服务器附带一个健康指示器，用于检查配置的EnvironmentRepository是否正常工作。默认情况下，它会向EnvironmentRepository请求一个名为app的应用程序，default profile和EnvironmentRepository实现提供的默认label。
您可以配置Health Indicator以检查更多应用程序以及custom profiles and custom labels，例如
spring: cloud: config: server: health: repositories: myservice: label: mylabel myservice-dev: name: myservice profiles: development
您可以通过设置spring.cloud.config.server.health.enabled = false来禁用健康指示器。
5.3 Security
您可以以任何对您有意义的方式（从物理网络安全到OAuth2承载令牌）自由保护您的Config服务器，Spring Security和Spring Boot可以轻松完成任何事情。
要使用默认的Spring Boot配置的HTTP Basic安全性，只需在类路径中包含Spring Security（例如通过spring-boot-starter-security）即可。默认值是用户名“user”和一个随机生成的密码，这在实践中并不会很有用，所以我们建议您配置密码（通过security.user.password）并对其进行加密（参见下面的说明如何做到这一点）。
5.4 Encryption and Decryption
Important
先决条件：要使用加密和解密功能，您需要安装在JVM中的全功能JCE（默认情况下不存在）。您可以从Oracle下载“Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files”，并按照安装说明进行操作（实质上上将JRE的 lib / security目录中的2个Policy Files替换为您下载的那些文件就好了）。
如果远程属性源包含加密内容（以{cipher}开头的值），则在通过HTTP发送给客户端之前，它们将被解密。这种设置的主要优点是，属性值在“at rest”不必为纯文本（例如，在git存储库中）。如果某个值无法解密，则将其从属性源中移除，并使用相同的key添加其他属性，但key的前缀为“invalid.”。和一个意味着“not applicable”的value（通常是“<n / a>”）。这主要是为了防止被用作密码的加密文本意外泄漏的情况。
如果你正在为config client应用程序设置一个远程配置库，它可能会包含一个像这样的application.yml，例如：
application.yml.
spring: datasource: username: dbuser password: '{cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ'
.properties文件中的加密值不得包含在引号中，否则该值不会被解密：
application.properties.
spring.datasource.username: dbuser
spring.datasource.password: {cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ
您可以安全地将此纯文本推送到共享的git存储库，并且密码被保护。
服务器还暴露/encrypt and /decrypt端点（假设这些端点将被保护并且仅由授权代理访问）。如果您正在编辑远程配置文件，则可以使用配置服务器通过POST到/encrypt端点来加密值，例如，
$ curl localhost:8888/encrypt -d mysecret 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda
如果您正在加密的值中包含需要进行 URL encoded的字符，则应在crul命令中使用--data-urlencode选项进行以确保其编码正确。
请务必不要在加密值中包含任何curl命令统计信息。将该值输出到文件可以帮助避免此问题。
通过/decrypt 也可以反向操作（假设服务器配置了对称密钥或完整密钥对）：
$ curl localhost:8888/decrypt -d 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda mysecret
如果你正在用curl来测试，那么使用--data-urlencode（而不是-d）或者设置一个明确的Content-Type：text / plain来确保curl在有特殊字符时正确编码数据（"+''特别棘手）。
取出加密的值并且添加{cipher}前缀在将它放入YAML或属性文件之前，在提交并将其推送到远程，可能存储的不安全。
/ encrypt和/ decrypt端点也都接受格式为/*/{name}/{profiles}的路径，这些路径可用于在客户端调用main Environment resource时控制每个应用程序（name）和profile的加密。
为了以这种细粒度的方式控制加密，您还必须提供一个类型为TextEncryptorLocator的@Bean，它为每个name和profile创建不同的encryptor （加密器）。默认提供的那个加密器不会这样做（因此所有的加密都使用相同的密钥）。
command line client（安装有Spring Cloud CLI扩展）也可用于加密和解密，例如，
$ spring encrypt mysecret --key foo 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda $ spring decrypt --key foo 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda mysecret为了使用 在文件中的密钥（例如用于加密的RSA公钥），在文件路径前加@前缀，例如，
$ spring encrypt mysecret --key @${HOME}/.ssh/id_rsa.pub
AQAjPgt3eFZQXwt8tsHAVv/QHiY5sI2dRcR+...
key参数是强制性的。
5.5 Key Management
配置服务器可以使用对称（共享）密钥或不对称密钥（RSA密钥对）。非对称密钥在安全性方面优越，但使用对称密钥通常更方便，因为它只是在bootstrap.properties中配置的单个属性值。
要配置对称密钥，您只需将encrypt.key设置为一个secret字符串（或使用环境变量ENCRYPT_KEY将其保留在纯文本配置文件之外）。
要配置非对称密钥，您可以将密钥设置为PEM编码的文本值（在encrypt.key中）或通过keyStore(密钥库)（例如，由JDK附带的keytool实用工具创建的密钥库）。密钥库属性名为encrypt.keyStore。*，其中*可以是：
location(aResourcelocation),password(to unlock the keystore) andalias(to identify which key in the store is to be used).
加密使用公钥完成，解密需要私钥。因此，如果您只想执行加密（并准备使用私钥在本地解密值），则原则上只能在服务器中配置公钥。实际上，您可能不想这样做，因为它将密钥管理过程分散到所有客户端，而不是集中在服务器中。但是，如果您的配置服务器确实相对不安全并且只有少数客户端需要加密的属性，那么这是一个有用的选项。
5.6 Creating a Key Store for Testing
要创建一个测试密钥库，可以这样做：
$ keytool -genkeypair -alias mytestkey -keyalg RSA \ -dname "CN=Web Server,OU=Unit,O=Organization,L=City,S=State,C=US" \ -keypass changeme -keystore server.jks -storepass letmein
将server.jks文件放在类路径中，然后配置您的配置服务器的bootstrap.yml文件：
encrypt: keyStore: location: classpath:/server.jks password: letmein alias: mytestkey secret: changeme
5.7 Using Multiple Keys and Key Rotation
除了加密属性值中的{cipher}前缀之外，配置服务器还会在cipher text（Base64编码）开始之前查找{name：value}前缀（零个或多个）。密钥被传递给一个TextEncryptorLocator，它可以执行任何需要定位用于cipher的TextEncryptor的逻辑。如果您已配置密钥库（encrypt.keystore.location），则默认定位器将在密钥库中使用由“key”前缀提供的别名查找密钥，例如像下面的cipher text
foo: bar: `{cipher}{key:testkey}...`
定位器将查找名为“testkey”的密钥。secret也可以通过{secret：...}形式来提供，但如果它不是默认值，则使用密钥库密码（这是您在构建密钥库并且没有指定secret的情况下获得的）。如果您的确提供了secret，建议您使用自定义SecretLocator加密这个secret。
如果密钥仅用于加密几个字节的配置数据，则Key rotation几乎不需要，但是偶尔如果存在安全漏洞，则可能需要更改keys。在这种情况下，所有客户端都需要更改源配置文件（例如，在git中），并在所有ciphers中使用新的{key:…}前缀，当然事先检查key alias在Config Server密钥库中是否可用。
如果您想让Config服务器处理所有加密和解密，则{name：value}前缀也可以添加到发布到/encrypt端点的纯文本中。
5.8 Serving Encrypted Properties
有时您希望客户端在本地配置解密，而不是在服务器中进行配置。在这种情况下，您仍然可以拥有 /encrypt and /decrypt端点（如果您提供了encrypt.*配置来查找key(密钥)），但您需要使用spring.cloud.config.server.encrypt.enabled=false明确关闭对外部属性的解密。如果你不关心 /encrypt and /decrypt端点，那么你既不配置key也不启用那个标志就可以好了。
6. Serving Alternative Formats
environment endpoints(环境端点)的默认JSON格式非常适合Spring应用程序使用，因为它直接映射到Environment抽象。如果您愿意，您可以通过在资源路径添加后缀（“.yml”，“.yaml”或“.properties”）来获取与YAML或Java属性相同的数据。这对于不关心JSON端点结构的应用程序或者它们提供的额外元数据的应用程序非常有用，例如，不使用Spring的应用程序可能会受益于此方法的简单性。
YAML和properties representations有一个额外的标志（作为布尔查询参数resolvePlaceholders提供）以标志Spring $ {...}形式的源文档中的占位符，应该在呈现前尽可能在输出中解析。对于不了解Spring占位符约定的消费者来说，这是一个有用的功能。
在使用YAML或properties格式方面存在限制，主要涉及元数据的丢失。JSON的结构是一个有序的property sources列表，例如，与源相关的名称。YAML和属性表单会合并到一个map中，即使这些值的来源有多个来源，那么原始源文件的名称也会丢失。YAML representation不一定是YAML源在后备存储库中的真是代表：它是从一个平铺的属性源列表构建的，并且假设必须是关键字的形式。
7. Serving Plain Text
应用程序可能需要通用的纯文本配置文件，这些文件是针对其环境定制的,而不是使用 Environment abstraction(或YAML或properties格式中的替代表示形式)。Config服务器通过另一个端点在/{name}/{profile}/{label}/{path}中提供这些端点，其中“name”，“profile”和“label”的含义与常规environment端点相同，但“path“是一个文件名（例如log.xml）。此端点的源文件的位置与environment端点的相同：使用与properties or YAML files相同的搜索路径，但不会汇总所有匹配资源，而只返回第一个匹配的资源。
找到资源后，将使用与提供的application name, profile and label 对应的有效的Environment解析（$ {...}）格式的占位符。通过这种方式，resource endpoint与environment endpoints紧密集成。例如，如果您的GIT（或SVN）存储库有下面两个文件
application.yml nginx.conf
其中nginx.conf如下所示：
server {
listen 80;
server_name ${nginx.server.name};
}application.yml像这样：
nginx: server: name: example.com --- spring: profiles: development nginx: server: name: develop.com
那么/foo/default/master/nginx.conf资源如下所示：
server {
listen 80;
server_name example.com;
}
/foo/development/master/nginx.conf像这样：
server {
listen 80;
server_name develop.com;
}
就像用于环境配置的source files一样，“profile”用于解析文件名，因此如果您需要profile-specific的文件，那么/*/development/*/logback.xml将获得名为logback-development.xml的文件（优先于logback.xml）。
如果您不想提供label并让服务器使用默认label，则可以提供useDefaultLabel请求参数。因此，上面的default profile示例可能类似于/foo/default/nginx.conf?useDefaultLabel
8. Embedding the Config Server
Config服务器作为独立应用程序运行得最好，但如果需要，可以将其嵌入到另一个应用程序中。只需使用@EnableConfigServer注释。在这种情况下可用的可选属性是spring.cloud.config.server.bootstrap，它是一个标志，指示服务器应该从其自己的远程存储库配置自身。该标志默认是关闭的，因为它可以延迟启动，但是当嵌入到另一个应用程序中时，以与其他应用程序相同的方式进行初始化是有意义的。
应该很明显，但请记住，如果使用bootstrap flag，则配置服务器需要在bootstrap.yml中配置其名称和存储库URI。
要更改服务器端点的location，您可以（可选）设置spring.cloud.config.server.prefix，例如，“/ config”，为这个前缀下的资源提供服务。前缀应该以"/"开始，但不能以"/"结尾。它应用于配置服务器中的@RequestMappings（即在Spring Boot前缀server.servletPath和server.contextPath下）。
如果您想直接从后端存储库（而不是从配置服务器）读取应用程序的配置，这基本上是一个没有端点的嵌入式配置服务器。如果您不使用@EnableConfigServer注释（只需设置spring.cloud.config.server.bootstrap = true），则可以完全关闭端点。
9. Push Notifications and Spring Cloud Bus
许多源代码存储库提供程序（例如Github，Gitlab或Bitbucket）会通过webhook向您通知存储库中的更改。您可以通过提供商的用户界面将webhook配置为您感兴趣的URL和一组事件。例如，Github将通过一个包含提交列表的JSON主体和一个等于“push”的header为“X-Github-Event”的请求发布到webhook。如果添加了对spring-cloud-config-monitor库的依赖关系并在Config Server中激活Spring Cloud Bus，则会启用“/ monitor”端点。
当webhook被激活时，配置服务器将发送一个RefreshRemoteApplicationEvent，这个事件针对它认为可能发生变化的应用程序。更改检测可以制定策略，但默认情况下它只是查找与应用程序name匹配的文件更改（例如，“foo.properties”针对“foo”应用程序，“application.properties”针对所有应用程序）。如果要覆盖该行为，策略是PropertyPathNotificationExtractor，它接受请求header和body作为参数，并返回已更改的文件路径的列表。
使用Github，Gitlab或Bitbucket可以使用默认配置。除了来自Github，Gitlab或Bitbucket的JSON通知之外，您还可以通过以form-encoded body参数path = {name}的POST方式触发“/ monitor”来触发更改通知。这将广播到匹配“{name}” pattern的应用程序（可以包含通配符）。
只有在配置服务器和客户端应用程序中激活了spring-cloud-bus时，才会传输RefreshRemoteApplicationEvent。
默认配置还检测本地git存储库中的文件系统更改（在这种情况下不使用webhook，但只要编辑了配置文件，刷新将被广播）。
10. Spring Cloud Config Client
Spring Boot应用程序可以立即利用Spring Config Server（或应用程序开发人员提供的其他外部属性资源），并且还可以获取一些与Environment修改事件相关的其他有用功能。
10.1 Config First Bootstrap
对于在类路径中具有Spring Cloud Config Client的任何应用程序，这是默认行为。当配置客户端启动时，它将绑定到配置服务器（通过引导配置属性spring.cloud.config.uri）并使用远程属性来初始化Spring Environment。
这样做的最终结果是，所有想要使用配置服务器的客户端应用程序都需要一个bootstrap.yml（或一个environment variable），并在spring.cloud.config.uri中配置服务器地址（默认为“http：// localhost：8888" ）。
10.2 Discovery First Bootstrap
如果您正在使用“DiscoveryClient”实现，例如Spring Cloud Netflix和Eureka Service Discovery或Spring Cloud Consul（Spring Cloud Zookeeper尚不支持此功能），则可以让Config Server在发现服务中注册（如果需要）但是在默认的“配置优先”模式下，客户端将无法利用注册。
如果您更喜欢使用DiscoveryClient来查找配置服务器，可以通过设置spring.cloud.config.discovery.enabled = true（默认为“false”）来实现。最终的结果是，客户端应用程序都需要具有适当discovery配置的bootstrap.yml（或环境变量）。例如，使用Spring Cloud Netflix，您需要定义Eureka服务器地址，例如，在eureka.client.serviceUrl.defaultZone中。使用此选项的代价是启动时寻找服务注册的额外网络往返时间。好处是配置服务器可以改变它的坐标，只要发现服务是一个固定点。默认的服务ID是“configserver”，但是你可以用spring.cloud.config.discovery.serviceId在client上改变它（服务器上的服务以通常的方式设置服务名，例如通过设置spring.application.name）。
discovery client实现都支持一些元数据映射（例如，对于Eureka，我们有eureka.instance.metadataMap）。Config Server的一些其他属性可能需要在其service registration metadata中配置，以便客户端可以正确连接。如果配置服务器使用HTTP Basic进行安全保护，则可以将credentials(凭证)配置为"username" and "password"。如果配置服务器有一个上下文路径，您可以设置“configPath”。例如，对于作为Eureka客户端的Config服务器：
eureka: instance: ... metadataMap: user: osufhalskjrtl password: lviuhlszvaorhvlo5847 configPath: /config
10.3 Config Client Fail Fast
在某些情况下，如果服务无法连接到配置服务器，则可能需要启动服务时失败。如果这是所需的行为，请设置 bootstrap configuration property属性spring.cloud.config.failFast = true，这样客户端将停止并抛出一个Exception。
10.4 Config Client Retry
如果您希望配置服务器在您的应用程序启动时可能偶尔不可用，您可以要求应用程序在发生故障后继续尝试。首先，您需要设置spring.cloud.config.failFast = true，然后您需要将spring-retry and spring-boot-starter-aop添加到您的类路径中。默认行为是重试6次，初始回退间隔为1000ms，后续回退的指数乘数为1.1。您可以使用spring.cloud.config.retry.*配置属性来配置这些属性（和其他属性）。
要完全控制重试，请添加ID为“configServerRetryInterceptor”的RetryOperationsInterceptor类型的@Bean。Spring Retry有一个RetryInterceptorBuilder，可以很容易地创建一个。
10.5 Locating Remote Configuration Resources
Config服务提供来自/ {name} / {profile} / {label}的属性来源，其中客户端应用程序中的默认绑定是
- "name" =
${spring.application.name} - "profile" =
${spring.profiles.active}(actuallyEnvironment.getActiveProfiles()) - "label" = "master"
所有这些都可以通过设置spring.cloud.config.*其中*为“name”，“profile”或“label”）来覆盖。“label”对于回滚到以前版本的配置非常有用;使用默认的Config Server实现时，label可以是git label, branch name or commit id。label也可以作为逗号分隔的列表提供，在这种情况下，列表中的项目将逐个尝试，直到一个成功。例如，当您在一个feature分支上开发时，可能希望将label与分支对应，但将其设置为可选的（例如，spring.cloud.config.label = myfeature，develop）。
10.6 Security
如果您在服务器上使用HTTP Basic security，则客户端只需知道密码（如果用户名不是默认的，那么还需要用户名）。您可以通过配置服务器URI或通过单独的用户名和密码属性，例如
bootstrap.yml.
spring: cloud: config: uri: https://user:secret@myconfig.mycompany.com
or
bootstrap.yml.
spring: cloud: config: uri: https://myconfig.mycompany.com username: user password: secret
spring.cloud.config.password和spring.cloud.config.username值将覆盖URI中提供的任何内容。
如果您在Cloud Foundry上部署应用程序，则提供密码的最佳方式是通过service credentials(服务凭据)，例如，在URI中，因为它甚至不需要在配置文件中。一个本地运行的项目并调用Cloud Foundry上 的user-provided名为“configserver”的服务的示例：
bootstrap.yml.
spring: cloud: config: uri: ${vcap.services.configserver.credentials.uri:http://user:password@localhost:8888}
如果您使用其他形式的安全校验，则可能需要向ConfigServicePropertySourceLocator提供RestTemplate（例如，通过在bootstrap context 中抓取并注入一个）。
10.6.1 Health Indicator
Config Client提供一个Spring Boot Health Indicator，它试图从配置服务器加载配置。可以通过设置health.config.enabled = false来禁用健康指示器。由于性能原因，响应也被缓存。默认的缓存时间为5分钟。要更改该值，请设置health.config.time-to-live属性（以毫秒为单位）。10.6.2 Providing A Custom RestTemplate
在某些情况下，您可能需要自定义从客户端向配置服务器发出的请求。通常这包括传递特殊的Authorization headers来验证对服务器的请求。要提供自定义RestTemplate，请按照以下步骤操作。
用PropertySourceLocator的实现创建一个新的配置bean。
- Create a new configuration bean with an implementation of
PropertySourceLocator.
CustomConfigServiceBootstrapConfiguration.java.
@Configuration public class CustomConfigServiceBootstrapConfiguration { @Bean public ConfigServicePropertySourceLocator configServicePropertySourceLocator() { ConfigClientProperties clientProperties = configClientProperties(); ConfigServicePropertySourceLocator configServicePropertySourceLocator = new ConfigServicePropertySourceLocator(clientProperties); configServicePropertySourceLocator.setRestTemplate(customRestTemplate(clientProperties)); return configServicePropertySourceLocator; } }
- In
resources/META-INFcreate a file calledspring.factoriesand specify your custom configuration.
spring.factories.
org.springframework.cloud.bootstrap.BootstrapConfiguration = com.my.config.client.CustomConfigServiceBootstrapConfiguration
10.6.3 Vault
10.7.1 Nested Keys In Vault
Vault supports the ability to nest keys in a value stored in Vault. For example
echo -n '{"appA": {"secret": "appAsecret"}, "bar": "baz"}' | vault write secret/myapp -
该命令将向您的Vault写入JSON对象。要在Spring中访问这些值，您可以使用传统的点. 注解。例如
@Value("${appA.secret}") String name = "World";
上面的代码会将name变量设置为appAsecret。
321
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
