我坐的情况是我需要在启动时为一些软件包配置EC2实例 . 存在一些（企业/公司）约束：
-
我需要在特定的AMI之上进行配置，这会增加企业级的东西，比如LDAP / AD访问等等
-
这些更改旨在用于所有内部开发计算机
由于主要是第二个约束，我想知道放置配置的最佳位置在哪里 . 这就是我想出来的
Provision in Terraform
正如它所述，我只是为了必要的实例提供了terraform . 如果我将这些资源打包到模块中，那么配置就不会“泄漏” . 缺点
-
我将无法在模块顶部添加一组不同的配置步骤？
-
配置的更改可能会导致实例在申请时被销毁？
-
由于尝试安装的软件包，配置需要很长时间
Provisioning in Packer
这是基于assumption，Packer允许您在AMI之上进行配置，以便AMI可以是"extended" . 此外，这只会在AWS中使用，所以它赢得了't use other builders necessarily. Provisioning in Packer makes the Terraform Code much simpler and terraform applies will become faster because it'只是你启动的AMI .
For me both of these methods have their place. But what I really want to know is when do you choose Packer Provisioning over Terraform Provisioning?
2 回答
使用Packer创建完成（或非常接近完成）的图像可以大大缩短部署新实例所需的时间，还允许您使用自动缩放组 .
如果您在每次创建EC2实例时都有Terraform运行Chef或Ansible之类的配置器，那么您需要为需要部署新实例时的配置器添加一段时间 . 在我看来，使用Packer尽可能多地烘焙到AMI然后使用用户数据脚本/工具（如Consul-Template）来提前和提前进行配置要好得多，以提供特定于环境的差异 .
Packer当然可以构建在图像之上，实际上需要指定source_ami . 我强烈建议您以一种允许您在Packer和Terraform的aws_ami data source中使用source_ami_filter的方式标记您的AMI，这样当您对AMIs Packer进行更改时，Terraform会自动将这些更改为在下一次机会之上构建或部署 .
我亲自烘焙了一个相当轻量级的“Base”AMI，它可以进行一些基本的强化，并为所有部署的实例设置我想要的监控和日志记录，并确保Packer加密AMI的根卷 . 然后，所有其他映像都是根据最新的“Base”AMI构建的，并且不必担心确保安装/配置这些内容或担心加密根卷 .
通过将配置烘焙到AMI中，您还可以转向不可变基础架构模型，该模型具有一些主要优点，因为您知道您可以随时丢弃有问题的实例并快速将其替换为新实例 . 根据您的成熟度级别，您甚至可以删除对实例的访问权限，以便在部署实例后不再可能更改实例，根据我的经验，这是操作问题的主要因素 .
偶尔您可能会遇到一些使得为AMI烘焙非常困难的事情，在这种情况下，您可能会选择在Terraform配置器创建时运行配置脚本 . 有时将现有流程移动到使用Terraform的配置器比烘焙AMI更容易，但我会尽可能地将事情移交给Packer .
我遇到过同样的情况 . 据我所知
如果您经常说出您的EC2实例每天2至3次，那么请使用打包器创建自定义AMI，然后通过terraform调用ami .
如果您的基本图像（由打包程序创建的AMI）根据您的要求经常更改，那么打包机会很好 . 但对我来说，运行打包程序脚本非常耗时 .
您也可以对包装工做同样的事情 . 您可以在脚本中编写需求并以terraform形式调用它 . 将所有内容合并到一个terraform脚本中会减少一些时间
最后你的决定和你提出EC2实例的频率 .