我正处于需要在启动时为EC2实例提供一些软件包的情况。存在两个(企业/公司)约束:


我需要在特定的AMI之上进行配置,这将添加诸如LDAP / AD访问之类的企业内容。
这些更改旨在用于所有内部开发机器


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

在Terraform中提供

正如它指出的那样,我只是在terraform中提供了必要的实例。如果将这些资源打包到模块中,则配置不会“泄漏”。缺点


我将无法在模块顶部添加一组不同的设置步骤?
设置的更改可能会导致实例在应用时被销毁?
由于要尝试安装软件包,因此配置需要很长时间


在Packer中置备

这基于Packer允许您在AMI之上进行配置的assumption,以便可以“扩展” AMI。另外,此方法仅在AWS中使用,因此不必使用其他构建器。 Packer中的资源调配使Terraform代码更加简单,并且Terraform代码将变得更快,因为它只是您启动的AMI。

对我来说,这两种方法都有自己的位置。但是我真正想知道的是,什么时候选择Packer Provisioning而不是Terraform Provisioning?

最佳答案

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

如果让Terraform在每次创建EC2实例时都运行诸如Chef或Ansible之类的资源调配器,则会在需要部署新实例时增加一定的时间让资源调配器运行。在我看来,最好先使用Packer尽可能早地将其烘焙到AMI中,然后使用诸如Consul-Template之类的用户数据脚本/工具提供特定于环境的差异,然后再进行配置。

Packer当然可以在图像之上构建,并且实际上需要指定source_ami。我强烈建议您以一种允许您在Packer和Terraform的source_ami_filter中使用aws_ami data source的方式标记AMI,这样,当您对AMI进行更改时,Packer和Terraform会自动将其构建或构建在AMI之上在下一个机会。

我亲自烘焙了一个相当轻量的“ Base” AMI,该AMI进行了一些基本的强化,并为所有部署的实例设置了所需的监视和日志记录,并确保Packer加密AMI的根卷。然后,所有其他映像都是基于最新的“ Base” AMI构建的,不必担心确保已安装/配置了这些内容,也不必担心加密根卷。

通过将配置烘焙到AMI中,您还可以朝着不可变的基础架构模型迈进,该模型具有一些主要优点,因为您知道您总是可以丢弃有问题的实例,并很快用新实例替换它。根据您的成熟度级别,您甚至可以删除对实例的访问权限,这样,一旦实例被部署,就不再可能更改任何实例,根据我的经验,这是操作问题的主要因素。

有时,您可能会遇到难以烘焙AMI的情况,在这些情况下,您可能会选择在创建Terraform预配器时运行预配脚本。有时,将现有流程转移到与Terraform一起使用预配器要比烘焙AMI容易得多,但是我会尽可能将内容移到Packer。

07-24 09:39
查看更多