III. 配置
将配置保存在环境中
应用的配置是指在各种部署（预发，线上，开发环境等）时的信息。这包括：
- 处理数据库，缓存或其他后端服务的资源
- 亚马逊s3或Twitter等外部服务的验证信息
- 像部署用的主机名这种预部署的值信息
应用有时将部署信息放在代码的常量中。这违反了12因子规则，规则要求将配置从代码中隔离。配置可以在各种差异极大的部署中传递，代码不能。
一种检验应用是否配置正确成为开箱即用的方式是，应用可以在任何时刻开源，不需要对一些凭证信息妥协。
记住这里对“配置”的定义不包括应用内部配置，比如Rails的config/routes.rb， 或者代码模块是如何连接到Spring的。这种类型的配置在部署时不会差异极大，所以最好还是写在代码里。
另一种做配置的方式是使用不会提交到版本控制里的配置文件（config files），如Rails的config/database.yml。这相比会提交到代码库中的常量是一种巨大的进步，但仍有弱点：在将配置文件提交到仓库时很容易出错；配置文件有一种以各种格式并放在各种地方的趋势，使得在一处管理所有配置很难。而且，这些格式会与使用的语言和框架有关。
** 12因子应用将配置信息存储在环境变量中**（一般是env vars或env）。Env vars可以在部署时很简单的做变更并且不需要更改任何代码；不像配置文件，它们几乎没有机会被意外的提交到代码库；也不像自定义配置文件，或其他像Java System Properties的配置机制，它们是与语言和操作系统无关的。
配置管理的另一个层面是分组。有时应用被批量配置到一个已经被特定部署命名过的分组（一般叫做“环境”），比如Rails中的 开发(development)，测试(test)，生产（production） 环境。这样的方式不太适合伸缩： 当应用有新的环境部署时，就需要一个新环境的命名，比如预发和测试。当项目发展起来，开发可能会添加他们特定的环境，比如 joes-staging，会造成管理应用部署的配置爆炸。
在12因子应用中，env 变量是粗粒度控制。它们从不被分组成“环境”，但每个部署集群会被独立管理。这种方式可以更平滑的对应用做伸缩，在其生命周期中部署到更多的集群。
本文来自微信公众号「麦芽面包」，id「darkjune_think」
转载请注明。
交流Email: zhukunrong@yeah.net
