六个月前，在我们的非营利项目中，我们决定开始将系统管理迁移到Puppet控制的环境，因为我们希望从现在到一年之间，我们的服务器数量将大幅增长。
自从做出决定以来，我们的IT人员变得太烦恼了。他们最大的反对意见是：
我明白了为什么大型组织会派系统管理员到Puppet课程来成为Puppet大师。但是，如果较小的玩家不参加课程并且基本上通过浏览器和编辑器学习Puppet，他们将如何获得专业水平的学习？
Answers:
在部署新的基础架构之前，我开始使用Puppet，只是买了一本（备受赞誉的）有关该主题的书。我认为大多数人实际上并没有接受过专业的木偶培训。我一直在研究示例，直到可以根据自己的环境调整流程。那是2011年12月，所以在几周内，我就能了解基本知识并建立生产框架。我对配置管理并不陌生，具有CFEngine背景，但是您的许多系统管理员的担忧引起了共鸣。我犯了错误，不得不多次重构，但是我的确能令人满意地工作。
关于您的观点的几点说明...
传统的系统管理角色正在发生变化。适应或被抛在后面。我曾经是一名成功的系统工程师，但也必须重新安装工具（例如，学习Python）。随着通过虚拟化的硬件抽象以及公共和私有云服务的普及，对单个服务器的关注已减少。这意味着系统任务的自动化和配置管理的使用，以控制更多服务器。将DevOps概念添加到组合中，您将看到客户/最终用户的期望和要求正在变化。
在线提供的人偶模块的样式和结构各不相同，是的，我看到了很多重叠，冗余和重复的工作。与我合作的一位开发人员说：“您花在网上寻找可行的东西的时候就可以开发自己的工具！” 这让我停下来，因为我意识到Puppet似乎比寻求最佳实践或正确方法的管理员更吸引开发人员。
大量记录文档，以了解事物之间的联系。鉴于定义不明确且缺乏标准的处理方式，因此配置管理结构确实是您的环境所独有的。这种透明度必须在内部发展。
我认为复制一个模块以容纳新的守护程序或向现有清单添加服务相当容易，这取决于您如何组织服务器和角色。
在将更改推送到更大的服务器组之前，我花了很多时间在单个目标上进行测试。在代表服务器上手动运行人偶可以让我调试更改并评估其影响。也许这有点保守，但这是必要的。
我不确定我对社区模块的依赖程度。我确实必须开始使用Augeas进行某些工作，并为它是我在CFEngine中理所当然的功能而感到遗憾。
总体而言，我觉得Puppet尚无明确的标准。我在弄清楚如何在Puppetmaster上组织目录结构，了解如何管理证书签名，使适当的反向DNS随处可用，使Puppet能够针对环境进行适当扩展以及了解何时利用社区模块而非构建自己的模块时遇到了麻烦。这是思想上的转变，我知道这将使系统管理员感到恐慌。但是，这也是从头开始构建的解决方案，因此我拥有大量的评估工具。采取这种方式的决定是基于心态和Puppet背后的动力。努力学习新知识是值得的。
请记住，该站点也是很好的资源。
puppetd -t在推向所有服务器之前，我还在几个盒子上进行测试。一对夫妇拥有独特的东西而导致我的更新失败，这绝不会失败。如果您一开始就拥有一个受控且一致的环境，那么Puppet会容易得多。
在上一份工作中，我被分配了执行Puppet的试验实施的任务。现在，我拥有编程背景，尽管没有Ruby，所以我没有其他人那么多的问题。
但是，有趣的是，没有使用非传统范例经验的程序员也会遇到Puppet的问题，因为Puppet是声明性的，而不是强制性的。从这个意义上讲，Puppet的工作原理几乎与任何配置文件一样：您说的应该是这样，Puppet负责其余的工作。
试点之后，我有机会与Puppet一起培训了十几位其他管理员，并在两次活动中进行了介绍。我从这种经验中得出的结论是，有些管理员接受了，有些则没有。这些都是传统的管理员，没有编程技能，而且专业水平也不尽相同。
我注意到的一件事是木偶需要不断练习。经过培训的人编写了模块，然后花了整整一个月或两个月的时间做其他事情，然后又以很少有用的技巧回到了Puppet。每周坚持做小事的人永远不会失去这种能力。
基于这两个观察，我建议您确保每个人每周都保持添加一些Puppet类，定义或模块（最好至少添加2或3次）。那些仍然不习惯它的人可能确实缺乏做到这一点的技能。
再说一次，如果将Puppet从上层强加给他们，他们可能只是对他们认为是管理层的事情做出反应，干扰了他们的工作方式-实际上，这是足够的。这可能是让他们选择的情况下，其使用配置管理系统将改善的事情。以下是一些替代方案：
我在唯一的系统管理员的小型商店里使用Puppet已有两年多了。我遇到的最大障碍是学习如何正确开发软件。没有一个星期过去了，我没有搞乱我告诉开发人员不要做很多次的事情。我签入了太多代码，没有中断签到，没有标记，没有分支，没有运行语法检查器，没有使用标准，等等。如果您只是开始我会建议以下一些。
总之，我遇到了所有这些问题，所以我的大多数sysadmin朋友也遇到了。使用配置管理系统需要一些时间才能变得精通。一旦做完，您会想知道没有人过的生活。“登录到服务器并手动进行更改？
六个月前，在我们的非营利项目中，我们决定开始将系统管理迁移到Puppet控制的环境，因为我们希望从现在到一年之间，我们的服务器数量将大幅增长。
听起来像是一个很早就开始的好主意-Puppet不仅仅是配置管理，而是一种文档形式。
自从做出决定以来，我们的IT人员变得太烦恼了。
他们需要调整态度。
"We're not programmers, we're sysadmins";
再次，态度。您可以为服务器创建conf文件吗？随着需求和复杂性的发展，您可以轻松研究模板/“程序员”一词。
模块可在线获得，但许多模块彼此不同。车轮经常被重新发明，您如何确定哪一个合适？
很难回答-我总是比大多数人更喜欢puppetlabs模块-即使那样，我也不用那么多。判决电话肯定。在我看来，有些模块“过于混乱”。
我们仓库中的代码还不够透明，无法找到他们必须如何通过清单和模块来递归某些东西，而清单和模块甚至可能是他们前一段时间编写的。
这听起来不像是人偶问题，但更像是组织或文档问题？
一个新的守护程序需要编写一个新模块，约定必须与其他模块相似，这是一个困难的过程。
如果该守护程序足够简单，可以进行管理。我不确定您所说的约定是什么，人偶会很好地对您执行约定，不是吗？还是我们按照代码格式进行交谈？
"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文档非常详尽。只需注意内置类型，然后花一些时间研究其他模块的组装方式。我不会说这很简单，但也不是很难。使您的基础结构准备就绪时会花费一些时间，但是可以确保在扩展时花费了很多时间。
吻（保持简单愚蠢）-不要仅仅因为它们存在而使用新技术，而是因为您对它们有需求，请使用您的部署所需的最低限度的信息，根据需要进行更新，请不要试图跟上最新的潮流。边缘。如果您从基本设置开始并以此为基础，那么随身携带就更容易了，而且他们不需要课程（这些课程甚至可用吗？）。
您可以查看的其他区域是您的系统管理员。如果他们也不能编程，那么它们是否足够先进以进行大型部署，无论您使用什么工具，大多数工作都需要编写脚本？
我也为非营利性工作，并负责最初将Linux盒子带入内部，不久之后又由Puppet进行管理。我们已经完成了几项具体工作，这些工作确实帮助推动了工作的进行。
首先也是最重要的是，我试图远离第三方模块。内置工具可处理我们90％的管理。我使用的最大的第三方实用程序是防火墙模块。任何自定义事实等都是在整个团队参与下开发的。我们开发了一个模板模块，并且使文件管理，软件包，服务等在此模板之外均保持标准化。
其次，在标准化使用内置模块之后，我们开始使用Git和Atlassian的Crucible（顺便说一句，对非赢利免费的）对所有配置更改进行审查。这提供了所需的透明度。
第三，我自动化了Puppet的设置，以便可以使用一组默认选项自动添加新主机。有几种解决方法。由于我已经拥有完整的Kickstart环境，因此我选择在此处添加脚本。
“我们不是程序员，我们是系统管理员”
我怎么时代变了，变得更糟：像我这样的樽被预计会比专业程序员更好的程序员，要不然也从来没有能够通过一个系统管理员。
现在，我们有了“系统管理员”，他们基本上是Windows桌面用户，他们在某些时候已经转换为Linux，并且无法编程，也没有发现任何错误。
房间里的大象是管理层宽容这种破坏性态度的原因。对谁或什么具有破坏性？对于企业和基础设施。
回到Puppet [，CFEngine，Chef]主题：一旦提出了这样的解决方案，就会输掉。每个人都输了。为什么？因为无论是谁提出的，都无法以美观，干净，Kickstart [，JumpStart，自动安装程序，AutoYaST，Ignite-UX，NIM]操作系统软件包的形式设计封装的配置管理。当您必须使用自动黑客工具（例如Puppet（或Chef或CFEngine））时，这意味着您缺乏设计和实施过程的资金，而该过程将通过相同的设计完全执行原始操作，并完全淡化托管系统。自动化且完全非交互。
另一个重要的一点是，如果您必须拥有Puppet或某些此类解决方案来手动纠正某人的黑客系统或应用程序配置，那又可以追溯到没有设计流程的经验，并且在该流程中没有打包配置的框架分成离散的组件。实际上，无论谁实现Puppet等，都没有组件所有者，发布，配置管理，能力成熟度模型的概念。这正在迅速发展成为行业中非常严重的问题。
与Puppet一起工作还帮助我学习了Ruby，它已取代Bash成为我的默认系统工具语言。”
仅通过使用Bourne Shell程序，AWK和sed，就可以在操作系统软件包的安装前，安装后，移除前和移除后部分中封装全面的端到端配置管理，为什么需要Ruby？完全没有必要花一些时间去学习Ruby的一种深奥的语言，以及在Puppet上下文中的一种方言。使用shell程序和AWK以及在这里和那里一点点sed（1）作为胶水，很容易解决（而且已经解决了）配置管理的问题。
看到您的Puppet清单从头开始配置整个计算机或新服务，这是一种很酷的感觉。
看到它是由Kickstart，AutoYaST或JumpStart完成的，甚至没有一件简单的代码，并且能够使用内置工具来查询操作系统，而无需任何深奥或额外的软件，也不需要客户端服务器，这是一件更酷的事情。所需的体系结构（SSH远远超过了罚款，远远超过了罚款），并且看到您的操作系统知道对其进行的每一个更改。
5.将代码与数据分开。这是较难学习的概念之一。将“监视主机”之类的值硬编码到模块代码中是不好的。将它们放在模块可以使用的数据存储区（db，yaml（Hiera使用此默认值），csv等）中是很好的。一个示例是使用Mysql的Web应用程序。这允许的是分别推送代码和数据的能力。这使您的开发过程更加简单。
...或者您可以仅使用shell变量，甚至用反引号（例如）将您的配置文件模板化，ls -1 ...并编写一个使用AWK调用eval（1）并扩展模板中所有变量的shell脚本，从而充分利用相同的强大功能解析器内置了哪些shell。当它真的可以真的很简单时，为什么还要使其复杂？您将在哪里存储配置值？为什么在您喜欢的任何地方（例如pkginfo（4）文件，Oracle之类的数据库）或几乎任何地方都可以。无需超复杂的解决方案。我上面提到的文库可以简单地来源于从安装前或安装后的部分中的操作系统软件包，从而去除重复和利用一个中央一段代码...
但是最重要的是，我发现以上引用是下一代系统管理员的一个示例，该系统管理员不需要系统管理员，而是需要系统工程师进行辅导。找到一个白胡子，然后作为学徒登录。