简而言之，我们有一个包含多个应用程序/服务器的平台。 Terraform用于管理AWS Infrastructure（VPC，Subnet，IGW，Security Groups，...）和Applications部署（使用Ansible作为Terraform的配置器）。对于每个部署，Packer将构建所有AMI，使用适当的名称标记它们，以便从Terraform中获取最新的AMI。
这个过程总体上有效，但是当我们想要部署一些小的修补程序时，我们会面临两难选择，这种情况可能会在每次部署和QA测试之后频繁发生，而某些回归可能会发生。因此，对于需要热修复的每个应用程序（可能不是所有应用程序都需要修复），我们创建一个修补程序分支，构建工件（可能是jar或deb pkg） - 然后有两种情况：
使用第一种方法，我们保证遵循Immutable Infra的想法，不幸的是它也造成了一些缺点，因为Terraform配置或Infra中的任何小变化都会导致terraform计划发生变化，例如我们可能会对安全组进行一些更改terraform状态（即：它可能来自某些关于将某些IP列入白名单的功能），并且应用tf将取消所有更改。构建AMI和运行Terraform的整个过程也很重要。
我们更倾向于采用第二种方法，这很容易，但仍然怀疑它是否是一种好的做法？
对于代码更改，我建议使用打包器来构建AMI作为CI管道的一部分，使用Terraform和ASG来管理启动配置更改肯定会很麻烦，因为它有多么多，但我认为结果比使用它更干净，更安全。用Ansible更新代码。你在技术上有一个变化的“记录”，因为你知道你的ansible playbooks和他们所处的状态，但我认为它应该从CI管道驱动来构建不可变的工件。
如果你真的想坚持使用Ansible，你可以随时在你的用户数据中加入一个Ansible playbook，它总是从Master（或其他）中提取最新的代码。这可确保新主机提供最新代码，您可以针对预先存在的主机手动调用Ansible。或者，您可以通过将所需容量加倍来旋转ec2实例来更新代码，并在新的健康状态下缩减。这可以高度自动化，并为您提供伪金丝雀部署。虽然我建议坚持使用不可变的构建。
出于好奇心，你有没有使用码头工程？我确信你有一个很好的商业理由，但是转移到docker也简化了很多，因为构建一个docker容器和更新ECS任务定义要比部署一个全新的AMI / EC2实例容易得多。