何时在 Packer 与 Terraform 中进行配置? [英] When to provision in Packer vs Terraform?

问题描述

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

I am sitting with a situation where I need to provision EC2 instances with some packages on startup. There are a couple of (enterprise/corporate) constraints that exist:

• 我需要在特定的 AMI 之上进行配置，这会添加企业的东西，例如 LDAP/AD 访问等
• 这些更改旨在用于所有内部开发机器

主要是因为第二个约束，我想知道在哪里放置配置的最佳位置.这是我想出来的

Because of mainly the second constraint, I was wondering where is the best place to place the provisioning. This is what I've come up with

Terraform 中的配置

正如它所说，我只是在 terraform 中为必要的实例进行配置.如果我将这些资源打包成模块，那么配置将不会泄露".缺点

As it states, I simply provision in terraform for the necessary instances. If I package these resources into modules, then provisioning won't "leak out". The disadvantages

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

在 Packer 中配置

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

This is based on the assumption that Packer allows you to provision on top of AMIs so that AMIs can be "extended". Also, this will only be used in AWS so it won't use other builders necessarily. Provisioning in Packer makes the Terraform Code much simpler and terraform applies will become faster because it's just an AMI that you fire up.

对我来说，这两种方法各有千秋.但我真正想知道的是，你什么时候选择 Packer Provisioning 而不是 Terraform Provisioning?

推荐答案

使用 Packer 创建完成(或几乎完成)的图像大大缩短了部署新实例所需的时间，还允许您使用自动缩放组.

Using Packer to create finished (or very nearly finished) images drastically shortens the time it takes to deploy new instances and also allows you to use autoscaling groups.

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

If you have Terraform run a provisioner such as Chef or Ansible on every EC2 instance creation you add a chunk of time for the provisioner to run at the time you need to deploy new instances. In my opinion it's much better to do the configuration up front and ahead of time using Packer to bake as much as possible into the AMI and then use user data scripts/tools like Consul-Template to provide environment specific differences.

Packer 当然可以建立在图像之上，实际上需要一个 source_ami 被指定.我强烈建议以允许您使用 <代码>source_ami_filter 在 Packer 和 Terraform 的 aws_ami 数据源 因此，当您对 AMI 进行更改时，Packer 和 Terraform 会自动将这些内容拉入，以便在下次机会时构建或部署.

Packer certainly can build on top of images and in fact requires a source_ami to be specified. I'd strongly recommend tagging your AMIs in a way that allows you to use source_ami_filter in Packer and Terraform's aws_ami data source so when you make changes to your AMIs Packer and Terraform will automatically pull those in to be built on top of or deployed at the next opportunity.

我亲自烘焙了一个相当轻量级的基础"AMI，它会进行一些基本的强化，并为所有部署的实例设置我想要的监控和日志记录，并确保 Packer 加密 AMI 的根卷.然后，所有其他映像均基于最新的基本"AMI 构建，无需担心确保已安装/配置这些东西或担心加密根卷.

I personally bake a reasonably lightweight "Base" AMI that does some basic hardening and sets up monitoring and logging that I want for all instances that are deployed and also makes sure that Packer encrypts the root volume of the AMI. All other images are then built off the latest "Base" AMI and don't have to worry about making sure those things are installed/configured or worry about encrypting the root volume.

通过将您的配置烘焙到 AMI 中，您还可以转向不可变的基础架构模型，该模型具有一些主要优势，因为您知道您始终可以丢弃有问题的实例并很快将其替换为新的一.根据您的成熟度级别，您甚至可以删除对实例的访问权限，这样一旦部署实例就无法再更改任何内容，根据我的经验，这是导致操作问题的主要因素.

By baking your configuration into the AMI you are also able to move towards the immutable infrastructure model which has some major benefits in that you know that you can always throw away an instance that is having issues and very quickly replace it with a new one. Depending on your maturity level you could even remove access to the instances so that it's no longer possible to change anything on the instance once it has been deployed which, in my experience, is a major factor in operational issues.

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

Very occasionally you might come across something that makes it very difficult to bake an AMI for and in those cases you might choose to run your provisioning scripts in a Terraform provisioner when it is being created. Sometimes it's simply easier to move an existing process over to using provisioners with Terraform than baking the AMIs but I would push to move things over to Packer where possible.

这篇关于何时在 Packer 与 Terraform 中进行配置?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！