六个月前,在我们的非营利项目中,我们决定开始将系统管理迁移到Puppet控制的环境,因为我们希望从现在到一年之间,我们的服务器数量将大幅增长。 br />
自从做出决定以来,我们的IT人员就变得过于烦恼。他们最大的反对意见是:“我们不是程序员,我们是sysadmins”;
模块可在线获得,但许多模块彼此不同。车轮经常被重新发明,您如何确定哪一个合适呢?
我们的仓库中的代码不够透明,无法找到需要如何通过清单和模块来递归的东西,他们甚至可能自己编写了清单前一阵子;
一个新的守护进程需要编写一个新模块,约定必须与其他模块相似,这是一个困难的过程;
“让我们运行它,看看它是如何工作的”。
社区模块中鲜为人知的“扩展”:“ trocla”,“ augeas”,“ hiera” ...我们的系统管理员如何保持跟踪?
我可以理解为什么大型组织为何将其系统管理员分派给人偶课程成为人偶大师。但是,如果较小的玩家不参加课程并基本上通过他们的浏览器和编辑器学习Puppet,他们将如何专业地学习Puppet?
#1 楼
在部署新的基础架构之前,我开始使用Puppet,只是买了一本(备受赞誉的)有关该主题的书。我认为大多数人实际上并没有接受过专业的木偶培训。我一直在研究示例,直到可以根据自己的环境调整流程。那是2011年12月,所以在几周内,我就能了解基本知识并建立生产框架。我对配置管理并不陌生,具有CFEngine背景,但是您的许多系统管理员的担忧引起了共鸣。我犯了错误,不得不多次重构,但是确实可以令人满意地工作。关于您的观点的几点说明...
传统系统管理角色正在变化。适应或被抛在后面。我曾经是一名成功的系统工程师,但也必须重新安装工具(例如,学习Python)。随着通过虚拟化的硬件抽象以及公共和私有云服务的普及,对单个服务器的关注已减少。这意味着系统任务的自动化和使用配置管理来夺取对更多服务器的控制权。将DevOps概念添加到组合中,您将看到客户/最终用户的期望和要求正在变化。
在线提供的人偶模块的样式和结构各不相同,是的,我看到了很多重叠,冗余和重复的现象。努力。与我合作的一位开发人员说:“您花在网上寻找可行的东西的时候就可以开发自己的工具!”这让我停下来,因为我意识到,Puppet似乎比寻求最佳实践或正确方法的管理员更吸引开发人员。
大量编写文档,以了解事物之间的联系。鉴于定义不明确且缺乏标准的处理方式,因此您的配置管理结构确实是您的环境所独有的。这种透明度必须在内部发展。
我认为复制一个模块以容纳新的守护程序或向现有清单添加服务相当容易,这取决于您如何组织服务器和角色。
我花了很多时间在一个单一目标,然后再将更改推送到更大的服务器组。在代表服务器上手工运行人偶可以让我调试更改并评估其影响。也许这有点保守,但这是必要的。
我不确定我对社区模块的依赖程度如何。我确实必须开始使用Augeas进行一些工作,并对这是我在CFEngine中理所当然的功能感到遗憾。
总而言之,我觉得Puppet尚无明确的标准。我在弄清楚如何在Puppetmaster上组织目录结构,了解如何管理证书签名,使适当的反向DNS随处可见,使Puppet能够针对环境进行适当扩展以及了解何时利用社区模块而非构建自己的模块时遇到了麻烦。这是思想上的转变,我知道这将使系统管理员感到恐慌。但是,这也是从头开始构建的解决方案,因此我拥有大量的评估工具。采取这种方式的决定是基于心态和Puppet背后的动力。值得努力学习新知识。
请记住,该站点也是很好的资源。
#2 楼
在上一份工作中,我被分配了进行Puppet试点实施的任务。现在,我拥有编程背景,尽管没有Ruby,所以我没有其他人那么多的问题。但是,有趣的是,没有Ponpet经验的程序员也对Puppet产生了疑问,因为Puppet是声明性的,而不是强制性的。从这个意义上讲,Puppet的工作原理几乎与任何配置文件一样:您说的应该是这样,Puppet负责其余的工作。
试点之后,我有机会与其他十几个管理员进行了培训。木偶,并在两个事件中进行介绍。我从这种经验中得出的结论是,有些管理员接受了,有些则没有。这些都是传统的管理员,没有编程技能,而且知识水平也不尽相同。
我注意到的一件事是Puppet需要不断练习。经过培训的人编写了模块,然后花了整整一个月或两个月的时间做其他事情,然后又以很少有用的技巧回到了Puppet。每周都会在其中做小事情的人永远不会失去这种能力。
基于这两个观察,我建议您确保每个人每周都在不断添加一些Puppet类,定义或模块(最好至少两次或三遍)。那些仍然不习惯它的人可能确实缺乏做到这一点的技能。
再说一次,如果将Puppet从高处强加于他们,他们可能只是在对自己的看法做出反应干预他们工作方式的管理人员-实际上,这已经足够了。让他们选择使用哪个配置管理系统可能会有所改善。以下是一些替代方法:
ANSIBLE:这是新功能,但是它基于shell命令和ssh,可能会吸引传统的系统管理员。
Chef:也许他们的问题是声明式风格,在这种情况下,如果他们具有Ruby经验,Chef会更好。
SaltStack:基于Python,并且是开源的
CFEngine:旧的,快速的,传统的-可能会因此而赢得他们的青睐。
评论
关于ANSIBLE的好处是,它可以在银河系之间工作,并且绝对不会延迟数据传输!
–卡拉马
2012年6月6日20:10
感谢您提到ANSIBLE。直到现在我才意识到。
–ewwhite
2012年6月7日下午0:58
@ewwhite不客气。我本人直到最近才发现它,但是有关它的许多内容引起了我的注意。如果我们在Puppet中还没有那么多,我一定会尝试一下。
–Daniel C. Sobral
2012年6月8日在3:50
#3 楼
我在唯一的系统管理员的小商店里使用Puppet已有两年多了。我遇到的最大障碍是学习如何正确开发软件。没有一个星期过去了,我没有搞错我告诉开发人员不要做很多次的事情。我签入了太多代码,没有中断签到,没有标记,没有分支,没有运行语法检查器,没有使用标准,等等。如果您只是开始我建议您采取以下措施。意识到您正在开发的软件可能不知道怎么做或做得不好。这是预料之中的,因为它是新的。
基础架构是代码的现实,一旦克服困难,它就非常强大。我会邀请一些开发人员过来,向他们展示您当前的开发过程(或缺少这些过程),当他们大惊小怪时不要冒犯,并且认真对待他们的建议。我建议您使用开发人员使用的任何系统和流程,除非完全不适当。
Puppet第三方模块会占用90%的时间。我读过我会从他们那里窃取想法。如果不进行重大修改,我不会将它们拉入我的系统。但是,我会加入伪造的stdlib,它添加了一些不错的功能。
augeas和hiera。学习那两个。第一个允许对现有文件进行复杂的编辑。第二个是外部数据存储。
将代码与数据分开。这是较难学习的概念之一。将“监视主机”之类的值硬编码到模块代码中是不好的。将它们放在模块可以使用的数据存储区(db,yaml(Hiera使用此默认值),csv等)中是很好的。一个示例是使用Mysql的Web应用程序。这允许的是分别推送代码和数据的能力。这使您的开发过程更加简单。
在您进行代码之前或之后的签入过程中,puppet解析器将进行验证并添加puppet-lint。一旦您掌握了速度,rspec测试也可能是一个好主意。
编写样式指南/代码标准并使用它。 “安装Apache的代码在哪里”是一个常见问题。如果您的模块基本相同,则应该很容易。
总之,我遇到了所有这些问题,所以我的大多数sysadmin朋友也都遇到了。使用配置管理系统需要一些时间才能变得精通。一旦您做完,您会想知道没有人的生活。 “登录到服务器并手动进行更改吗?I。”
评论
感谢您的建议,尤其是Augeas和hiera是我们已开始实施的两个组件,这使我们更加意识到,甚至对Puppet的功能充满信心。那谢谢啦 :-)
–drumfire
2012年7月18日在0:14
#4 楼
六个月前,在我们的非营利项目中,我们决定开始
,将系统管理迁移到Puppet控制的环境中
,因为我们希望服务器数量会大幅增长
从现在到一年之间。
听起来像是个好主意,早日开始-Puppet不仅是配置管理,它是一种文档形式。
自从做出决定以来,我们的IT人员变得有点过于生气了。
经常让他们感到烦恼。
他们需要调整态度。 。
"We're not programmers, we're sysadmins";
再次,态度。您可以为服务器创建conf文件吗?
随着您的需求和复杂性的发展,您可以轻松使用模板/“程序员”之类的东西。
模块可用在线,但许多彼此不同;车轮
经常被重新发明,您如何确定哪一个符合
法案;
很难回答-我总是更喜欢puppetlabs模块-即使那样,我也不用那么多。判决电话肯定。在我看来,有些模块“过于混乱”。
我们仓库中的代码不够透明,无法找到他们必须如何通过清单和模块来递归的东西。 />
这听起来不像是一个problem问题,但更多的是组织或文档问题?
一个新的守护程序需要编写一个新模块,约定必须与其他模块类似,这是一个困难的过程;
该守护程序可以很简单地进行管理。我不确定您所说的约定是什么,人偶很好地对您实施了约定,不是吗?还是我们是按照代码格式来谈论?
"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文档在阅读时非常详尽。 。只需注意内置类型,然后花一些时间研究其他模块的组装方式。我不会说这很简单,但也不是很难。使您的基础结构准备就绪时会花费一些时间,但是可以确保在扩展时花费了很多时间。
评论
仅供参考,这是来自刚刚完成基础架构准备就绪的人员。所以我有了新鲜的经验,不能说这是浪费时间。
–瘦身
2012年6月6日19:05
作为我的新手,我完全在您的评论中认出自己。
–马丁·海默斯(Martijn Heemels)
2012年7月30日14:21在
就我而言,确实有必要改变态度。 Ops喜欢自动化并且经常编写脚本,因此,这主要是使用不同的工具。看到您的Puppet清单从头开始配置整个计算机或新服务,这是一种很酷的感觉。错误会立即影响多台计算机这一事实要求习惯于进行更严格的测试,这可能很烦人,但显然是一件好事。试用Vagrant,rspec-puppet,puppet-lint,Geppetto,Git分支和其他免费工具,您很快就会发现自己喜欢的工作流程。
–马丁·海默斯(Martijn Heemels)
2012年7月30日14:34
与Puppet一起工作还帮助我学习了Ruby,它已取代Bash作为我的默认系统工具语言。
–马丁·海默斯(Martijn Heemels)
2012年7月30日14:36
#5 楼
吻(保持简单的愚蠢)-不要仅仅因为它们存在而使用新技术,而是因为您对它们有需求,请使用您的部署所需的最低限度的内容,根据需要进行更新,请不要试图跟上最新情况。边缘。如果您从基本设置开始并以此为基础,那么随身携带就更容易了,而且他们不需要课程(这些课程甚至还可以吗?)。您可以看一下其他区域at是您的系统管理员。如果他们也不能编程,那么它们是否足够先进以进行大型部署,而无论使用什么工具,大多数工作都需要编写脚本?
评论
...因为我们期望从现在到一年之间,我们的服务器数量将大幅增长。需求?
– Jeff Ferland
2012年6月6日14:02
真正取决于期望的确定性,以及到实际需求出现时您所采用的设置是否仍然合适。
–詹姆斯·瑞安(JamesRyan)
2012年6月6日在16:05
+1代表“使用部署所需要的最低限度” –由于试图使人偶控制系统上的所有内容,我遇到了很多人偶问题。
– Sirex
2012年7月16日在23:40
#6 楼
我也为非赢利性工作,并负责最初将Linux盒子带入内部,不久之后又由Puppet进行管理。我们已经完成了几项具体工作,这些工作确实有助于推动工作进展。首先,我一直试图远离第三方模块。内置工具可处理我们90%的管理。我使用的最大的第三方实用程序是防火墙模块。整个团队都将开发任何自定义事实等。我们开发了一个模板模块,并且使文件管理,软件包,服务等在此模板下均保持标准化。
其次,在标准化使用内置模块之后,我们开始使用Git和Atlassian的Crucible(顺便说一句免费),以对所有配置更改进行审查。这提供了所需的透明度。
第三,我自动化了Puppet的设置,以便可以使用默认选项集自动添加新主机。有几种解决方法。由于我已经拥有完整的Kickstart环境,因此我选择在此处添加脚本。
#7 楼
“我们不是程序员,我们是sysadmins”。
我的时代发生了变化,更糟的是:像我这样的灰胡子被认为比专业程序员,否则将永远无法通过系统管理员。
现在,我们有了“系统管理员”,他们基本上是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之类的数据库)或几乎任何地方都这样。无需超复杂的解决方案。我上面提到的库可以简单地从操作系统软件包中的preinstall或postinstall部分获取,从而消除重复并利用中央代码段... 但是最重要的是,我发现以上引述是下一代系统管理员需要由系统管理员而不是系统工程师进行辅导的示例。找到自己的白胡子,然后作为学徒登录。
评论
您似乎忘记了作者问题的答案。
– M. Glatki
16 Dec 28'在11:33
这个答案似乎主要是关于观点,态度和工具的讨论,并没有真正解决所提出的问题。
–乔纳森·戴维·阿恩特(JonathanDavidArndt)
17年7月17日在15:16
评论
我从没有使用Puppet的经验变成了在两周内对整个环境进行管理。我负责约40个虚拟机,尽管它们都运行Ubuntu。这简化了很多事情。我是专业的开发人员。 “适应还是被抛在后面”-我现在是devops + sysadmin +架构师。很好的答案!
–FrançoisBeausoleil
2012年6月6日13:58
我建议他们开始部署小型服务,首先是独立部署,然后再修补更多服务器。我不必使用Puppet,但是我有一个小型VPS,最近我制作了自己的Puppet模块。如果他们想跟上本世纪的其他系统管理员的步伐,那么他们最好保持胸襟开阔。我这样做是因为我喜欢,而且我想并不是每个人都喜欢学习新事物,但是可以肯定的是,如今系统管理员比以往任何时候都更接近开发人员。
–塞尔吉奥·加尔文(Sergio Galvan)
2012年6月7日19:22
我在一家小公司工作,在推送到所有服务器之前,我还运行了puppetd -t在几个盒子上进行测试。一对夫妇拥有独特的东西而导致我的更新失败,这绝不会失败。如果您一开始就拥有一个受控且一致的环境,那么Puppet会容易得多。
–jordanm
2012年8月25日下午5:33
@ewwhite,我已经在他们的文档中完成了Puppet教程的学习,但是想知道您学习时使用的是哪本书?我有点像文档中提供的教程丢失了某些东西,这使我无法在我与测试主机上的Puppet一起学习我在做什么的同时单击所有内容。编辑:或任何其他资源,您可以推荐。谢谢。
–迈克·凯勒(Mike Keller)
2012年11月9日在2:32
@MikeKeller我在我的帖子中喜欢它...但是可以在这里找到。
–ewwhite
2012年11月9日在2:41