THE TWELVE-FACTOR APP
THE TWELVE-FACTOR APP一文提供了一套方法论，内容可以分成两个部分：
- 一个最大化可移植性、可持续交付、易扩展的项目源代码应该符合哪些规则。
- 应该如何部署项目代码来处理请求、处理并发、处理日志以及管理（启动、终止、监视）进程。
上述的第二条，我会在之后的章节中提到，这些也正是kubernetes解决的问题。
这里我们着重说说一点：一个最大化可移植性、可持续交付、易扩容的项目源代码应该符合哪些规则。重点有两个：如何配置，如何处理依赖。
下面先举一些反面例子：
配置冗余
曾经部署过一份外包公司产出的代码，上线前需要改一个微信分享地址的url的host，测试环境与正式环境的host不同，部署一个环境，单是这一个配置就需要修改6个文件的8个地方。部署一个环境尚且费事，更不用提多环境部署。
有隐式依赖
语言级别的库依赖一般会有比较好的解决方案，例如ruby的bundler，python的pip。隐式依赖的问题一般出现在系统级别的库和软件。例如在项目中需要操作图片，依赖机器安装imagemagick，但是imagemagick并没有写在项目的依赖中，而是需要部署的机器事先安装好。当把项目部署在新机器上的时候，很容易漏掉安装imagemagic的步骤，导致服务错误。快速的水平扩展无从谈起，因为需要了解项目到底有哪些隐藏的依赖没有安装。
最佳实践：
配置
例如数据库连接地址、Redis地址、微信公众号appid与secret、用来加密cookie的SECRET_KEY_BASE、微信分享url等任何需要控制项目行为的配置。
- 配置和代码严格分离。不同环境的部署使用同样的代码，不同的配置。
- 使用环境变量作为配置。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码，环境变量与语言和系统无关。
- 环境变量的粒度要足够小，且相对独立。
依赖
- 使用包管理器处理语言级别的库。
- 使用容器技术来确保项目的系统级别的类库依赖完整。
依赖处理发生在项目构建时，配置发生在项目运行时。所以我们接下来就要进入Docker相关的章节，来讨论如何构建项目，处理依赖；以及项目构建完成，将要运行项目时，如何注入配置。