DevOps之软件配置协作化管理

大家好，我是许二虎，现在负责新一代数字化企业云平台 “The Platform” 的各业务领域系统的设计和开发。很荣幸有这次机会和大家分享交流“DevOps之软件配置协作化管理” 。

首先，我们来看一下为什么需要SCM。

由于每一个人都有可能需要修改配置，以便使之与相应的环境相匹配。

但是，如果没有配置集中的管理又会怎么样呢？开发人员没定义，测试人员不知道配什么，上线人员不知道怎么配。这些问题都直接影响软件的交付进度，这也是DevOps需要解决的问题。

由此，我们得出了SCM的目标，即将配置管理贯穿到软件交付过程中的每个环节。这也与实现cloud-native的12因子之一(在环境中存储配置)是相对应的。

针对SCM的目标，我们来看看SCM的概要设计。在具体的概要设计之前，我们首先需要明确SCM配置的粒度、本次SCM做什么/不做什么、以及在DevOps领域系统中的定位。

SCM配置的粒度为组件。关于组件的概念，之前我的同事王召已经在SPM的微课堂中详细作出过说明。

这里，我再重申一下，组件就是可发布的最小单元。组件可以是一个可运行的jar包、war包、zip包，也可以是发布到nexus上供其它应用依赖的jar包。

配置统一管理由三个基本概念组成：配置定义、环境、配置值。配置定义＋环境 => 配置值（也就是说，一个环境，一套配置值。

SCM本质上也是围绕这三个基本属性的一个配置管理的微服务。

从片子中，我们可以看出SCM主要解决的关键问题和一些好处。

SCM与DevOps其它领域系统中的SPM，VCS，TM，CI都有一定的依赖和交互。其中VCS中的源代码提供了配置模板和元数据，配置元数据可以导入SCM。

SPM提供了组件的相关信息，便于区分哪些配置属于哪些组件。TM提供了租户环境信息，用以为不同租户环境的设置不同的配置值。CI可以将针对于某一环境的一套配置值注入到组件的介质包形成可部署包。

从上图，我们可以看出SCM主要的概念模型有配置项、配置实例、配置提交。其概念模型也会与SPM、TM中的概念模型有所关联。具体来讲，

1）配置的粒度是针对于组件的。一个组件有N个配置项。

2）一个配置项，根据环境可以有不同的配置值。假设有M套环境，一个配置项就有M＊S个配置值 (S为配置提交次数)。

3）针对某一组件某一环境的配置值，用户可以提交多次，每一次提交都是一个全量提交（此处的提交不是指一次增、删、改操作）。这样，我们可以直接比较两次提交都有什么变化。

上图中描述了SCM在一个应用的交互周期中的核心流程。其中，

第1～3步主要涉及到1) 源代码的编写; 2)抽取出配置项元数据的定义 3)确定配置文件模板；

第4～6步主要涉及1) 配置项(定义)的导入/添加; 2) 各环境配置值的设置; 3) 各环境配置值的审批；

第7步是指源代码的编译（此过程的编译结果成为介质包，因为其中不含具体的配置文件）；

第8步是指将某一组件的某一套配置值，注入到该组件对应的介质包中，形成可发布的部署包。

根据SCM的概要设计，我们基本可以看到整个SCM的实现策略。

下面看一下，我们怎样将SCM应用到一个微服务中去开发、测试、上线过程中去。在此，我们必须先引用AutoConfig这一工具。

autoconfig源码地址：https://github.com/webx/citrus-tool/tree/master/antx/autoconfig

文档：http://www.openwebx.org/docs/autoconfig.html

基于SpringBoot开发的微服务只需要将配置信息通过application.yml来组织即可。application.yml只是用于开发人员在本地IDE环境进行代码调试，并为配置文件模板定义好原型。

application.template是根据application.yml抽取出来的配置文件模板。其中${}内的字符就是配置项名称。

auto-conf.xml主要包含两部分：

1）配置元数据的定义，即配置项的定义

2）配置文件生成的脚本定义，如<generate template="application.template" destfile="application.yml"/>

通过上面一个简单的命令，我们就可以完成配置的注入，生成一个针对特定环境的部署包。

关于作者：

许二虎

EAII-企业架构创新研究院 专家委员

现任普元云计算高级工程师。毕业于中国科学技术大学，软件工程硕士。曾任职于群硕软件、科纬迅软件服务、平安健康，具备互联网领域的技术应用经验。在普元云计算平台中的角色是，以靠谱的后端的功底，支撑着整个DevOps业务平台交付。