六个月前，在我们的非营利项目中，我们决定开始将我们的系统管理迁移到 Puppet 控制的环境，因为我们预计从现在到一年后我们的服务器数量将大幅增长。
自从做出决定以来，我们的 IT 人员经常会感到有点恼火。他们最大的反对意见是：
- “我们不是程序员，我们是系统管理员”；
- 网上有很多模块，但是很多模块彼此之间都存在差异；轮子被重新发明得太频繁了，你如何决定哪一个适合呢？
- 我们的仓库中的代码不够透明，为了找到某些东西是如何工作的，他们必须通过清单和模块进行递归，他们甚至可能在不久前自己编写了这些清单和模块；
- 一个新的守护进程需要编写一个新的模块，约定必须与其他模块类似，这是一个困难的过程；
- “我们来运行一下，看看效果如何”
- 社区模块中有大量几乎不为人知的“扩展”：“trocla”、“augeas”、“hiera”......我们的系统管理员如何跟踪？
我明白为什么大型组织会派遣他们的系统管理员参加 Puppet 课程，成为 Puppet 大师。但如果小型企业不参加课程，而是主要通过浏览器和编辑器学习，他们如何才能将 Puppet 学习到专业水平？
答案1
我在部署新的基础设施之前就开始使用 Puppet，并且只是买了一个（备受推崇) 书籍。我认为大多数人实际上并没有接受过专业的 Puppet 培训。我研究了示例，直到我能够将流程塑造成适合我的环境。这是 2011 年 12 月，所以在几周内，我能够理解基础知识并建立生产框架。我对配置管理并不陌生，有CF引擎背景，但您的许多系统管理员的担忧引起了共鸣。我犯了错误，不得不多次重构，但我确实让事情令人满意地运转起来。
关于你的观点的几点注释...
传统的系统管理角色正在发生变化。要么适应，要么被淘汰。我曾经是一名成功的系统工程师，但也必须重新调整（例如学习 Python）。随着通过虚拟化实现硬件抽象以及公有云和私有云服务的发展，对单个服务器的关注度逐渐降低。这意味着系统任务的自动化和使用配置管理来夺取对大量服务器的控制权。添加DevOps 概念混合起来，你会看到客户/最终用户的期望且要求正在发生变化。
网上提供的 Puppet 模块在风格和结构上有所不同，是的，我看到了很多重叠、冗余和重复的工作。我曾与之共事的一位开发人员说：“你本来可以在网上寻找有用的东西，然后花点时间开发自己的工具！”这让我停下来思考，因为我意识到 Puppet 似乎更吸引开发人员，而不是寻找最佳实践或者正确的方法方法。
大量记录是为了了解事物是如何联系在一起的。鉴于定义不明确，缺乏标准做事的方式，您的配置管理结构确实是您环境所独有的。这种透明度必须在内部发展。
我认为复制一个模块来容纳一个新的守护进程或者将服务添加到现有清单是相当容易的，这取决于您如何组织您的服务器和角色。
在将更改推送到更大的服务器组之前，我花了很多时间在单个目标上进行测试。在代表性服务器上手动运行 puppetd 使我能够调试更改并评估其影响。也许这有点保守，但这是必要的。
我不确定我会在多大程度上依赖社区模块。我确实必须开始使用 Augeas 进行一些工作，并对这是我在 CFEngine 中视为理所当然的功能感到遗憾。
总而言之，我觉得 Puppet 并没有一个明确的标准。我很难弄清楚如何在 Puppetmaster 上组织目录结构，理解如何管理证书签名，正确的反向 DNS无处不在，让 Puppet 适当扩展对于环境，并了解何时利用社区模块而不是构建自己的模块。这是一种思维转变，我知道这会让系统管理员感到恐慌。然而，这也是从头开始构建的解决方案，所以我有评估工具的奢侈。决定这样做是基于思想共享和 Puppet 背后的动力。学习新东西是值得的。
记住，本网站也是一个很好的资源。
答案2
在之前的工作中，我被分配了一项任务，即进行 Puppet 的试点实施。现在，我有编程背景，虽然不是 Ruby，所以我遇到的问题不像其他人那么多。
然而，值得注意的是程序员没有非传统范式经验的人也会对 Puppet 感到困惑，因为 Puppet声明式，而不是命令式的。从这个意义上讲，Puppet 的工作方式与任何配置文件非常相似：您指定应该如何操作，Puppet 会处理其余的事情。
试用后，我有机会培训了十几位其他管理员使用 Puppet，并在两次活动中进行了演示。从那次经历中我得出的结论是，有些管理员喜欢它，有些则不喜欢。这些都是传统管理员，没有编程技能，专业水平也参差不齐。
我注意到的一件特别的事情是 Puppet 需要持续的练习。接受培训、编写模块，然后花一两个月时间做其他事情的人，回到 Puppet 时几乎没有什么有用的技能。每周坚持在 Puppet 上做些小事情的人永远不会失去这种能力。
基于以上两个观察，我建议大家每周都添加一些 Puppet 类、定义或模块（最好至少两三次）。那些还不习惯的人可能真的缺乏这方面的技能。
再说，如果 Puppet 是高层强加给他们的，他们可能只是在对他们所认为的管理层干涉他们工作的方式做出反应——事实上，这确实没错。让他们选择哪个配置管理系统的使用将改善这种情况。以下是一些替代方案：
答案3
我在一家小公司使用 Puppet 已有两年多了，当时我是唯一的系统管理员。我遇到的最大障碍是学习如何正确开发软件。我没有一周不搞砸一些我已经告诉开发人员不要做的事情。我签入了太多代码，没有拆分签入，没有标记，没有分支，没有运行语法检查器，没有使用标准，等等。如果你刚刚开始，我建议你遵循以下一些建议。
- 意识到你正在开发的软件要么你不知道该怎么做，要么你做得很差。这是意料之中的，因为它是新软件。
- 基础设施即代码是现实，一旦你克服了困难，它就会变得非常强大。我会邀请一些开发人员过来，向他们展示你当前的开发流程（或缺乏的流程），当他们提出质疑时不要生气，并认真对待他们的建议。我建议使用你的开发人员使用的任何系统和流程，除非它完全不合适。
- Puppet 第三方模块 90% 的时间都很糟糕。我会阅读它们。我会从中窃取想法。我不会在没有进行重大编辑的情况下将它们引入我的系统。但是我会引入 puppet stdlib，它增加了一些不错的功能。
- augeas 和 hiera。了解这两个。第一个允许对现有文件进行复杂的编辑。第二个是外部数据存储。
- 将代码与数据分开。这是最难学习的概念之一。将诸如监控主机之类的值硬编码到模块代码中是不好的。将它们放在模块可以使用的数据存储（db、yaml（Hiera 默认使用此格式）、csv 等）中是好的。一个例子是使用 Mysql 的 Web 应用程序。这允许分别推送代码和数据。这使您的开发过程更简单。
- puppet 解析器验证和puppet-lint作为代码签入前或签入后过程的一部分。此外，一旦您熟悉了，rspec 测试可能是一个好主意。
- 编写样式指南/代码标准并使用它。“安装 Apache 的代码在哪里”是一个常见问题。如果您的模块大致相同，这应该很容易。
总而言之，我遇到了所有这些问题，我的大多数系统管理员朋友也遇到了。要熟练使用配置管理系统需要一些时间。一旦你学会了，你就会想知道如果没有它你是怎么生活的。“登录服务器并手动进行更改？真讨厌。”
答案4
KISS（保持简单）——不要仅仅因为有新技术就使用它们，而要因为您有需求才使用它们，使用部署所需的最低限度，根据需要进行更新，不要试图跟上前沿技术。如果您从基本设置开始并在此基础上进行构建，那么随着您的学习，您会更容易掌握它们，而且它们不需要课程（这些课程甚至可用吗？）。
另一个可以关注的领域是系统管理员。如果他们编程能力不强，那么他们是否足够先进，可以胜任大规模部署？无论使用什么工具，大部分工作都需要编写脚本。