烘烤不可变图像

#1 楼

您的问题的一个想法关键是不可变的基础架构，即一个映像只能构建一次，可以部署多次，并且在运行时不会更改。如果图像的内容需要更改，则从头开始构建一个全新的图像，并用新实例替换运行旧图像的实例。通常是从通用OS映像引导计算机（或容器），然后由配置管理工具持续对其内容进行管理。在此模型中，实例的寿命通常更长，并且可以根据新要求进行就地更改。

打包程序旨在作为不可变基础结构的构建块。旨在协调立即启动到所需状态的自定义映像的创建。如果不可变的基础架构适合您的用例（不一定是这种情况！），则确实不需要诸如Ansible，Chef和Puppet之类的工具。

但是，在Packer的“一次性”模式（例如Chef Solo）通常对于非平凡的图像很有用：这些工具通常提供比Packer单独提供的功能更强大的抽象，从而使诸如配置init系统运行某些程序等操作变得更容易服务，或创建用户帐户。在这种情况下，配置管理工具将在Packer中作为配置程序运行，在映像中创建必要的配置，但不参与对从映像启动的实例进行的持续维护。

大多数实际的系统包括可变的和不可变的基础结构的混合，因为例如不变的基础架构不适用于有状态的集中式系统。在这种情况下，使用传统的配置管理系统可在不可变和可变系统之间建立通用的功能基础，以一次性方式将配置应用于不可变映像，并以持续，有状态的方式将其应用于长期运行，可变机器。

#2 楼

图像的生成和分发迅速上升到O（n ^ 2）或更高，并且由于terraform明确地专注于实例化，因此它依赖外部供应者提供内部状态。

它会以较小的规模工作，但是

还会使混合云模型变得非常复杂，并且如果系统的寿命很长，则会出现问题。

它还会在重构迭代过程中造成困难，但这取决于您的用例。 >
例如，假设您要部署新版本的python模块。如果您有轮子或Requirements.txt，则可以将其部署到操作系统版本c和d的云提供程序a，b，c。但是，对于完全烘焙的图像，您将不得不生成并测试图像a_c，b_c，c_c，a_d，b_d，c_d。如果必须在每次迭代中执行此操作，则开发人员生产力的成本将迅速增长。

请注意，您可能会假设图像将完全不可变，但是如果没有配置管理工具，您将无能为力。确保它们是正确的。

由于容器现在通常在受信任的模型下工作，因此对于有权在docker等框架下启动计算机的任何进程或个人进行任意更改，这都是微不足道的对于系统上的任何对象（每个API用户都是root用户，甚至在docker的主机上都是root用户），这都是您要考虑的偶然性。

如果保持云提供商，应用程序和基础之间的松散耦合操作系统随着时间的流逝要容易得多，而缓解供应商也要容易得多。

如果为GCE，AWS和Azure维护terraform配置，则按操作系统配置打包程序，然后单独使用应用程序部署方法增加了最初的复杂性，但是这些费用将很快摊销超出了项目的整个生命周期。

我个人发现像ansible这样的工具可以在没有集中式基础架构的情况下运行，并且可以根据状态进行有计划的更改，从而在纯部署模型中更加灵活，但是我始终不得不在某种程度上进行某种形式的配置管理改造。

这可能不会直接映射到您的特定用例，但这是很常见的惯例，这是一个很好的理由。

#3 楼

我看不到打包程序和ansible / chef / puppet之间的关系。 Packer可能会提供一种方法来声明您正在构建映像，但是如果您不打算使用ansible / chef / etc之类的内容来加载映像中所需的内容，那么您将如何建议将其放入其中图像吗？

通常，默认的答案是“好吧，我们将其编写脚本”，但是她将脚本仅仅是可以将任何东西粘在一起的粘合剂，它们并不是专门为处理基础结构而设计的和配置。

我已经在一个项目上工作了一段时间，在这个项目中，我们做出了明智的决定，尝试不编写任何shell脚本，即使编写起来不太方便。一切都以其他人为之保持标准的明确定义的语言（最好是声明性语言）进行（例如，我们不需要确保ansible可以完成我们需要做的事情，我们可以让开发人员来做，而不是为所有内容编写脚本，并且需要自行编写所有详细操作）。

将您的配置管理工具作为一种很好的方法来声明基本映像中的实际内容，然后，如果您希望开发人员信任其代码将在其上运行的映像，那么您将有一个很好的起点。