注意：有很多理论问题。
最近我在阅读有关 Puppet（和类似系统）的文章，我相信它可以让我的工作轻松很多。但我尝试（但不幸的是无法）理解我可以“傀儡化”的所有东西。我可以想象“云”或 HA 集群，其中相同的配置在更多服务器上。但是工作站呢？我有一台 PC（带 kvm 的 centos）、一台笔记本电脑（fedora）和个人服务器，可以（或应该）将其傀儡化吗？有哪些（缺点）优势？或者在我们公司，我们有数百台服务器（主要使用 centos），但每台服务器都有点不同。无法决定是否最好在一个地方拥有大量配置。（缺点）优势？我很高兴收到您对这个主题的所有意见或链接。
答案1
控制整个环境的程度取决于几个变量：
- 自动化人员愿意为每一件小事编写自动化程序。
- 文化条件使得“我只会改变这一点，反正这只是一次性的”变成了“我只会改变这个傀儡清单中的这一点，然后立即应用它；这只是一次性的”。
- 环境中的异质性程度。
完全有可能将每个可以傀儡化的 ********** 东西傀儡化，但要做到这一点需要正确的文化和所有可以接触傀儡设备的人的支持。有些设备从根本上很难以这种方式管理，例如工作站，而傀儡作为暂存工具比配置管理引擎更好。
当你管理一组虚拟机，它们都做着大致相同的事情时，Puppet 非常棒。完全成功，而且不需要付出太多努力。
而另一方面，我上一份工作中也遇到过类似的情况，有 200 多台服务器提供 130 项服务，其中只有一小部分服务器使用多台机器。绝对地一些公司（和大学）已经实现了这种功能，但这需要付出很多努力，需要很多支持。它要求新机器部署过程的第一步不是是“安装操作系统”，而是“创建清单”。
归根结底，这是一个努力与效率的文化问题，您必须在所有 IT 员工中解决。
答案2
任何在所有系统（或其中的子集）中合理相似的东西，或者你可以根据事实建立模板的东西都是facter公平的游戏。
您可能不应该为真正独特的事情烦恼，而应该只从文件桶中提供配置。
对于属于哪一类，如果我们不深入了解您的环境，我们就无法做出决定，所以这需要您自己去弄清楚。
答案3
我认为其他人已经解释了为什么，所以我将尝试解释如何。我认为通过了解某人如何使用 Puppet 来做你想做的事情，这将使决策更加清晰。
先做基本案例
默认情况下，Apache 的 Puppet 模块不会做太多事情。安装 Apache，将其配置为最低标准，然后启动服务。让此操作在您需要支持的所有发行版上都有效。
其次增加灵活性
我们需要添加 vhosts。最终您将得到一个可以根据需要从一组 conf.d 或 vhosts.d/ 目录中删除或删除文件的系统。启用或配置模块也是一样。
使用角色或主机组类别将您的构建块绑定在一起
我认为使用 Puppet 的最佳方式是确保它具有可添加性。使用上面的例子，我们应该有一个模块可以做到
- 安装 Apache
- 设置基本配置
- 将虚拟主机添加到 apache
- 配置任何额外设置
- 启动 Apache
我们不应该让我们的默认 Apache 模块过载来为特定主机或组执行我们所需的操作，而应该将其作为角色或主机组类来处理。
class role::web_cust1 {
include apache
apache::vhost {'www.domain.com': }
apache::vhost {'www.domain2.com': priority => '99', }
include php
include php-fpm
include mysql
}
再次添加。
将特殊情况放入 Hiera
我非常喜欢让 Puppet 的 Hiera（可以将其视为 Puppet 的数据库）存储特殊位。如果某个主机或主机组需要特殊设置，则首先将合理的默认值放入模块中，这样普通用户就不需要知道它了。然后插入这些特殊主机或主机组的数据，以便 Hiera 可以根据需要使用它并将其传递给 Puppet。
我的用例是 Listen 端口。一些服务器前面有 Varnish 或 haproxy。默认情况下，Puppet 模块让 Apache 使用端口 80，但如果 Hiera 找到数据，它将覆盖该默认值。
答案4
我目前正在从 Puppetize 与 Puppetize everything 相当相似的系统过渡，并确信从长远来看，Puppetize everything 是一种更好的方法。
如果您对 Puppet 清单进行版本控制（我们都这样做，对吧），那么您将获得基础架构版本控制的所有好处。您的团队将成为运营工程师。这对于特殊的一次性系统和同质的养牛场一样重要。您可以获得一份日志，记录谁更改了某些内容、他们何时更改了某些内容、具体更改了什么，以及回滚更改的能力。
就我个人而言，我发现强迫自己通过 Puppet 进行每项更改会让我更加仔细地考虑更改。当我编写清单时，我会比通常在命令行上乱敲代码时更加关注每项更改。
您的 Puppet 模块也会变得更好。您有多个 Nginx 模块吗？也许这意味着您的 Nginx 模块不是那么好，您需要使其足够灵活以处理您的所有特殊需求。至少将相似之处抽象为核心 Nginx 模块，然后扩展为“自定义”模块。
此外，当灾难发生时，您是否有信心将所有特殊需求的服务器恢复到其当前状态（就配置而言）？如果将工厂 Ubuntu 服务器纳入内部 wiki 所需的每项更改都经过 Puppetized，则您可以轻松重建 wiki 的当前状态，包括 Bob 昨天对 Tomcat 内存进行的调整。
最后，这可能真的很难。如果你不花时间把事情做好，管理大量不同的服务器可能会导致一些黑客式的 Puppet 代码。如果你不使用 Puppet Enterprise，请考虑使用 hiera 和/或 ENC（如 Foreman）来帮助将数据与清单分开。每天都对其他东西进行 Puppet 化。让同事开车，同时你解释 Puppet 中的工作原理。每次更改都会变得更容易。