我一直都在他们以前定期运行 Puppet 的地方工作。因此，分发更改很容易，而且是即时的。在新团队中，他们不赞成定期运行 Chef 代理。他们只使用它来引导操作系统，然后将其关闭。我不明白为什么有人会使用 Chef 这样的配置管理工具，而不必定期运行它。无论我们做什么引导，都可以通过基本的 shell 脚本完成 - 安装 xyz 软件、复制配置文件、重新启动服务。
他们说在生产中定期运行它太危险了，因为他们不确定代码是否是幂等的。
我的疑问是：
- 你们中有多少人使用 Orchestration 工具只是为了引导？这难道不像在小巷里以 20 英里/小时的速度驾驶布加迪吗？
- 当您扩大规模时，定期运行此程序时是否遇到任何问题？您将如何处理？（我知道的一种方法是单独运行代理，并让它们从可以同时处理多个下载的某个存储库/工件中下载食谱，而不是压垮 Puppet/Chef 服务器）。
- 我如何鼓励团队修复代码以实现幂等性并定期运行代理？或者从 Chef 转移到像 bash 这样简单的程序，以减少维护/编写代码的开销。
- 我说的对吗？我们没有按照应有的方式使用这些工具？
- 我是否遗漏了/忽略了什么？
答案1
引导编排
有一些工具，比如 Terraform，实际上就是专注于这一部分流程。我还使用 ansible 来执行一些不需要经常重新运行的临时任务。
不过，一般来说，每小时至少运行一次配置管理是最佳做法。授予或删除访问权限通常通过这些机制进行，而延迟更新可能会导致合规性或可用性问题。在一家大型商店，我们将 Puppet 分成两部分，这样就可以暂停特定于应用程序的内容，而不会破坏处理访问控制更新且“无法”被切断的“影子木偶”。
定期跑步带来的问题
如果你编写了错误的配方，那么你很快就会毁掉所有的生产。有一些流程，角色在进入准备阶段之前被发布到 QA 并验证，在进入生产阶段之前被重新验证。Chef 有内置的测试机制。类似的技术可以与其他技术一起使用。
如何鼓励定期跑步
我首先要关注那些被掩盖的问题。如果你不经常运行你的食谱，那么你不会注意到它们何时因为操作系统或应用程序的更改而开始不起作用。
然后我想说的是，在需要时，可以非常快速地在任何地方进行更改。Chef 运行之间的间隔应该是您愿意等待更改在整个环境中传播的最长时间。
你说得对吗？
大部分情况下都是如此。如果效果足够好，他们可能认为不需要改变任何东西。你可能需要拿出一个演示来展示它的价值，并让人们真正感受到它的价值。或者你可能需要等待你的组织成熟到可以处理你所教的内容的程度。
你错过了什么？
您似乎没有考虑的主要问题是可能的性能影响。如果应用程序对后台运行的内容非常敏感，那么您可能会在 Chef 运行时看到较低的吞吐量或更高的延迟。如果是这种情况，您需要调整配方或仅让它在非高峰时段运行。
我看到的另一件事是内存耗尽。应用程序逐渐消耗内存，直到 Chef 无法再运行。希望您能够监控内存水平以及 Chef 是否正常工作，以便发现此类问题。
除了性能和内存之外，我建议阅读以下书籍释放它这详细解释了如何构建可靠的生产系统。