众所周知，配置在项目开发中非常重要，一般来说，我们都会根据环境会有不同的配置，比如本地开发会配置本地机器的数据库，测试时还会给数据库设置不同的本地数据库，然后线上线下也会有不同的配置，其中非常值得注意的便是：生产环境的配置，因为这些配置非常敏感，需要加密。

把配置直接放进代码管理 repo 是最低级的做法：历史记录会有永远记录着配置中的敏感信息，看过不少初学者这么干，一搜历史记录所有的密码都出现了，github 一搜一大堆，更有甚着，把密码替换掉，然后 commit。。。哎。。。

如果这个项目只是公司内部，不会被外人发现，那也倒勉强可以接受，只是一旦公司大了，这些敏感信息也不是所有开发人员可以看到的，于是就很麻烦了。

那么，接下来说说，怎么解决：

我们的需求：** 安全 & 方便 **

剥离

一般来说，最简单的方式：从项目文件中剥离，并 ignore，git 中是放入. gitignore。然后配置单独管理，只有被授权的开发人员才能获取查看。只是这样的话，单独管理增加成本，前期几乎也是对所有人可见，新开发人员需要获取开发配置后才能继续，每次修改生产环境配置的话，都得一个个修改配置文件，以及对 CI 以及 CD 不友好（一般来说，CI 还有 CD 都是直接清理本地非 repo 文件，然后拉取新代码，于是你得添加一个专门获取配置的过程）。

加密配置

比如 Blackbox，是将配置文件加入 repo，但是呢，是加密过的，利用 GPG 加密，安全性还是不错的，也很方便管理，只是，会有一些学习成本，在接受范围之内。

单独管理动态

动态以及非初始化配置，可以放到专门的配置管理服务器上，比如 Vault、zookeeper、etcd 还有 consul，其中 vault 非常适合敏感信息的配置，它甚至可以做到即使黑客侵入内网，也不会像静态文件那么容易获取信息。还有个非常棒的优点：统一管理，不用担心每个服务器上的配置不统一，也能动态的更新。

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

本文采用 署名-非商业性使用-相同方式共享（BY-NC-SA）进行许可
作者：习之北 (@xizhibei)
原链接：https://blog.xizhibei.me/2016/09/11/tan-tan-xiang-mu-de-pei-zhi-guan-li/