集中配置管理
本文为阿里云容器服务Spring Cloud应用开发系列文章的第六篇。
一、在阿里云容器服务上开发Spring Cloud微服务应用
三、服务发现
四、服务间通信与集成
五、服务智能路由
六、集中配置管理(本文)
七、高可用和容错
八、监控和日志
在传统的运维中,如果一个服务器或着运行环境升级升级,可以通过自动化脚本对服务器进行更新。随着时间的推移和需求的不断变化,可能需要运维人员登陆进入服务器进行改动。这样做虽然方便,但积累起来会造成服务器环境的"漂移",意味着自从上次代码部署后在这个服务器发生了什么改变谁都不记得了,也许微小的一个差异就会引起错误。
不变基础架构(Immutable Infrastructure)的意思我们不再打补丁了,也不允许运维人员登陆进入手工修改。如果服务器需要升级,那就把原来的服务停掉,删除服务器,用一个新的服务器替换。不变架构保证了线上运行的代码和配置永远是有版本控制,并且一致的。
Spring Cloud Config Server
这样做会带来一些不方便,如果一个服务需要更新一个基础配置,也需要在代码的配置文件中进行更改,构建一个新的镜像,然后把该服务的所有实例停掉进行替换。有时候为了更改一个配置信息而重新构建镜像,这件事总让人觉得有些不对。能不能应用的配置信息也集中管理起来?
Spring Cloud提供的集中配置管理(Config Server)可以解决这个问题。服务在启动的时候统一从一个集中的配置服务器中读取的配置,这样可以保证服务的代码和配置选项都不变的情况下又能够得到最新的配置信息。
我们在下面会演示如何创建Config Server,如何让其它服务访问Config Server。
注意:本文的示例程序没有包含这部分内容。如果向获得详细描述,请参见Spring官方文档。
创建Config Server
在build.gradle中引入对Config Server的依赖。
dependencies {
compile('org.springframework.cloud:spring-cloud-config-server')
...
}
通过@EnableConfigServer
注解将主class声明为Config Server:
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}
}
在application.properties
中定义Config Server的侦听端口和从git中获得配置信息:
server.port=8888
spring.cloud.config.server.git.uri=https://github.com/xxxx/spring-cloud-samples-config
git.uri指向存储配置信息的git仓库,里面为每个服务创建一个.properties文件,例如如下文件目录结构:
$ tree springcloud-samples-config/
springcloud-samples-config/
├── foo-cloud.properties
└── foo.properties
0 directories, 2 files
foo.properties
是为一个名字为foo
的服务存储配置信息的文件,foo-cloud.properties
是同样的foo
服务在cloud profile下使用的配置信息。
具体关于Config Server内容可以参见Spring官方文档:Spring Cloud Config Server。
假定foo
需要一个名字为message
的配置信息,可以在foo.properties
中写入:
message = Spring Cloud!
Config Server启动后可以通过http协议访问,获取配置信息:
$ curl http://localhost:8888/foo/message
Spring Cloud!
在其它服务中配置对Config Server的访问
所有需要从Config Server中获取配置信息的服务,需要在build.gradle
中引入Spring Config依赖:
dependencies {
compile('org.springframework.cloud:spring-cloud-starter-config')
...
}
@RefreshScope
注解将FooController
class声明为从Config Server中获取配置。
@RefreshScope
@RestController
public class FooController {
...
bootstrap.yml
声明Config Server的地址和端口号,在这里分别是config-server
与8888
。
spring:
...
cloud:
config:
uri: http://config-server:8888
启动容器时,通过容器间的links
将真正的Config Server和服务关联起来。
假定这个服务就上文提到的foo
服务,那么它如何获取message
配置呢?这也是通过注解完成。
public class FooController {
...
@Value("${message}")
private String message;
...
@Value("${message}")表示在应用启动时自动注入FooController的message变量。
利用阿里云OSS进行配置信息同步
通过Spring Config Server进行配置信息同步可能有一个潜在的问题,例如上面的示例中,在bootstrap.yml
中配置对配置服务器的访问。bootstrap.yml
是在应用启动时解析的,如果在启动时配置服务器还没有启动则会出现依赖它的所有服务也无法成功启动。
我们这里展示的是通过阿里云的对象存储(OSS)完成服务的集中配置管理。原理是所有的容器挂载OSS,启动成功后容器内的应用从OSS中读取配置。由于OSS具有非常高的可靠性,并且对其内容的更改会被所有服务读到,非常适用于配置信息同步这个场景。
更进一步,阿里云容器服务上提供了OSSFS的支持。OSSFS可以把OSS模拟成为文件系统,应用可以直接用传统的文件系统API访问OSS,而不必使用OSS API。由于一般应用都是将配置存储在文件系统中,使用OSSFS意味着应用不必做任何变更就实现了配置信息的中心化管理。
下面演示如何创建OSS以及挂载OSSFS。
创建OSS Bucket并为子账号授权
进入OSS管理控制台,创建OSS Bucket,注意所属地域要选择容器集群所在地域,如下图所示:
Bucket创建好后,将配置文件上传。
基于安全的考虑,建议进入安全令牌
创建子账号,并记录下AccessKeyId和AccessKeySecret。
进入容器服务控制台,在数据卷
菜单下创建新的数据卷:
选择刚才创建的bucket:
在部署模版文件中为服务挂载OSSFS
在docker-compose.yml中为服务增加如下声明:
bar:
image: xxxx
...
volumes:
- 'foobar-config-oss:/config'
volumes
中,foobar-config-oss
是前面创建的OSS Bucket名字,/config
是在容器中的挂载点。
验证OSSFS是否已经挂载成功
我们准备通过登陆进入容器来验证OSSFS是否已经挂载成功。
首先在容器服务的控制台上点击集群连接信息
进入连接信息页面。
复制环境变量配置,在你的命令行窗口配置环境变量,下载证书,将证书解压缩到工作目录。
在工作目录下运行如下命令,获得挂载OSSFS的容器ID:
docker ps
进入容器,查看/config
下的配置文件内容。
$ docker exec -ti 8eb8de74440c ash
/ # cat /config/bar-config.txt
message=Hello OSS!
可以看到容器已经成功挂载OSSFS。如果配置文件发生变更,上传进入OSS Bucket后容器就可以读到最新的内容。所以容器示例都挂载同一个数据卷,实现了配置信息的集中化管理和分布读取。
小节
本文介绍了如何通过Spring Config Server和阿里云的对象存储OSS来进行配置信息的集中管理。