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