theme: condensed-night-purple
小知识,大挑战!本文正在参与“程序员必备小知识”创作活动。
上文讲到了整体流程和版本控制,这篇文章继续后面的工作流程。
三、本地运行代码
对于应用代码,我们可以很容易在本机构建环境,模拟实际业务场景进行测试,对于基础设施相关的代码,我们当然无法在本机再创建计算实例和数据库实例等。但了保证在生产环境的健壮性、安全性,还是很有必要在正式部署之前进行测试,基于Terraform
,我们能手动测试其的唯一方法是在沙箱环境中运行它。
所谓沙箱环境,比如申请专用于开发的云资源操作账户,然后再进行相关的apply
操作,最后再使用Curl
等工具去验证部署的是否成功。
四、进行代码更改和提交评审
进行代码更改当然指的是代码的迭代变化,变化后,需要部署验证测试。这一部分强调在验证过程中,如何节省验证时间?核心主旨在可以并不进行全阶段的验证,可以选择性的验证,比如可以选择性的不创建资源、销毁资源,只是做应用层次的部署,通过这样的方式可以大大地减少反馈时间,提高效率。
提交代码并评审这一部分内容在应用代码开发时,很多开发团队都是遵守的,核心就是创建pull request
完成代码评审。团队作战大家需要遵守同样一套编码准则、代码风格,通过代码评审这样的方式能达到这样的目的。
五、自动化测试
跟应用程序代码一样,使用自动化测试,能满足持续集成(CI)。即通过拦截脚本,在每次提交后触发CI服务器中的自动化测试流程,并在pull request
请求中显示测试的结果。为此我们要做好两件事:
- 为Terraform代码编写单元测试、集成测试和端到端的测试
- 使用
Atlantis
开源工具,在代码提交时自动运行terraform plan
命令,并将 plan命令的输出添加到pull request的注释中。
六、合并和发布
当代码更改和计划输出通过团队成员的评审,并完成所有测试之后。你可以将更改合并到master分支中并发布代码。与应用程序代码流程类似,可以使用Git标记创建发布的版本。
因为Terraform支持从Git存储库直接下载代码,所以特定标签的存储库状态就是将要部署的、不可变的、版本控制的工件。
七、部署
上面代码编写,版本控制,验证、自动化测试完成后,就要开始部署。部署Terraform
代码有一些优化和注意事项,以让工作更加高效。
7.1 部署工具
本身Terraform是一个工具,但在一些方面有局限性,还有一些部署工具包括Atlantis(用于pull request)、Terraform Enterprise(提供UI、管理变量、机密和访问权限)、Terragunt(部署功能增强)、甚至脚本都能较好地改善整个部署管理流程。
7.2部署策略
Terraform本身不提供任何部署策略,需要自己开发模块支持零停机、滚动部署、蓝绿部署、金丝雀部署。但因为其语言本身的局限性,能做到的控制能力是很有限的,所以需要花心思去设计。比如策略性地重试、核心关注Terraform的状态错、对于锁释放出错要有兜底方案等等。
还有一些其它的注意事项,比如应当有一个独立的部署服务器,而不是在开发人员机器上操作;并且对CI服务器应该进行严格的权限控制等等。