最早课程格子的后端组织
- 一个巨大rails项目，承载了app端的所有版本的api、很多h5页面、以及运营同学的运营工具
- 电商运营后台
- 教务爬虫系统
- 后端存储服务，如MySQL，PG，Redis，ElasticSearch
项目以ruby为主，部署使用capistrano。
项目部署的水平扩容
- 在这台机器上添加负责部署的工程师public key
- 为项目添加这台机器的public key作为deploy key
- 配置ruby环境
- 拷贝项目的production配置文件
- 配置nginx作为反向代理，serve静态文件
- 针对机器硬件设置web服务器（puma）的进程数、线程数
- 讲机器端口加入Load Balance
这个过程很枯燥也很机械，一个熟练的后端工程师，能在半小时内搞定这些事情。在项目少，机器数量不多的时候，这种方式可以接受。
随着机器增多，项目增多，以及工程师增多，问题出现：
- 部署一个项目时(多环境：sandbox, staging, production)，耗费很多时间，由于项目的增多，这个问题愈发严重
- 服务器的权限管理混乱
- 因为手动分配的计算资源不合理，导致集群部分机器闲的要死，部分机器忙的要命
- 需要编写脚本监视管理进程（god）
- 自动化程度低
- 开始使用更多的语言和框架，部署方式分散，对工程师要求越来越高
开始探索新的部署方案，期望能达到：
- 自动化部署
- 简单的多环境部署 (sandbox，staging，production)
- 进程监控、出错重启
- 部署水平扩容简单(scaling)
- 部署期间服务可用(rolling update)
- 部署出现问题时，能快速回滚(rollback)
- 统一多种语言、框架的部署方式
- 最小程度开放服务器权限
最终采取的方案
gitlab + docker + kubernetes
目前的部署流程
目前格子的开发到部署到上线的流程如下
- 新建branch开发需求
- commit
- push branch
- gitlab ci 构建此branch的image
- gitlab ci 将构建好的image提交到registry
- gitlab ci 在这个image的基础上运行测试
- gitlab ci 将这个image发布到sandbox环境中
- 创建merge request
- Code Review
- Merge Branch To Master
- gitlab ci 构建master的image
- gitlab ci 将构建好的image提交到registry
- gitlab ci 在这个image的基础上运行测试
- gitlab ci 将这个image发布到staging环境
- 确认staging环境代码工作正常
- 手动点击gitlab pipeline中的按钮，一键部署到production
目前的部署方案，解决了上文提出的问题，也满足了上文提到的对部署方式的预期。接下来的部分，我会向大家来介绍如何实现以上的部署方式。在这之前，我需要了解一下THE TWELVE-FACTOR APP。