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