自从 上次 简单提到应用配置管理的几种方式以来，我都在尝试不同的方式，到目前为止，仍觉得 ** 剥离单独管理 ** 加上 ** 动态配置服务器 ** 的方式最好用，接下来谈谈原因以及具体实践。

原因

记录变更与审计

其实这个涉及到 CD，即持续交付的范畴，为了保证线上应用环境的稳定性，如果配置无法追踪的话，即意味着你不能在出问题的时候，快速定位原因，处理问题。

因此，放到 CVS 系统中就可以非常方便审计，在更新提交历史中查找即可。

自动化

与 CD 配合，即你可以提交到 CVS 系统后，采用 CD 方式直接将各个不同环境中的配置更新。

简单，直观，简洁

在 CVS 中，可以直接看到修改的内容，同事也能知道你修改过什么。

环境统一

这意味着，你可以快速重建自动化生产环境，或者很方便地搭建预发布环境，而由于两个环境相似，一旦在预发布环境上验证过相关的脚本之后，就可以在生产环境中出问题时候，排除脚本问题。

实践

git submodule

主项目中，可以直接 git submodule 结合起来：

1
2
cd project-root/
git submodule add https://github.com/your-group/project-config config

npm private module

即相当于拆出一个单独的配置管理模块。
发布时：

1
2
3
4
npm set registry http://private-registry-url/
npm adduser --registry http://private-registry-url/

npm publish

安装时：

1
npm install @your-group/config --registry

具体的 npm private registry，你可以付费使用 npmjs 的服务，也可以自己搭建一个。

搭建的话可以看这里：https://github.com/verdaccio/verdaccio，用 docker 部署非常方便：

1
docker run -d --name verdaccio -d -p 4873:4873 verdaccio/verdaccio

动态配置

可以使用 etcd，Node.js 应用中使用 nconf 以及 nconf-etcd2

1
npm i nconf nconf-etcd2 --save

在配置文件中：

1
2
3
4
5
6
7
8
9
10
11
nconf.env();

nconf.defaults({
    NODE_ENV: 'development',
    ETCD_HOSTS: 'localhost:2379',
});

nconf.add('etcd', {
    namespace: nconf.get('NODE_ENV'),
    hosts: nconf.get('ETCD_HOSTS').split(',')
});

然后，在项目直接使用 nconf.get 即可，当然了，为了达到动态更新的目的，可以使用 node-etcd 提供的 watch 方法，实时监听配置变化。

P.S.

不知道你注意到没有，我在这篇文章中，特意在配置管理之前加了『应用』两个字，这是有原因的：

配置管理不仅包括应用的配置，而且还包括线上环境所有相关的配置，如基础设施的配置：服务器的配置，网络的配置等。

在 《持续交付》 这本书中，给配置管理的定义是：

配置管理是指一个过程，通过该过程，所有与项目相关的产物，以及他们之间的关系，都被唯一的定义、存储、检索和修改。

显然，应用配置管理只是配置管理的一小部分而已，而配置管理是所有自动化的基础与前提，做好配置管理至关重要。

多余的不在这里赘述，下次需要专门讲讲持续交付。

首发于 Github issues: https://github.com/xizhibei/blog/issues/41 ，欢迎 Star 以及 Watch

本文采用 署名-非商业性使用-相同方式共享（BY-NC-SA）进行许可
作者：习之北 (@xizhibei)
原链接：https://blog.xizhibei.me/2017/03/03/ying-yong-pei-zhi-guan-li-shi-jian/