amazon-web-services - 使用 AWS 和修补程序部署策略的 Terraform

Question

简而言之，我们有一个包含多个应用程序/服务器的平台。 Terraform 用于管理 AWS 基础设施(VPC、子网、IGW、安全组等)和应用程序部署(利用 Ansible 作为 Terraform 的供应商)。对于每个部署，Packer 将构建所有 AMI，用适当的名称标记它们，以便从 Terraform 中提取最新的 AMI。

这个过程通常是有效的，但是当我们想要部署一些小的修补程序时，我们会面临一个困境，这可能会经常发生，因为在每次部署和 QA 测试之后，可能会发生一些回归。因此，对于每个需要热修复的应用程序(可能不是所有应用程序都需要修复)，我们创建一个热修复分支，构建工件(可以是 jar 或 deb pkg) - 那么有两种情况:

要么触发 Packer 构建新镜像，用适当的修补程序标记它并运行 terraform apply。

或者，运行 Ansible 作业以热部署应用程序包，如果需要，重新启动服务/应用程序。

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

我们更倾向于第二种方法，这很容易，但仍然想知道这是否是一种好的做法？

Answer 1

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

如果您真的只想坚持使用 Ansible，您可以随时将 Ansible playbook 放入您的用户数据中，该手册始终从 Master(或其他任何代码)中提取最新代码。这可确保新主机提供最新代码，并且您可以针对预先存在的主机手动调用 Ansible。或者，您可以轮换 ec2 实例来更新代码，方法是将所需容量加倍，并在新实例运行良好后缩减。这一切都可以高度自动化，并且会给你一个伪金丝雀部署。再次，尽管我建议坚持使用不可变的构建。

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