小家伙们如何有效地学习和使用Puppet呢？

Question

六个月前，在我们的非营利项目中，我们决定开始将系统管理迁移到 Puppet 控制的环境，因为我们预计从现在到一年后我们的服务器数量将大幅增长。

自从做出决定后，我们的 IT 人员就变得有点过于恼火了。他们最大的反对意见是：

• “我们不是程序员，我们是系统管理员”；
• 模块可在线获取，但许多模块彼此不同；轮子经常被重新发明，你如何决定哪一个合适；
• 我们的 repo 中的代码不够透明，要找到某些东西是如何工作的，他们必须通过清单和模块进行递归，他们甚至可能在不久前自己编写；
• 一个新的守护进程需要编写一个新的模块，约定必须与其他模块相似，这是一个困难的过程；
• “让我们运行它，看看它是如何工作的”
• 社区模块中有大量鲜为人知的“扩展”：“trocla”、“augeas”、“hiera”……我们的系统管理员如何跟踪？

我可以理解为什么大型组织会派遣他们的系统管理员参加 Puppet 课程以成为 Puppet 大师。但是，如果小玩家不参加课程并且基本上通过浏览器和编辑器学习它，他们如何将 Puppet 学习到专业水平？

Answer 1

我在部署新基础设施之前就开始使用 Puppet，并简单地买了一本关于这个主题的（广受好评的）书。我认为大多数人实际上并没有获得专业的 Puppet 培训。我一直在研究示例，直到我可以将过程塑造到我的环境中。那是 2011 年 12 月，所以在几周内，我就能够了解基础知识并建立一个生产框架。我对配置管理并不陌生，有CFEngine背景，但您的许多系统管理员的担忧引起了共鸣。我犯了错误，不得不多次重构，但我确实让事情令人满意地工作。

关于你的观点的一些注意事项......

• 传统的系统管理角色正在发生变化。适应或被抛在后面。我一直是一名成功的系统工程师，但我也不得不重新调整工具（例如，学习 Python）。随着通过虚拟化和公共和私有云服务获得的硬件抽象化，对单个服务器的关注减少了。这意味着系统任务的自动化和使用配置管理来控制大量服务器。将DevOps 概念添加到组合中，您将看到客户/最终用户的期望和要求正在发生变化。

• 在线提供的 Puppet 模块在风格和结构上各不相同，是的，我看到了很多重叠、冗余和重复的工作。一位与我共事的开发人员说：“你可以在网上寻找有用的东西的时间开发自己的工具！” 这让我停顿了一下，因为我意识到 Puppet 似乎比寻求最佳实践或正确方法的管理员更能吸引开发人员类型。

• 大量记录以了解事物之间的联系。鉴于不稳定的定义和缺乏标准的做事方式，您的配置管理结构对于您的环境来说确实是独一无二的。这种透明度必须在内部发展。

• 我认为复制一个模块以适应新的守护进程或向现有清单添加服务是相当容易的，这取决于您组织服务器和角色的方式。

• 在将更改推送到更大的服务器组之前，我花了很多时间对单个目标进行测试。在代表性服务器上手动运行 puppetd ​​使我能够调试更改并评估其影响。也许这有点保守，但这是必要的。

• 我不确定我对社区模块的依赖程度。我确实不得不开始使用 Augeas 做一些工作，并感叹这是我在 CFEngine 中认为理所当然的功能。

总而言之，我觉得在 Puppet 方面没有一个明确定义的标准。我在弄清楚如何在我的 Puppetmaster 上组织目录结构、了解如何管理证书签名、在任何地方设置适当的反向 DNS、让 Puppet为环境适当扩展以及了解何时利用社区模块与构建我自己的模块时遇到了麻烦。这是一种思维方式的转变，我明白这会让系统管理员感到恐慌。然而，这也是从头开始构建的解决方案，所以我有机会评估工具。走这条路的决定是基于思想共享和 Puppet 背后的动力。努力学习新东西是值得的。

请记住，该站点也是一个很好的资源。

Answer 2

在之前的一份工作中，我被分配了做 Puppet 的试点实施的任务。现在，我有编程背景，虽然不是 Ruby，所以我没有其他人那么大的问题。

然而，有趣的是，没有非传统范式经验的程序员也有使用 Puppet 的问题，因为 Puppet 是声明式的，而不是命令式的。从这个意义上说，Puppet 的工作方式与任何配置文件非常相似：您说事情应该如何，Puppet 会负责其余的工作。

试点结束后，我有机会用 Puppet 培训了十几位其他管理员，并在两次活动中进行了介绍。我从那次经历中得出的结论是，有些管理员接受了，有些则没有。这些都是传统的管理员，没有编程技能，专业知识水平也各不相同。

我注意到的一件特别的事情是 Puppet 需要不断的练习。那些接受过培训、编写模块，然后花了整整一两个月做其他事情的人回到 Puppet 时几乎没有什么有用的技能。每周都在里面做一些小事的人，从来没有失去过这种能力。

基于这两个观察，我建议您确保每个人每周都不断添加一些 Puppet 类、定义或模块（最好至少添加两到三次）。那些还不能适应的人可能真的缺乏做这件事的技巧。

再说一次，如果 Puppet 是从上级强加给他们的，他们可能只是对他们认为的管理人员干预他们的工作方式做出反应——事实上，这已经足够了。情况可能是让他们选择使用哪个配置管理系统会有所改善。以下是一些替代方案：

• ANSIBLE：这是新的，但它基于 shell 命令和 ssh，这可能会吸引传统的系统管理员。
• Chef : 也许他们的问题是声明式风格，在这种情况下，如果他们有 Ruby 经验，Chef 会更好。
• SaltStack：基于 Python 的开源
• CFEngine：旧的、快速的、传统的——它可能会在这些方面赢得他们的青睐。

Answer 3

我已经在小商店使用 Puppet 两年多了，在那里我是唯一的系统管理员。我遇到的最大障碍是学习如何正确开发软件。已经有一周时间我没有把我告诉开发人员不要做十几次的事情搞砸了。我检查了太多代码，我没有分解签入，我没有标记，我没有分支，没有运行语法检查器，没有使用标准等等。如果你刚刚开始我会推荐以下一些。

1. 意识到您正在开发您不知道如何做或做得很差的软件。这是预料之中的，因为它是新的。
2. 基础设施即代码是现实，一旦你克服了困难，它就会变得非常强大。我会邀请一些开发人员过来，向他们展示您当前的开发过程（或缺少的过程），当他们扬眉时不要生气，并认真对待他们的建议。我建议使用您的开发人员使用的任何系统和流程，除非它完全不合适。
3. Puppet 第三方模块在 90% 的时间里都很糟糕。我会阅读它们。我会从他们那里窃取想法。如果没有重大编辑，我不会将它们拉入我的系统。但是我会引入 puppet stdlib，它增加了一些不错的功能。
4. augeas 和 hiera。学习这两个。第一个允许对现有文件进行复杂的就地编辑。第二个是外部数据存储。
5. 将代码与数据分开。这是较难学习的概念之一。将监控主机等值硬编码到模块代码中是不好的。将它们放在您的模块可以使用的数据存储（db、yaml（Hiera 使用此为默认值）、csv 等）中是很好的。一个例子是一个使用 Mysql 的 webapp。这允许分别推送代码和数据的能力。这使您的开发过程更简单。
6. puppet 解析器验证和puppet-lint作为您前或后代码签入过程的一部分。此外，一旦您掌握了速度，rspec 测试可能是一个好主意。
7. 编写样式指南/代码标准并使用它。“安装Apache的代码在哪里”是一个常见问题。如果您的模块大部分相同，那应该很容易。

总之，我遇到了所有这些问题，我的大多数系统管理员朋友也是如此。熟练使用配置管理系统需要一些时间。一旦你这样做了，你会想知道没有人你是如何生活的。“登录服务器并手动进行更改？哎呀。”

Answer 4

六个月前，在我们的非营利项目中，我们决定开始将系统管理迁移到 Puppet 控制的环境，因为我们预计从现在到一年后我们的服务器数量将大幅增长。

尽早开始听起来是个好主意 - Puppet 不仅仅是配置管理，它还是一种文档形式。

自从做出决定后，我们的 IT 人员就变得有点过于恼火了。

他们需要调整态度。

"We're not programmers, we're sysadmins";

再说态度。你 - 可以 - 为服务器制作一个 conf 文件，对吗？随着您的需求和复杂性的发展，您可以轻松进入模板/“程序员”的内容。

模块可在线获取，但许多模块彼此不同；轮子经常被重新发明，你如何决定哪一个合适；

很难回答 - 我总是更喜欢 puppetlabs 模块而不是大多数 - 即便如此，我也不会使用那么多。肯定是有判断力的。在我看来，有些模块“太花边了”。

我们的 repo 中的代码不够透明，要找到某些东西是如何工作的，他们必须通过清单和模块进行递归，他们甚至可能在不久前自己编写；

这听起来不像傀儡问题，更像是组织或文档问题？

一个新的守护进程需要编写一个新的模块，约定必须与其他模块相似，这是一个困难的过程；

如果该守护进程易于管理，它可以是一个类。我不确定你所说的约定是什么意思，puppet 对你强制执行约定很好，不是吗？或者我们是在讨论代码格式？

"Let's just run it and see how it works"

如果你缓慢而安全地考虑它，这并不是一个坏主意。我仍然会从 VM 开始来了解事情的要点。

社区模块中有大量鲜为人知的“扩展”：“trocla”、“augeas”、“hiera”……我们的系统管理员如何跟踪？

postfix、exim、sendmail、mysql、postgresql、iftop、iptraf、perl、perl 模块……选择你想要的并使用它？我想这听起来更像是一种态度……

我可以理解为什么大型组织会派遣系统管理员参加 Puppet 课程以成为 Puppet 大师。但是，如果小玩家不参加课程并且基本上通过浏览器和编辑器学习它，他们如何将 Puppet 学习到专业水平？

我没有参加过任何课程 - 虽然我是一名程序员而不是系统管理员，但我发现它不需要太多的编程技能来完成任何事情。

Puppet 文档在遵循时非常彻底。只需注意内置类型并花一些时间看看其他模块是如何组合在一起的。我不会说它 - 超级 - 容易，但它也不 - 难 - 。为 Puppet 准备基础设施需要一些时间，但是当您扩展时，可以确保投入的时间得到充分利用。

Answer 5

KISS（保持简单愚蠢）-不要仅仅因为新技术的存在而使用新技术，而是因为您对它们有需求，使用部署所需的最低限度，根据需要进行更新不要试图跟上流血的步伐边缘。如果你从一个基本的设置开始并以此为基础，那么你就可以更轻松地开始学习，而且他们不应该需要一门课程（这些课程甚至可用吗？）。

您可以查看的另一个区域是您的系统管理员。如果他们也不能编程，那么它们是否足够先进以进行大型部署，无论您使用什么工具，大部分工作都需要编写脚本？

Answer 6

我也为一家非盈利机构工作，最初负责将 Linux 机器带入内部，此后不久，Puppet 负责管理它们。我们已经完成了一些具体的事情，这些事情确实有助于推动事情的进展。

首先，我尽量远离第三方模块。内置工具处理我们 90% 的管理工作。我使用的最大的第三方实用程序是防火墙模块。任何自定义事实等都是在整个团队参与的情况下开发的。我们开发了一个模板模块，并将文件管理、包、服务等都标准化了这个模板。

其次，在使用内置模块进行标准化之后，我们开始使用 Git 和 Atlassian 的 Crucible（顺便说一下，非营利性免费）来对所有配置更改进行审查。这提供了所需的透明度。

第三，我自动化了 Puppet 的设置，以便可以使用一组默认选项自动添加新主机。有几种方法可以解决这个问题。因为我已经有一个完整的 Kickstart 环境，所以我选择在那里添加一个脚本。