六个月前,在我们的非盈利项目中,我们决定开始将我们的系统pipe理迁移到Puppet控制的环境中,因为我们期望从现在到一年之间,我们的服务器数量会大幅增长。
自从做出这个决定后,我们的IT人员变得有点太烦人了。 他们最大的反对意见是:
我可以看到为什么一个大型组织将派遣他们的系统pipe理员到木偶课程成为木偶大师。 但是,如果小型玩家不上课程,基本上通过浏览器和编辑学习,那么小型玩家如何才能将木偶学到专业水平呢?
在开始部署新的基础架构之前,我开始使用Puppet,并简单地购买了一本关于这个主题的书。 我不认为大多数人实际上获得了专业的木偶培训。 我一直在做例子,直到我可以将过程塑造到我的环境中。 这是2011年12月,所以在几个星期之内,我能够理解基础知识并获得一个生产框架。 我对configurationpipe理并不陌生 ,拥有CFEngine背景,但是许多系统pipe理员的担忧引起了共鸣。 我犯了错误,不得不多次重构,但是我确实做了令人满意的工作。
关于你的观点的几点笔记
传统的系统pipe理angular色正在发生变化。 适应或被抛在后面。 我一直是一个成功的系统工程师,但也必须重新组装(例如学习Python)。 随着虚拟化和公私云服务的硬件抽象化,个人服务器的关注度逐渐降低。 这意味着系统任务的自动化和使用configurationpipe理来夺取大量服务器的控制权。 将DevOps概念添加到组合中,您将看到客户/最终用户的期望和要求正在发生变化。
在线上的木偶模块在风格和结构上各不相同,是的,我看到了很多重叠,冗余和重复的努力。 一位与我一起工作的开发人员说:“当你在网上寻找有用的东西的时候,你可以开发自己的工具! 这让我停下来,因为我意识到Puppet似乎更喜欢开发者types,而不是pipe理员寻找最佳实践或正确的方法。
大量文档以便了解事物是如何连接的。 鉴于不稳定的定义和缺乏标准的做事方式,您的configurationpipe理结构对您的环境来说确实是独一无二的。 透明度将在内部得到发展。
我认为,复制模块以容纳新的守护进程或向现有的清单添加服务是相当容易的,具体取决于您如何组织服务器和angular色。
在将更改推送到更大的服务器组之前,我花了很多时间在单个目标上进行testing。 在有代表性的服务器上手动运行puppetd允许我debugging更改并评估其影响。 也许这有点保守,但这是必要的。
我不知道我有多less依赖社区模块。 我不得不开始使用Augeas进行一些工作 ,并感叹这是我在CFEngine中认为理所当然的一个function。
总的来说,我觉得Puppet没有一个明确的标准。 我无法弄清楚如何在我的Puppetmaster上组织目录结构,了解如何pipe理证书签名,在任何地方获得正确的反向DNS , 让Puppet适当地适应环境,了解何时利用社区模块与构build自己的模块。 这是思维上的转变,我看到这会使系统pipe理员恐慌。 然而,这也是从头开始的解决scheme,所以我有评估工具的奢侈。 这样做的决定是基于思想上和Puppet背后的势头。 学习新东西是值得的。
记住, 这个网站也是一个很好的资源。
在之前的工作中,我被分配到了试点实施木偶的任务。 现在,我有编程背景,虽然不是Ruby,所以我没有像其他人那么多的问题。
然而,有意思的是,没有非传统范式经验的程序员也有Puppet的问题,因为Puppet是声明式的 ,并不是必须的。 从这个意义上说,Puppet的工作方式与任何configuration文件非常相似:你说事情应该如何,Puppet负责剩下的事情。
在飞行员之后,我有机会训练一些其他pipe理员与木偶,再加上在两个事件介绍。 我从中得到的经验是,一些pipe理员接受了,有些则没有。 这些都是传统的pipe理员,没有编程技能和不同的专业水平。
我注意到的一件事是木偶需要不断的练习。 受过培训的人写了一些模块,然后花了整整一两个月的时间做了一些别的事情,然后用一些有用的技巧回到了Puppet。 那些每周都在做小事情的人永远不会失去这种能力。
基于这两个观察,我build议你确保每个人每周都不断地添加一些Puppet类,定义或模块(最好至less有两三次)。 那些仍然不习惯的人可能真的缺乏这个技能。
再次,如果木偶从上层强加给他们,他们可能只是对他们认为是pipe理层干预他们工作的侵略行为做出了反应 – 实际上这是事实。 让他们select使用哪种configurationpipe理系统可能会改善事情。 这里有一些select:
我已经使用了两年多的木偶在我只有系统pipe理员的小商店。 我遇到的最大障碍是学习如何正确开发软件。 没有一个星期,我没有把我曾经告诉开发人员不要做十几次的东西搞砸了。 我检查了太多的代码,我没有打破检查,我没有标记,我没有分支,没有运行的语法检查,没有使用标准等,如果你刚刚开始我build议下面的一些。
总之,我已经遇到了所有这些问题,所以我的大多数系统pipe理员朋友。 使用configurationpipe理系统需要一些时间。 一旦你这样做,你会想知道你如何没有一个人生活。 “login到服务器并手动进行更改?Ick”。
六个月前,在我们的非盈利项目中,我们决定开始将我们的系统pipe理迁移到Puppet控制的环境中,因为我们期望从现在到一年之间,我们的服务器数量会大幅增长。
听起来像是一个好主意,尽早开始 – Puppet不仅仅是configurationpipe理,它是一种文档forms。
自从做出这个决定以来,我们的IT人员已经变得有点过于恼火了。
他们需要一个态度调整。
"We're not programmers, we're sysadmins";
再次,态度。 你可以创build一个服务器的conf文件吗? 随着您的需求和复杂性的发展,您可以轻松进入模板/程序员的内容。
模块可以在线获得,但是许多模块有所不同; 车轮经常被重新发明,你如何决定哪一个适合这个法案?
很难回答 – 我总是比较喜欢puppetlabs模块 – 即使如此,我也不会那么多。 肯定的判断电话。 在我看来,一些模块是“太褶边”了。
在我们的回购中的代码是不够透明的,要找出他们必须通过他们可能甚至写了自己前面的清单和模块recursion的东西是如何工作的;
这听起来不像一个傀儡问题,但更像一个组织或文件问题?
一个新的守护进程需要编写一个新的模块,惯例必须与其他模块相似,这是一个困难的过程;
守护进程可以是一个类,如果它足够简单的pipe理。 我不确定你的意思是什么,傀儡对你实行惯例不是吗? 或者我们正在讨论代码格式化的问题?
"Let's just run it and see how it works"
如果你把它放慢又安全,那不是一个好主意。 我仍然从虚拟机开始,以获得东西的要点。
在社区模块中几乎没有“扩展名”:“trocla”,“augeas”,“hiera”…我们的系统pipe理员如何跟踪?
postfix,exim,sendmail,mysql,postgresql,iftop,iptraf,perl,perl模块..select你想要的并使用它? 我想这听起来更像一个态度的事情…
我可以看到为什么一个大型组织将派遣他们的系统pipe理员到木偶课程成为木偶大师。 但是,如果小型玩家不上课程,基本上通过浏览器和编辑学习,那么小型玩家如何才能将木偶学到专业水平呢?
我没有参加任何课程 – 虽然我是一个程序员而不是系统pipe理员,但是我发现不需要太多的编程技能就可以完成任何事情。
随后的木偶文档是相当彻底的。 只要注意内置的types,花一些时间看看其他模块如何放在一起。 我不会说这很容易,但也不是很难。 把你的基础设施准备好给傀儡是有点费时的,但是当你扩展的时候,投入的时间是可以确定的。
我也从事非盈利工作,并负责最初将Linux机箱内置于内部,不久之后Puppet负责pipe理它们。 我们已经做了一些具体的事情,这些事情确实有助于事情的发展。
首先,我试图远离第三方模块。 内置的工具可以处理我们90%的pipe理。 我使用的最大的第三方实用程序是防火墙模块。 任何自定义的事实等都是在整个团队参与下发展起来的。 我们开发了一个模板模块,并将文件pipe理,包装,服务等全部标准化。
其次,在使用内置模块进行标准化之后,我们开始使用Git和Atlassian的坩埚 – 顺便说一句 – 免费用于非盈利 – 对所有configuration变更进行审查。 这提供了所需的透明度。
第三,我自动化了Puppet的设置,这样新的主机可以自动添加一组默认的选项。 解决这个问题有几种方法。 由于我已经有一个完整的Kickstart环境,我select在那里添加一个脚本。
KISS(保持简单愚蠢) – 不要仅仅因为他们在那里而使用新技术,而是因为你有他们的需求,使用你的部署需要的最低限度,根据需要更新不要跟上出血边缘。 如果你从一个基本的设置开始,build立在它上面,它更容易拾取,他们不应该需要一个课程(这些甚至可用?)。
你可以看看的其他领域是你的系统pipe理员。 如果他们不能编程,那么他们是否足够先进的大型部署,大部分的工作需要使用任何工具脚本?
“我们不是程序员,我们是系统pipe理员”
我的时代已经发生了变化,更糟糕的是,像我这样的灰胡子被认为是比专业程序员更好的程序员,否则将永远无法通过系统pipe理员 。
现在,我们有了“系统pipe理员”,他们基本上是Windows桌面用户,他们已经转换到Linux,无法编程,也没有发现任何问题。
房间里的大象是pipe理层为什么容忍这种破坏性的态度。 破坏谁或什么? 对企业和基础设施。
回到Puppet [,CFEngine,主厨]主题:只要有一个解决scheme,就会失败。 每个人都失去了。 为什么? 因为无论是谁提出这个想法,都不能以好,干净的Kickstart [,JumpStart,Automated Installer,AutoYaST,Ignite-UX,NIM]操作系统包的forms来devise封装的configurationpipe理。 当你不得不使用像木偶(或厨师,或CFEngine)自动黑客工具,这意味着你缺乏devise和实施一个过程,将通过同样的devise,完全执行完全原始和熄灭pipe理系统自动的,完全不交互的。
另一个重要的一点是,如果你必须有Puppet或者其他的解决scheme来纠正某些人手动攻击系统或者应用程序configuration的情况,那么这又回到没有devise进程的经验,并且在这个过程中,一个configuration被打包的框架分立元件。 实际上,谁来实现Puppet之类的,没有组件所有者,发行版,configurationpipe理,能力成熟度模型的概念。 这正在迅速发展成为行业中一个非常严重的问题。
与Puppet合作也帮助我学习了Ruby,它已经取代了Bash作为我的默认系统工具语言。“
为什么需要Ruby,只需使用Bourne shell程序,AWK和sed,就可以在预安装,后安装,preremove和postremove操作系统软件包的各个部分中封装全面的端到端configurationpipe理? 有人会学习Ruby的深奥语言,在木偶的背景下学习一种方言,是完全没有必要的。 configurationpipe理的问题很容易通过shell程序和AWK解决(而且已经解决了),并且在这里和那里粘贴一些sed(1)。
看到你的Puppet清单从头开始configuration整个机器或新的服务是一种很酷的感觉。
使用Kickstart,AutoYaST或JumpStart, 无需任何代码即可完成更酷的事情,并且可以使用内置工具查询操作系统,而不需要任何深奥的或额外的软件 , 也不需要客户端 – 服务器所需的架构 (SSH远不止罚款,而不仅仅是罚款),并看到你的操作系统意识到每一个变化。
5.从数据分离代码。 这是学习困难的概念之一。 硬编码值像监视主机到你的模块代码是不好的。 把它们放在一个数据存储(db,yaml(Hiera使用这个是默认的),csv,不pipe),你的模块可以使用的是好的。 一个例子是使用Mysql的webapp。 这允许的是分别推送代码和数据的能力。 这使得您的开发过程更简单。
…或者你也可以用你的configuration文件来模拟shellvariables,甚至是反引号(例如ls -1 ...
),然后编写一个使用AWK调用eval(1)的shell脚本,并展开模板中的所有variables,从而利用shell内置的完全相同的强大的分析器。 为什么把它变得复杂,什么时候真的很简单? 你将在哪里存储configuration值? 为什么在任何你喜欢的地方,比如pkginfo(4)文件,或者像Oracle这样的数据库,或者任何地方 。 不需要超复杂的解决scheme。 我上面提到的库可以简单地从操作系统包中的预安装或安装后部分获取,从而消除重复并利用中心代码片段。
但最重要的是,我发现上面的引用是下一代系统pipe理员需要辅导的一个例子,而不是系统pipe理员,而是系统工程师 。 找一个灰胡子,并以学徒身份login。