伪造一切吗？

注意：这里有很多理论问题。

最近，我正在阅读有关Puppet（及类似系统）的信息，据我所相信，它可以使我的工作变得非常轻松。但是我尝试-不幸的是-无法理解我能“伪造”的一切。我可以想象“云”或HA群集，在更多服务器上的配置相同。但是工作站呢？我有一台电脑（带kvm的centos），一台笔记本电脑（fedora）和个人服务器，可以（或应该）将其伪造吗？有哪些（缺点）优势？或在我们公司中，我们有数百台服务器（主要是使用centos），但每个服务器都有点不同。无法决定在一个位置上进行大量配置是否更好。.（Dis）优势？对于您对此主题的所有意见或链接，我将非常高兴。

伪造整个环境的程度取决于几个变量：

• 自动化人员愿意为每个人编写自动化。小。事情。
• 文化条件允许“我只会改变这一件事，无论如何都是一次性的”变成“我只是改变这个木偶清单中的这一件事，现在就应用；这只是一次。”
• 环境中的异质程度。

可以伪造每一个可以伪造的东西，这绝对是可能的，但是要到达那里，需要正确的文化，并且需要能接触伪造设备的每个人的支持。从根本上讲，某些设备很难以这种方式进行管理，例如工作站和puppet作为暂存工具要比配置管理引擎更好。

当您管理大量都在做相同事情的VM时，Puppet很棒。完全胜利，并且没有太多努力才能到达那里。

在另一端，您拥有我上一份工作所拥有的东西，即200多台服务器提供了130种服务，而只有一小部分服务器使用一台以上的机器来提供服务。绝对有一些公司（和大学）在伪造这种东西，但是这很费力，而且需要很多支持。它要求新计算机部署过程的第一步不是 “安装操作系统”，而是“创建清单”。

归根结底，这是您在所有IT员工中必须解决的努力与效率文化的问题。

在所有系统（或其一部分）之间相当相似的任何事情，或者您可以根据可以摆脱的事实建立模板的任何事情facter都是公平的。

真正独特的事情您可能不必理会，而应该只从文件存储桶中提供配置。

属于这两个类别的是我们无法完全了解您的环境就无法做出的决定，因此您需要自己确定。

我认为其他人已经介绍了原因，因此我将介绍方法。我认为通过了解某人如何使用Puppet来完成您想要的事情，可以使决策更加清晰。

先做基本案例

默认情况下，您的Apache Puppet模块不会做太多事情。安装Apache，将其配置为最低标准，然后启动服务。在您需要支持的所有发行版上进行此项工作。

其次增加灵活性

我们需要添加虚拟主机。您最终将获得一个系统，该系统可以根据需要删除文件或将其从一组conf.d或vhosts.d /目录中删除。启用或配置模块也是一样。

使用角色或主机组类将构建模块捆绑在一起

我认为使用Puppet的最佳方法是确保它是可添加的。使用上面的示例，我们应该有一个模块

1. 安装Apache
2. 设置基本配置
3. 将虚拟主机添加到Apache
4. 配置任何其他设置
5. 启动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
}

再次添加。

把特殊情况放在希拉

我非常喜欢让Puppet的Hiera（将其视为Puppet的数据库）来存储特殊位。如果某个主机或主机组需​​要特殊设置，请先将合理的默认设置放入模块中，以便普通用户无需了解该默认设置。然后为那些特殊主机或主机组插入数据，以便Hiera可以使用它，并根据需要将其传递给Puppet。

我的用例是监听端口。某些服务器前面有清漆或透明胶。默认情况下，Puppet模块的Apache使用端口80，但是如果Hiera找到数据，它将覆盖该默认值。

我目前正在Puppetize合理类似的系统与Puppetize一切之间的过渡，并且坚信从长远来看，Puppetize一切都是更好的方法。

如果您对Puppet清单进行版本控制（我们都做到了，对），您将获得基础结构版本控制的所有好处。您的团队将成为运营工程师。这对于特殊的一次性系统与同质奶牛场一样重要。您可以看到谁更改了哪些内容，更改的记录，确切的更改以及回滚更改的能力。

就个人而言，我还发现强迫自己通过Puppet进行所有更改使我对更改进行了更仔细的思考。在编写清单时，与通常在命令行上乱搞相比，我对每个更改都更加关注。

您的Puppet模块也将变得更好。您是否有多个Nginx模块？也许这意味着您的Nginx模块不是那么好，并且您需要使其足够灵活以处理所有特殊需求。至少将相似性抽象到您为“自定义”模块扩展的核心Nginx模块中。

此外，您对在灾难发生时可以将所有特殊需求服务器恢复到当前状态（就配置而言）充满信心吗？如果将工厂Ubuntu服务器放入内部Wiki所需的每项更改都已伪造，则可以轻松地重建Wiki的当前状态，包括Bob昨天对Tomcat的内存调整。

最后，这可能真的很难。如果您没有花时间正确地做事，那么管理许多不同的服务器可能会导致某些骇人听闻的Puppet代码。如果您不使用Puppet Enterprise，请考虑使用hiera和/或ENC（例如Foreman）来帮助您将数据与清单分开。每天都伪造其他东西。在解释Puppet的工作原理时，请同事驱动。每次更改都将变得更加容易。