定期运行 Chef/Puppet 的优缺点是什么？

Question

我总是在他们曾经定期运行 Puppet 的地方工作。因此，分发更改很容易且即时。在新团队中，他们不赞成定期运行 Chef 代理。他们只用它来引导操作系统，然后杀死它。我不明白为什么有人会使用像 Chef 这样的配置管理工具而不必定期运行它。无论我们在做什么引导，都可以通过基本的 shell 脚本来完成 - 安装 xyz 软件，复制配置文件，重新启动服务。

他们说在生产中定期运行它太危险了，因为他们不确定代码是否是幂等的。

我的查询是：

• 你们中有多少人使用编排工具只是为了引导？这不就像在小巷里以每小时 20 英里的速度驾驶布加迪一样吗？
• 当您扩大规模时，您在定期运行此程序时是否发现任何问题？你会怎么处理？（我知道的一种方法是在单独模式下运行代理，让他们从可以处理同时进行多个下载的某个存储库/人工工厂下载食谱，而不是压倒 Puppet/Chef 服务器）。
• 我如何鼓励团队将代码修复为幂等的并定期运行代理？或者从 Chef 转移到像 bash 这样简单的东西，以减少维护/编写代码的开销。
• 我说的对，我们没有按照应该使用的方式使用这些工具吗？
• 我在这里遗漏/忽略了什么吗？

Answer 1

引导编排

像 Terraform 这样的工具实际上专注于流程的这一部分。我还使用 ansible 来执行一些不需要经常重新运行的临时任务。

但一般来说，最佳实践是至少每小时运行一次配置管理。授予或删除访问权限通常是通过这些机制进行的，延迟更新可能会导致合规性或可用性问题。在一家大型商店，我们将 puppet 一分为二，以便可以暂停特定于应用程序的内容，而不会破坏处理访问控制更新且“无法”被切断的“影子木偶”。

经常跑步带来的问题

如果你写了糟糕的食谱，那么你可以很快毁掉所有的生产。有一些流程，在进入暂存之前将角色发布到质量检查中并进行验证，并在进入生产之前重新验证。Chef 有内置的测试机制。类似的技术可以与其他技术一起使用。

如何鼓励定期运行

我首先会关注那些被掩盖的问题。如果您不经常运行您的食谱，那么您不会注意到它们何时因为操作系统或应用程序的更改而开始不起作用。

然后我要提到的是，当需要时，可以很快地在任何地方进行更改。Chef 运行之间的间隔应该是您愿意等待更改在整个环境中传播的最长时间。

你说得对吗？

大多。如果它对他们来说足够好，他们可能认为没有必要改变任何东西。您可能需要拿出一个演示来展示其价值并使其对人们来说是真实的。或者，您可能需要等待您的组织成熟到可以处理您所教授的内容。

你缺少什么？

您似乎没有考虑的主要事情是可能的性能影响。如果应用程序对后台运行的内容非常敏感，那么您可以在 Chef 运行时看到较低的吞吐量或较高的延迟。如果是这种情况，您需要调整您的食谱或仅让它在非高峰时间运行。

我见过的另一件事是内存耗尽。该应用程序会逐渐消耗内存，直到厨师无法再工作。希望您能够监控记忆水平以及厨师是否正在工作以捕捉此类事情。

除了性能和内存之外，我建议阅读像《Release It》这样的书，它详细解释了如何构建可靠的生产系统。