最近参与了 PaaS（也叫某某 App Engine，和 Google 学起名字）开发，总结、整理一下我实践十二因子的方式，供参考。相信你能找到更好或更合适的方式。
I. 基准代码
一份基准代码，多份部署
我们采用 gitlab 管理代码并采用 gitflow 工作流，当代码在 feature 分支开发完成并在 release 分支测试完毕后，会被合并到 master，此时机器人会构建 Docker 镜像、推送到 Harbor、让生产环境拉取镜像并依照预先定义的策略（重建、蓝绿等）进行升级。同时，我们每个人也能拉取到新的镜像和代码。
II. 依赖
显式声明依赖关系
对于 Java 程序，在 Gradle 中写明依赖关系；对于 Python 程序，将依赖保存在 requirements.txt，在 Dockerfile 文件中让 pip 安装 txt 文件中指明的依赖，而不是在 Dockerfile 文件中 RUN pip install（不够直观）；对于 Go 程序，go.mod 会指明依赖关系。我们暂时没有其他语言的后端服务。
如果程序依赖其他程序（如调用系统的 ping），可以把依赖顺便放入镜像。
III. 配置
在环境中存储配置
Docker 容器在运行前，可以传递环境变量进去，Kubernetes 当然也支持这种方式。在程序代码中，先读取环境变量（约定好默认值），成功获取环境变量后再干其他事情。
IV. 后端服务
把后端服务当作附加资源
用字符串（URL）表示一个资源，如 MySQL，RabbitMQ，Kafka，Ceph。适当修改、封装这些基础软件的客户端，使得加载它只需要一个函数：
db = connect_rdbms('mysql://......')
store = connect_cephfs('......')
V. 构建，发布，运行
严格分离构建和运行
用自动化工具实现。
VI. 进程
以一个或多个无状态进程运行应用
将所有需要保存的状态和需要持久化的数据存在后端服务（如 Redis 或 MySQL）中。
VII. 端口绑定
通过端口绑定提供服务
通过 Docker 和 Kubernetes 实现。服务 A 需要服务 B 的时候，可以从注册中心（或其他类似的地方）拿到 B 暴露的地址和端口。
VIII. 并发
通过进程模型进行扩展
我实现了基于 APM 和弹性伸缩控制程序。在需要时增加或减少一个 Deployment（或 StatefulSet，DaemonSet，等等）的副本数。
IX. 易处理
快速启动和优雅终止可最大化健壮性
代码中，要注意处理停止信号。
X. 开发环境与线上环境等价
尽可能的保持开发，预发布，线上环境相同
Docker 实现。
XI. 日志
把日志当作事件流
对于把日志写进文件的老应用，部署一个 filebeat 用于收集日志；对于新开发的应用，把日志打到控制台（Docker 会收集它）。将日志收集后统一送到 ElasticSearch 或其他适合存储日志的地方。
XII. 管理进程
后台管理任务当作一次性进程运行
管理任务（如数据库迁移，如登录控制台看东西）要和程序处在同一环境。Docker 实现。
综合感悟：Docker 和 Kubernetes 对实现十二因子的帮助真的很大。有了这两个，我们很快就构建了基本可用的一个 PaaS，开发人员们的效率显著提高，产品发布的频率显著加快，各个人员的心智负担都减轻了，产品也更不容易出错。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
