使用AWS和修补程序部署策略进行Terraform

Question

简而言之,我们有一个包含多个应用程序/服务器的平台.Terraform用于管理AWS Infrastructure(VPC,Subnet,IGW,Security Groups,...)和Applications部署(使用Ansible作为Terraform的配置器).对于每个部署,Packer将构建所有AMI,使用适当的名称标记它们,以便从Terraform中获取最新的AMI.

这个过程总体上有效,但是当我们想要部署一些小的修补程序时,我们会面临两难选择,这种情况可能会在每次部署和QA测试之后频繁发生,而某些回归可能会发生.因此,对于需要热修复的每个应用程序(可能不是所有应用程序都需要修复),我们创建一个修补程序分支,构建工件(可能是jar或deb pkg) - 然后有两种情况:

• 触发Packer构建新映像,使用适当的修补程序对其进行标记并运行terraform apply.
• 或者,运行Ansible作业以热部署应用程序包,如果需要,请重新启动服务/应用程序.

使用第一种方法,我们保证遵循Immutable Infra的想法,不幸的是它也造成了一些缺点,因为Terraform配置或Infra中的任何小变化都会导致terraform计划发生变化,例如我们可能会对安全组进行一些更改terraform状态(即:它可能来自某些关于将某些IP列入白名单的功能),并且应用tf将取消所有更改.构建AMI和运行Terraform的整个过程也很重要.

我们更倾向于采用第二种方法,这很容易,但仍然怀疑它是否是一种好的做法？

Answer 1

对于代码更改，我建议使用 packer 构建 AMI 作为 CI 管道的一部分，考虑到它可能有很多错误，使用 Terraform 和 ASG 管理启动配置更改肯定会很麻烦，但我认为结果比使用 Ansible 更新代码。鉴于您知道您的 ansible 剧本以及它们所处的状态，从技术上讲您确实拥有更改的“记录”，但我认为它应该从 CI 管道驱动来构建不可变的工件。

如果你真的想坚持只使用 Ansible，你总是可以在你的用户数据中烘焙一个 Ansible 剧本，它总是从 Master（或其他）获取最新的代码。这可确保新主机提供最新代码，并且您可以针对预先存在的主机手动调用 Ansible。或者，您可以轮换 ec2 实例来更新代码，方法是将所需容量加倍，并在新实例运行正常后缩减规模。这一切都可以高度自动化，并为您提供伪金丝雀部署。不过我再次建议坚持使用不可变的构建。

出于好奇，您不使用 docker 的原因是什么？我确信您有一个很好的商业理由，但迁移到 docker 也简化了很多工作，因为构建 docker 容器和更新 ECS 任务定义比部署全新的 AMI/EC2 实例要容易得多。