我正在为事实上的高可用性服务运行复杂的服务器设置。到目前为止，我大约需要两天时间来设置所有内容，因此我想自动配置。
但是，我对（正在运行的）服务器进行了大量手动更改。一个典型的例子是更改防火墙配置以应对各种黑客攻击、数据包泛滥等。能够快速在活动节点上工作很重要。此外，服务器维护大量活动的 TCP 连接，并且为了简单的配置更改而丢失这些连接是不可能的。
我不明白 Chef 或 Puppet 是否旨在处理此问题。一旦我更改了一些系统配置，我想将它存储在某个地方并在配置下一个实例时使用它。我应该坚持使用其中一种工具还是选择其他工具？
【问题讨论】：
标签： configuration chef-infra puppet provisioning
手动更改和配置无需手动操作。他们甚至不一起喝茶。
在工作中，我们使用 puppet 来管理所有架构，并且由于性能瓶颈、攻击等，我们需要匆忙进行手动更改。
我们要做的是首先确保 puppet 能够设置架构的每个部分，以便在没有任何特定调整的情况下交付。
然后当我们需要进行手动更改时，如果您很着急，只要您不弄乱 puppet 管理的文件就没有风险，如果它是 puppet 管理的文件，我们需要更改，那么我们只需停止 puppet 代理做我们需要的一切。
匆忙结束后，我们进行如下操作：
这些更改应该应用于所有具有相同症状的服务器？
如果是这样，那么您可以开发 puppet 调用的“事实”，它是每次运行时在代理上运行的代码，并将结果保存在所有 puppet 模块中可用的变量中，例如，如果您更改了 ip conntrack max 值因为防火墙无法处理所有连接，所以您可以轻松地（十行代码）在 puppet 中每次运行具有当前 conntrack 计数值的变量，因此告诉 puppet 设置与当前使用情况相关的最大值。然后所有其他服务器都将受益于此调整，并且您可能不再需要处理 conntrack 问题（只要您继续以短频率运行 puppet，这是默认值）
这些更改应始终手动应用在特定紧急情况下？
如果配置是由 puppet 管理的，想办法让配置包含其他文件，并告诉 puppet 忽略它。这是最简单的方法，但并不总是可行（例如 /etc/network/interfaces 不支持包含）。如果不可能，那么您将不得不在紧急情况下停止 puppet 代理，以便能够更改 puppet 文件，而不会在下次 puppet 运行时被删除。
此更改是否仅适用于该主机，其他主机都不需要它？
无论如何都将它添加到人偶中！如果 $fqdn == my.very.specific.host 放一个甜点，然后放入任何你需要的东西。即使对于单个案例，将您所做的所有更改迁移到服务器总是有益的（并且耗时），如果由于某种原因您的服务器崩溃到不可恢复的状态（例如硬件），这将允许您完全恢复服务器设置问题）
总结：
对我来说，处理手工更改的诀窍是花费大量精力来推理您决定如何进行更改，并且在紧急情况结束后将该逻辑转移到傀儡中。如果您因为给定的软件插槽都已使用但服务器上仍有可用内存而感到有问题，那么处理流量峰值是合理的，允许运行更多插槽，然后花一些时间将该逻辑移入 puppet .当然要非常小心，并且与您要测试它的架构上不同场景的数量一样耗时，但最终它会非常、非常有回报。
【讨论】：
我想完成 Valor 的出色回答。
puppet 是一种强制配置的工具。所以你必须这样想：
因此，要回答您的一个问题，puppet 不需要重新启动机器或服务。但是，如果您使用 puppet 设置的配置文件中的更改需要重新启动相应的服务/守护程序/应用程序，那么就无法避免它。 puppet 中有一些方法可以告诉在配置更改的情况下需要重新启动服务。当然，如果 puppet 发现没有任何变化，它不会重新启动服务。
Valor 假设您以客户端/服务器方式使用 puppet，（例如）puppet 客户端每小时轮询 puppet 服务器以获取配置。但也可以将您的 puppet 文件从一台机器移动到另一台机器，例如使用 git，然后手动启动 puppet。这种方式是：
如果您管理大量机器，这显然不是使用 puppet 的最佳方式，但它可能是一个好的开始或一个好的过渡。
而且，木偶很难在一个有趣的水平上学习。我花了 2 周时间才能够从头开始自动安装 AWS 服务器。我不后悔，但如果你必须说服老板分配你的时间，你可能想知道这个事实。
【讨论】：