amazon-web-services - 何时在 Packer 与 Terraform 中进行配置？

Question

我正面临这样一种情况，即我需要在启动时为 EC2 实例配置一些包。存在几个(企业/公司)约束:

我需要在特定的 AMI 之上进行配置，它添加了诸如 LDAP/AD 访问等企业内容

这些更改旨在用于所有内部开发机器

由于主要是第二个约束，我想知道在哪里放置配置的最佳位置。这就是我想出的

Terraform 中的配置

正如它所说，我只是在 terraform 中提供必要的实例。如果我将这些资源打包成模块，那么配置将不会“泄露”。缺点

我将无法在模块顶部添加一组不同的配置步骤？

配置的更改可能会导致实例在应用时被销毁？

由于它尝试安装的软件包，供应需要很长时间

Packer 中的配置

这是基于 assumption Packer 允许您在 AMI 之上进行配置，以便 AMI 可以“扩展”。此外，这只会在 AWS 中使用，因此不一定会使用其他构建器。 Packer 中的配置使 Terraform 代码更加简单，并且 terraform 应用将变得更快，因为它只是您启动的 AMI。

对我来说，这两种方法都有它们的位置。但我真正想知道的是，你什么时候选择 Packer Provisioning 而不是 Terraform Provisioning？

Answer 1

使用 Packer 创建已完成(或几乎已完成)的镜像可以大大缩短部署新实例所需的时间，并且还允许您使用自动缩放组。

如果您在每次创建 EC2 实例时让 Terraform 运行诸如 Chef 或 Ansible 之类的配置程序，则您会在需要部署新实例时为配置程序添加一段运行时间。在我看来，使用 Packer 尽可能多地烘焙到 AMI 中，然后使用像 Consul-Template 这样的用户数据脚本/工具预先进行配置会更好。提供环境特定的差异。

Packer 当然可以构建在图像之上，实际上需要 source_ami 要指定。我强烈建议以允许您使用 source_ami_filter 的方式标记您的 AMI。在 Packer 和 Terraform 的 aws_ami data source因此，当您对您的 AMI 进行更改时，Packer 和 Terraform 会自动将其拉入以构建或部署在下一次机会。

我个人烘焙了一个相当轻量级的“基础”AMI，它进行了一些基本的强化，并为部署的所有实例设置了我想要的监控和日志记录，并确保 Packer 加密 AMI 的根卷。然后，所有其他镜像都基于最新的“基本”AMI 构建，不必担心确保安装/配置这些东西或担心加密根卷。

通过将您的配置烘焙到 AMI 中，您还可以转向不可 rebase 础架构模型，该模型具有一些主要好处，因为您知道您总是可以丢弃有问题的实例并很快用新实例替换它。根据您的成熟度级别，您甚至可以删除对实例的访问权限，以便在实例部署后无法再更改实例上的任何内容，根据我的经验，这是操作问题的主要因素。

偶尔您可能会遇到一些难以为其烘焙 AMI 的情况，在这些情况下，您可能会选择在创建 Terraform 配置程序时在它中运行您的配置脚本。有时，将现有流程转移到使用带有 Terraform 的配置器比烘烤 AMI 更容易，但我会尽可能将事情转移到 Packer。