Workflow and Step Strategy#

Important

这部分是我们这套最佳实践的核心思想, 请仔细阅读.

在企业级项目中, 每一个 AMI 的构建过程可能包含非常多步骤. 如果我们将这些步骤放在单个 packer build 中进行, 那么构建时间就会很长, 并且出错的概率会很高. 一旦出错, 我们就需要从头再来, 会非常浪费时间, 为了验证一个 bug 可能要等前置步骤完成. 比较工程化的做法是将复杂的流程分拆成多个小步骤, 每个小步骤都会输出一个 AMI, 后一个步骤基于前一个步骤来进行构建. 这样我们可以用中间的 AMI 来创建 EC2 然后 SSH 进去 debug. 这样很容易对每一个步骤的逻辑进行检查和定位问题, 反馈速度也会比较快.

我们的 packer 脚本就是根据这个策略来设计的. 我们定义:

  1. Workflow: 一个为了构建一个复杂的 AMI 的工作. 比如普通 packer 开发者会用一个 packer template 来构建一个 AMI, 而我们将这个过程拆分成了多个步骤, 合起来就是一个 workflow. 一个 workflow 会有一个唯一的 ID, 通常我们使用 目标 + 日期时间 作为 ID. 例如 object-2023-01-01-09-00-00. 这样在我们每隔一段时间就要重新运行 workflow 的情况下, workflow id 天生就是可排序, 人类友好的.

  2. Step: 在一个过程中每一次运行 packer build 生成一个过度 AMI 的活动就是一个 Step. Step id 是 semantic 的, 这个步骤要做什么就叫什么. 举例来说, 如果第一步是安装 pyenv, 那么这个步骤的 ID 就是 pyenv. 总体来说, 越是更新频率低的部分我们就越先构建. 例如 Python Runtime 大概率我们是不需要重新构建的, 所以我们放在第一个 Step. 而 Application Code 的编译是要频繁更新的, 所以我们放在最后一步.