Hoxton.SR3
Spring Cloud Config为分布式系统中的外部化配置提供了服务器端和客户端支持。有了Config Server,您就有了一个中心位置来管理跨所有环境的应用程序的外部属性。客户机和服务器上的概念与Spring环境和PropertySource抽象完全相同,因此它们非常适合Spring应用程序,但可以用于以任何语言运行的任何应用程序。当应用程序通过部署管道从dev迁移到测试并进入生产环境时,您可以管理这些环境之间的配置,并确保应用程序在迁移时拥有所需的一切。服务器存储后端默认的实现使用git,因此它很容易支持配置环境的标记版本,并且可以访问各种各样的工具来管理内容。很容易添加替代实现并将它们插入Spring配置中。
http请求可以通过以下方式获取资源:
/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
application:spring.config.name
profile:an active profile (dev/repo)
label : an optional git label(defaults to master)
Spring Cloud Config Server从各种源获取远程客户端的配置。下面的示例从git存储库获取配置(必须提供配置),如下面的示例所示:
spring:
cloud:
config:
server:
git:
uri: https://github.com/spring-cloud-samples/config-repo
要在应用程序中使用这些特性,可以将其构建为依赖于Spring -cloud-config-client的Spring boot应用程序。添加依赖项最方便的方法是使用Spring boot start org.springframe .cloud: Spring -cloud-starter-config
。对于Maven用户,还有一个父pom和BOM (Spring -cloud-starter-parent),对于Gradle和Spring CLI用户,还有一个Spring IO版本管理属性文件。下面的例子展示了一个典型的Maven配置:
>
>org.springframework.boot >
>spring-boot-starter-parent >
>{spring-boot-docs-version} >
> <!-- lookup parent from repository -->
>
>
>
>
>org.springframework.cloud >
>spring-cloud-dependencies >
>{spring-cloud-version} >
>pom >
>import >
>
>
>
>
>
>org.springframework.cloud >
>spring-cloud-starter-config >
>
>
>org.springframework.boot >
>spring-boot-starter-test >
>test >
>
>
>
>
>
>org.springframework.boot >
>spring-boot-maven-plugin >
>
>
>
<!-- repositories also needed for snapshots and milestones -->
现在您可以创建一个标准的Spring启动应用程序,如以下HTTP服务器:
@SpringBootApplication
@RestController
public class Application {
@RequestMapping("/")
public String home() {
return "Hello World!";
}
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
当此HTTP服务器运行时,它从端口8888上的默认本地配置服务器(如果它正在运行)获取外部配置。你可以通过bootstrap.properties
(和application.properties
类似,但用于应用程序上下文的引导阶段)配置来改变config server 的位置来改变其启动行为,如下:
spring.cloud.config.uri: http://myconfigserver.com
默认情况下,如果application name没有设置,那么会使用application,可以在bootstrap.properties文件中添加下面这个属性来修改:
spring.application.name: myapp
在设置属性${spring.application.name}时,不要在应用程序名称前加上保留字前缀application—
以防止问题解决于正确的属性源。
引导属性在/env端点中显示为高优先级属性源,如下面的示例所示:
$ curl localhost:8080/env
{
"profiles":[],
"configService:https://github.com/spring-cloud-samples/config-repo/bar.properties":{"foo":"bar"},
"servletContextInitParams":{},
"systemProperties":{...},
...
}
名为configService:/的属性源包含foo属性,其值为bar,是最高优先级。
属性源名称中的URL是git存储库,而不是config server的URL。
Spring Cloud Config Server为外部配置(名称-值对或等效的YAML内容)提供了一个基于HTTP资源的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。最简单的方法是使用spring.config.name=configserver启动它,它也设置了一个默认的配置存储库( 在Config Server jar中有一个默认的configserver.yml文件)。另一种方法是使用您自己的application.properties如下例所示:
application.properties
server.port: 8888
spring.cloud.config.server.git.uri: file://${user.home}/config-repo
u s e r . h o m e / c o n f i g − r e p o 是 一 个 包 含 Y A M L 和 p r o p e r t i e s 文 件 的 g i t 仓 库 。 ∗ 在 W i n d o w s 上 , 如 果 文 件 U R L 是 带 有 驱 动 器 前 缀 的 绝 对 U R L ( 例 如 , / {user.home}/config-repo 是一个包含YAML 和properties 文件的git仓库。 *在Windows上,如果文件URL是带有驱动器前缀的绝对URL(例如,/ user.home/config−repo是一个包含YAML和properties文件的git仓库。∗在Windows上,如果文件URL是带有驱动器前缀的绝对URL(例如,/{user.home}/config-repo),则需要在文件URL中添加一个额外的“/”。*
应该将配置服务器的配置数据存储在哪里?管理这种行为的策略是环境存储库,它服务于环境对象。该环境是从Spring环境(包括propertySources作为主要特性)复制域的浅版本。这些环境资源用三个变量进行参数化:
spring:
application:
name: foo
profiles:
active: dev,mysql
(与Spring引导应用程序一样,这些属性也可以由环境变量或命令行参数设置)。
如果存储库是基于文件的,服务器将从应用程序创建一个application.yml(在所有客户端之间共享)和foo.yml(foo.yml采取优先)。如果YAML文件内部有指向Spring配置文件的文档,那么这些文件将具有更高的优先级(按照列出的配置文件的顺序)。如果存在特定于配置文件的YAML(或属性)文件,则这些文件的优先级也高于默认值。较高的优先级转换为环境中较早列出的PropertySource。(这些规则同样适用于独立的Spring Boot应用程序。)
你可以设置spring.cloud.config.server。accept-empty变为false,这样如果没有找到应用程序,服务器将返回HTTP 404状态。默认情况下,此标志设置为true。
EnvironmentRepository的默认实现使用Git后端,这对于管理升级和物理环境以及审计更改非常方便。要更改存储库的位置,可以设置spring.cloud.config.server.git。配置服务器中的uri配置属性(例如application.yml)。如果您使用file:前缀设置它,那么它应该可以在本地存储库中工作,这样您就可以在没有服务器的情况下快速轻松地启动它。但是,在这种情况下,服务器直接操作本地存储库,而不进行克隆(如果它不是裸的,也没关系,因为配置服务器从不对“远程”存储库进行更改)。为了扩展配置服务器并使其具有高可用性,您需要让服务器的所有实例都指向相同的存储库,因此,只有共享文件系统才能工作。即使在这种情况下,最好使用共享文件系统存储库的ssh:协议,以便服务器可以克隆它并使用本地工作副本作为缓存。
这个存储库实现将HTTP资源的{label}参数映射到一个git标签(提交id、分支名称或标记)。如果git分支或标记名包含一个斜杠(/),那么应该使用特殊的字符串(_)
来指定HTTP URL中的标签(以避免与其他URL路径混淆)。例如,如果标签是foo/bar,那么替换斜杠将会产生以下标签:foo(_)
bar。包含特殊字符串(_)
也可以应用于{application}参数。如果您使用命令行客户机(如curl),请注意URL中的括号—应该使用单引号(")将它们从shell中转义。
可以通过设置git.skipSslValidation属性为真(默认为假)来禁用配置服务器对Git服务器的SSL证书的验证:
spring:
cloud:
config:
server:
git:
uri: https://example.com/my/repo
skipSslValidation: true
您可以配置配置服务器等待获取HTTP连接的时间(以秒为单位)。使用git.timeout属性:
spring:
cloud:
config:
server:
git:
uri: https://example.com/my/repo
timeout: 4
Spring Cloud Config Server支持git存储库URL,它为{application}和{profile}提供了占位符(如果需要,还可以为{label}提供占位符,但是请记住,这个标签是作为git标签应用的)。因此,你可以支持“一个应用程序一个库”的政策,使用类似的结构如下:
spring:
cloud:
config:
server:
git:
uri: https://github.com/myorg/{application}
您还可以使用类似的模式,但使用{profile}来支持“每个概要文件一个存储库”策略。
此外,在{application}参数中使用特殊字符串“(_)”可以支持多个组织,如下例所示:
spring:
cloud:
config:
server:
git:
uri: https://github.com/{application}
在请求时以以下格式提供{application}:organization(_)application。
Spring Cloud配置还支持对应用程序和配置文件名称进行模式匹配的更复杂需求。模式格式是一个以逗号分隔的带有通配符的{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}不匹配任何模式,它使用下面定义的缺省URIspring.cloud.config.server.git.uri
,在上面的例子中,对于“simple”存储库,模式是simple/*(它只匹配所有配置文件中一个名为simple的应用程序)。“local”存储库匹配所有配置文件中以local开头的所有应用程序名称(/*后缀自动添加到没有配置文件匹配器的任何模式中)。
!!! “简单”示例中使用的“一行程序”捷径只有在要设置的惟一属性是URI时才能使用。如果需要设置其他内容(凭证、模式等),则需要使用完整的表单。
repo中的模式属性实际上是一个数组,因此可以使用YAML数组(或属性文件中的[0]、[1]等后缀)绑定到多个模式。你可能需要这样做,如果你要运行多个配置文件的应用程序,如下例所示:
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猜测,包含未以结尾的概要文件的模式意味着您实际上希望匹配以该模式开始的概要文件列表(因此*/staging是["/staging"、"/staging,"等的快捷方式)。这种情况很常见,例如,您需要在本地的“开发”配置文件中运行应用程序,但也需要在远程的“云”配置文件中运行应用程序。
每个存储库还可以选择将配置文件存储在子目录中,并且可以将搜索这些目录的模式指定为searchPaths。下面的例子展示了顶层的配置文件:
spring:
cloud:
config:
server:
git:
uri: https://github.com/spring-cloud-samples/config-repo
searchPaths: foo,bar*
在前面的示例中,服务器在顶层和foo/子目录中搜索配置文件,以及名称以bar开头的任何子目录。
默认情况下,服务器在第一次请求配置时克隆远程存储库。服务器可以配置为在启动时克隆存储库,如下面的顶级示例所示:
spring:
cloud:
config:
server:
git:
uri: https://git/common/config-repo.git
repos:
team-a:
pattern: team-a-*
cloneOnStart: true
uri: https://git/team-a/config-repo.git
team-b:
pattern: team-b-*
cloneOnStart: false
uri: https://git/team-b/config-repo.git
team-c:
pattern: team-c-*
uri: https://git/team-a/config-repo.git
在前面的示例中,服务器在启动时克隆team-a的config-repo,然后才接受任何请求。在从存储库请求配置之前,不会克隆所有其他存储库。
!!! 在配置服务器启动时设置要克隆的存储库,可以帮助在配置服务器启动时快速识别配置错误的配置源(例如无效的存储库URI)。由于没有为配置源启用cloneOnStart,配置服务器可能会使用配置错误或无效的配置源成功启动,并且直到应用程序从配置源请求配置时才检测到错误。
要在远程存储库上使用HTTP基本身份验证,请分别添加用户名和密码属性(不在URL中),如下面的示例所示:
spring:
cloud:
config:
server:
git:
uri: https://github.com/spring-cloud-samples/config-repo
username: trolley
password: strongpassword
如果您不使用HTTPS和用户凭证,那么当您将密钥存储在默认目录(~/. SSH)中并且URI指向SSH位置(如[email protected]:configuration/cloud-configuration)时,SSH也应该开箱即用。Git服务器的条目必须出现在~/中,这一点很重要。ssh/known_hosts文件,并且它是ssh-rsa格式的。不支持其他格式(如ecdsa-sha -nistp256)。为了避免意外,您应该确保Git服务器的known_hosts文件中只有一个条目,并且它与您提供给配置服务器的URL匹配。
如果你不知道你的~/.git
在哪里,使用git config --global
来操作设置(列如:git config --global http.sslVerify false
)
JGit需要PEM格式的RSA密钥。下面是一个示例ssh-keygen(来自openssh)命令,它将生成一个corect格式的密钥:
ssh-keygen -m PEM -t rsa -b 4096 -f ~/config_server_deploy_key.rsa
警告:在使用SSH密钥时,预期的SSH私有密钥必须以-----BEGIN RSA PRIVATE KEY-----
开始,如果密钥以-----BEGIN OPENSSH PRIVATE KEY-----
开头,那么当spring-cloud-config服务器启动时,RSA密钥将不会加载。会出现类似如下的错误:
- Error in object 'spring.cloud.config.server.git': codes [PrivateKeyIsValid.spring.cloud.config.server.git,PrivateKeyIsValid]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [spring.cloud.config.server.git.,]; arguments []; default message []]; default message [Property 'spring.cloud.config.server.git.privateKey' is not a valid private key]
要纠正上述错误,必须将RSA密钥转换为PEM格式。上面提供了一个使用openssh的示例,用于以适当的格式生成新密钥。
Spring Cloud Config Server还支持AWS CodeCommit身份验证。AWS CodeCommit在从命令行使用Git时使用身份验证助手。JGit库没有使用这个助手,所以如果Git URI与AWS CodeCommit模式匹配,就会创建AWS CodeCommit的JGit CredentialProvider。AWS CodeCommit uri遵循以下模式://git-codecommit.${AWS_REGION}.amazonaws.com/${repopath}。
如果您使用AWS CodeCommit URI提供用户名和密码,则它们必须是提供对存储库访问的AWS accessKeyId和secretAccessKey。如果不指定用户名和密码,则使用AWS缺省凭据提供程序链检索accessKeyId和secretAccessKey。如果您的Git URI匹配CodeCommit URI模式(如前面所示),则必须在用户名和密码中或在缺省凭据提供者链支持的位置之一中提供有效的AWS凭据。AWS EC2实例可以为EC2实例使用IAM角色。
Spring Cloud Config Server还支持针对谷歌云源存储库进行身份验证。如果您的Git URI使用http或https协议,并且域名为source.developers.google.com
,则将使用谷歌云源凭据提供程序。一个谷歌云存储库URI的格式是source.developers.google.com/p/${GCP_PROJECT}/r/${REPO}
。要获取存储库的URI,请单击谷歌云源UI中的“Clone”,然后选择“Manually generated credentials”。不生成任何凭据,只需复制显示的URI。
谷歌云源凭据提供者将使用谷歌云平台应用程序缺省凭据。有关如何为系统创建应用程序默认凭据,请参阅谷歌云SDK文档。这种方法将适用于开发环境中的用户帐户和生产环境中的服务帐户。
!!! com.google.auth:google-auth-library-oauth2-http
是一个可选的依赖项。如果google-auth-library-oauth2-http的jar包不在你的classpath中,无论git服务器的URI是什么,都不会创建谷歌云源凭据提供者。
默认情况下,当使用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: [email protected]: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-----
下表描述了SSH配置属性:
Property Name | Remarks |
---|---|
ignoreLocalSshSettings | If true, use property-based instead of file-based SSH config. Must be set at as spring.cloud.config.server.git.ignoreLocalSshSettings, not inside a repository definition. |
privateKey | Valid SSH private key. Must be set if ignoreLocalSshSettings is true and Git URI is SSH format. |
hostKey | Valid SSH host key. Must be set if hostKeyAlgorithm is also set. |
hostKeyAlgorithm | One of ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, or ecdsa-sha2-nistp521. Must be set if hostKey is also set. |
strictHostKeyChecking | true or false. If false, ignore errors with host key. |
knownHostsFile | Location of custom .known_hosts file. |
preferredAuthentications | Override server authentication method order. This should allow for evading login prompts if server has keyboard-interactive authentication before the publickey method. |
Spring Cloud Config Server还支持为{application}和{profile}(如果需要还可以为{label})提供占位符的搜索路径,如下例所示:
spring:
cloud:
config:
server:
git:
uri: https://github.com/spring-cloud-samples/config-repo
searchPaths: '{application}'
前面的清单将在存储库中搜索与目录(以及顶层)同名的文件。通配符在具有占位符的搜索路径中也是有效的(搜索中包含任何匹配的目录)。
如前所述,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: https://git/team-a/config-repo.git
force-pull: true
team-b:
pattern: team-b-*
uri: https://git/team-b/config-repo.git
force-pull: true
team-c:
pattern: team-c-*
uri: https://git/team-a/config-repo.git
!!! force-pull属性的默认值为false。
由于Spring Cloud Config Server在将分支签出到本地repo(例如通过标签获取属性)后复制了一个远程git存储库,所以它将永远保留这个分支,或者直到下一次服务器重启(这将创建新的本地repo)。因此,当远程分支被删除,但它的本地副本仍然可以获取时,可能会出现这种情况。如果Spring Cloud Config Server客户端服务以--spring.cloud.config.label=deletedRemoteBranch
开头,它将从deletedRemoteBranch本地分支获取属性,而不是从master。
为了让本地仓库保存干净和远程仓库同步,可以设置deleteUntrackedBranches参数,它将使Spring Cloud Config Server强制从本地存储库中删除未跟踪的分支。例如:
spring:
cloud:
config:
server:
git:
uri: https://github.com/spring-cloud-samples/config-repo
deleteUntrackedBranches: true #默认false
通过使用spring.cloud.config.server.git.refreshRate
可以控制配置服务器从Git后端获取更新配置数据的频率。此属性的值以秒为单位指定。默认值为0,这意味着每次请求配置服务器时,配置服务器都会从Git repo获取更新后的配置。
!!! 使用基于vcs的后端(git、svn),文件被检出或克隆到本地文件系统。默认情况下,它们被放在系统临时目录中,前缀为config-repo-
。例如,在linux上,它可以是/tmp/config-repo-
一些操作系统经常清理临时目录。这可能会导致意外的行为,比如丢失属性。为了避免这个问题,可以通过将spring.cloud.config.server.git.basedir
或spring.cloud.config.server.svn.basedir
设置为不驻留在系统临时结构中的目录来更改Config Server使用的目录。
配置服务器中还有一个“本地”配置文件,它不使用Git,而是从本地类路径或文件系统中加载配置文件(任何您想用spring.cloud.config.server.native.searchLocations
指向的静态URL)。要使用本机配置文件,请使用spring.profile .active=native
启动配置服务器。
searchLocations的默认值与本地Spring启动应用程序相同(即:[classpath:/, classpath:/config, file:./, file:./config])。这并不会将来自服务器的application.properties
公开给所有客户端,因为在发送到客户端之前,服务器中存在的任何属性源都会被删除。
文件系统后端对于快速启动和测试非常有用。要在生产环境中使用它,您需要确保配置服务器的所有实例之间的文件系统是可靠的和共享的。
搜索位置可以包含{application}、{profile}和{label}的占位符。通过这种方式,您可以隔离路径中的目录并选择对您有意义的策略(例如每个应用程序的子目录或每个概要文件的子目录)。
如果在搜索位置不使用占位符,这个存储库还将HTTP资源的A参数附加到搜索路径的一个后缀上,这样就可以从每个搜索位置和与标签名称相同的子目录加载属性文件(标记的属性在Spring环境中优先)。因此,没有占位符的默认行为与添加以/{label}/
结尾的搜索位置相同。例如,file:/tmp/config
与file:/tmp/config
、file:/tmp/config/{label}
相同。可以通过设置spring.cloud.config.server.native.addLabelLocations=false
来禁用此行为。
Spring Cloud配置服务器也支持Vault作为后端。
Vault是一个安全访问秘密的工具。秘密是您希望严格控制访问的任何东西,比如API密钥、密码、证书和其他敏感信息。Vault为任何秘密提供了一个统一的接口,同时提供了严格的访问控制和记录详细的审计日志。
更多信息请查看:Vault quick start guide.
要使配置服务器能够使用Vault后端,可以使用Vault配置文件运行配置服务器。例如,在配置服务器的application.properties
中,可以添加spring.profiles.active=vault
。
默认情况下,配置服务器假设您的Vault服务器运行在127.0.0.1:8200。它还假设后端名称为secret,密钥为application。所有这些默认值都可以在配置服务器的application.properties
中配置。下表描述了可配置的Vault 属性:
Name | Default Value |
---|---|
host | 127.0.0.1 |
port | 8200 |
scheme | http |
backend | secret |
defaultKey | application |
profileSeparator | , |
kvVersion | 1 |
skipSslValidation | false |
timeout | 5 |
namespace | null |
上表中的所有属性必须以spring.cloud.config.server.vault
为前缀,或放在组合配置的正确保险库部分。
所有可配置的属性都可以在org.springframework.cloud.config.server.environment.VaultEnvironmentProperties
中找到。
Vault 0.10.0引入了一个版本化的键值后端(k/v后端版本2),它公开了一个与早期版本不同的API,现在它需要一个数据/在挂载路径和实际上下文路径之间,并在数据对象中封装秘密。设置spring.cloud.config.server.vault.kv-version=2
将考虑这一点。
另外,还有对Vault企业X-Vault-Namespace
标头的支持。将其发送到Vault设置namespace
属性。
配置服务器运行后,可以向服务器发出HTTP请求,从Vault后端检索值。为此,您需要一个Vault服务器的令牌。
首先,在你的保险库里放一些数据,如下面的例子所示:
$ vault kv put secret/application foo=bar baz=bam
$ vault kv put 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"
}
}
]
}
客户端提供必要身份验证以便配置服务器与Vault对话的默认方法是设置X-Config-Token报头。但是,您可以通过设置与Spring Cloud Vault相同的配置属性来替代省略header并在服务器中配置身份验证。要设置的属性是spring.cloud.config.server.vault.authentication
。应该将其设置为受支持的身份验证方法之一。您可能还需要设置其他特定于您使用的身份验证方法的属性,方法是使用与spring.cloud.vault
文档相同的属性名称,而不是使用spring.cloud.config.server.vault
前缀。更多请查看 Spring Cloud Vault Reference Guide。
如果您省略了X-Config-Token头并使用服务器属性来设置身份验证,则配置服务器应用程序需要对Spring Vault的附加依赖项来启用附加的身份验证选项。查看Spring Vault Reference Guide了解如何添加依赖。
使用Vault时,可以为应用程序提供多个属性源。例如,假设您已经将数据写入了Vault中的以下路径:
secret/myApp,dev
secret/myApp
secret/application,dev
secret/application
写入secret/application的属性对于使用配置服务器的所有应用程序都是可用的。一个名为myApp的应用程序,将任何属性写入secret/myApp和secret/application。当myApp启用了dev配置文件时,上面所有路径的属性对它都是可用的,列表中第一个路径中的属性优先于其他路径。