简而言之，我们有一个包含多个应用程序/服务器的平台 . 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的整个过程也很重要 .
我们更倾向于采用第二种方法，这很容易，但仍然怀疑它是否是一种好的做法？
1 回答
对于代码更改，我建议使用打包器来构建AMI作为CI管道的一部分，使用Terraform和ASG来管理启动配置更改肯定会很麻烦，因为它有多么多，但我认为结果比使用它更干净，更安全 . 用Ansible更新代码 . 你在技术上有一个变化的“记录”，因为你知道你的ansible playbooks以及它们处于什么状态，但我认为应该从CI管道驱动它来构建不可变的工件 .
如果你真的想坚持使用Ansible，你可以随时在你的用户数据中加入一个Ansible playbook，它总是从Master（或其他）中提取最新的代码 . 这可确保新主机提供最新代码，您可以针对预先存在的主机手动调用Ansible . 或者，您可以通过将所需容量加倍来旋转ec2实例来更新代码，并在新的 Health 状态下缩减 . 这可以高度自动化，并为您提供伪金丝雀部署 . 虽然我建议坚持使用不可变的构建 .
出于好奇心，你有没有使用码头工程？我确信你有一个很好的商业理由，但是转移到docker也简化了很多，因为构建一个docker容器和更新ECS任务定义要比部署一个全新的AMI / EC2实例容易得多 .