theme: condensed-night-purple
小知识,大挑战!本文正在参与“程序员必备小知识”创作活动。
前面讲到了如何编写部署的代码,那么对于云基础设施部署,整个流程是怎么样的呢?花两篇文章的篇幅阐述流程的最佳实践。
一、整体流程
基础设施即代码,核心就是代码管理。
【第一步骤】
所以流程第一大部分就是代码管理。其全流程包括:
- 版本控制代码(Using VCS)
- 本地运行代码(Local First)
- 代码更改(Update)
- 提交更改以供评审(Commit And Review)
【第二步骤】
关于基础设施描述的代码修改完成后不能急于执行,当然还要走一下自动化测试。测试通过可进行接下来的步骤,未成功需要重新回到上一步代码管理进行修改操作。
【第三步骤】
测试通过后,就需要进行分支合并,运行等操作了。其全流程包括:
- 合并和发布
- 实施部署
整个流程似乎与应用部署的流程一致,但本质上确存在差异,包括代码更复杂,使用的工具更不容易理解。
二、版本控制
就像我们通过版本管理应用代码的习惯一样,我们在此基础上还有一些其它的要求。包括:
- 双库实践(实时代码库和模块代码库)
- 满足Terraform的黄金法则
- 避免多分支部署
2.1 双库实践
在应用代码中,我们也时常把公用的业务逻辑,统一的工具、或者Infrastructure相关的代码独立成包并单独上一个代码仓库进行管理。
需要至少两个单独的版本控制存储库来存储Terraform
代码,包括:
- 模块代码库
- 实时代码库
模块代码库一个用于存储模块代码,一个用于存储实时基础设施代码。模块存储库用来保存已创建的、可重用的、版本控制的模块代码;另一个实时基础设施存储库存储了每种环境(Dev、Stage、Prod等)中部署的实际基础设施。
根据两个库不同的性质,所以模块代码库建议成立基础设施团队,专门研究创建可重用的,健壮的生产级模块。实时代码库可以让业务团队管理,利用这些模块,来完成他们的工作。
2.2 黄金法则
所谓黄金法则,是为了更好的维护代码,避免团队合作带来的问题。总的思想是:“实时存储库的主代码分支应该以1:1的形式完全代表生产环境中实际部署的内容”。其包括以下细则:
Terraform
的代码即代表基础设施环境,不要试图再用其它方式管理环境- 尽量避免使用工作区来管理环境,强烈建议不同的环境用不同的文件和文件夹来定义,即所见即所有
- 能实际影响部署内容的只能是master,即环境所有的变化都应该体现到master主分支中
2.3 避免多分支部署
其实这一点在上面讲到的黄金法则中已经提到,在团队多人作战中,一定要使用主分支代码进行部署,如果多分支部署,很容易就造成冲突,虽然Terraform plan
能帮我们在正式应用部署之前做预览,察觉到diff的存在,及时止损。但毕竟这样的风险点存在,确实会为生产环境带来很多不确定的风险项。
所以总的来说,因为真实世界只有一个,所以多个分支的Terraform代码并没有太大的意义。因此,对于任何共享环境(如Stage、Prod),请始终从单个分支进行部署。