何时在Packer和Terraform中进行配置？

Question

我正在处理一个情况，需要在启动时为EC2实例提供一些软件包。存在几个（企业/公司）限制：

- 我需要在特定AMI之上进行配置，该AMI添加了诸如LDAP / AD访问等企业级功能 - 这些更改旨在用于所有内部开发机器

主要由于第二个限制，我想知道放置配置的最佳位置。这是我想出的：

- 在Terraform中进行配置：只需在必要的实例中进行配置即可。如果将这些资源打包到模块中，则配置不会“泄漏”。缺点是无法在模块之上添加不同的配置步骤？配置更改可能会导致实例被销毁并重新应用？由于它试图安装的软件包，配置需要很长时间。 - 在Packer中进行配置：基于假设，Packer允许您在AMI之上进行配置，以便可以“扩展”AMI。此外，这仅用于AWS，因此不一定使用其他生成器。在Packer中进行配置使得Terraform代码更简单，并且terraform应用程序将变得更快，因为它只是启动的AMI。

对我来说，这两种方法都有它们的用处。但我真正想知道的是，在什么情况下选择Packer配置而不是Terraform配置？

- Shiraaz.M

Answer 1

使用Packer创建完成（或几乎完成）的镜像可以极大地缩短部署新实例所需的时间，还允许您使用自动扩展组。如果您让Terraform在每次创建EC2实例时运行像Chef或Ansible这样的配置管理工具，则需要增加一段时间来运行配置管理工具以便在需要部署新实例时使用。我认为最好的方法是使用Packer提前对配置进行设置，并尽可能多地将其捆绑到AMI中，然后使用用户数据脚本/工具（如Consul-Template）提供特定于环境的差异。

当然，Packer可以在现有镜像的基础上构建，实际上需要指定一个source_ami。我强烈建议以一种允许您在Packer和Terraform的aws_ami数据源中使用source_ami_filter的方式标记您的AMI，以便在对AMI进行更改时，Packer和Terraform会自动获取并构建或部署它们。

我个人制作了一个相当轻量级的“基础”AMI，其中进行了一些基本的加固和设置监控和日志记录，我希望所有部署的实例都能够使用，并确保Packer对AMI的根卷进行加密。然后，所有其他映像都是基于最新的“基础”AMI构建的，无需担心安装/配置这些内容或担心加密根卷。

通过将配置嵌入到AMI中，您还可以向不可变基础架构模型迈进，其中有一些重要的好处，因为您知道始终可以丢弃出现问题的实例并快速替换为新实例。根据您的成熟度水平，甚至可以删除对实例的访问权限，以便在部署后不再可能更改实例上的任何内容，而这在我的经验中是操作问题的主要因素之一。

很少情况下，您可能会遇到一些难以制作AMI的东西，在这种情况下，您可以选择在创建时在Terraform提供程序中运行配置脚本。有时，将现有过程移动到使用Terraform提供程序比制作AMI更容易，但我会推荐尽可能将事情转移到Packer。

- ydaetskcoR

Answer 2

我遇到过相同的情况。据我所知：

• 如果您经常启动 EC2 实例（例如每天 2 至 3 次），则可以使用 packer 创建自定义 AMI，然后通过 terraform 调用该 AMI。
• 如果基础镜像（由 packer 创建的 AMI）根据您的要求频繁更改，则适合使用 packer。但对于我来说，运行 packer 脚本非常耗时。
• 您也可以使用 packer 完成同样的工作。您可以在脚本中编写您的要求，并在 terraform 中调用它。将所有内容都整合到 terraform 脚本中会节省一些时间。

最终决定取决于您启动 EC2 实例的频率。

- MS_22