为什么在外壳程序脚本上使用Chef / Puppet?


81

Puppet和Chef工具的新功能。好像他们正在做的工作可以使用Shell脚本来完成。也许这是在shell脚本中完成的,直到这些脚本出现为止。

我同意它们更具可读性。但是,除了可读性之外,shell脚本还有其他优点吗?

Answers:


56

特定领域的语言在您编写的代码量上有很大的不同。例如,您可能会争辩说:

chmod 640 /my/file

file { "/my/file":
    mode => 640,
}

但是这些之间有很多区别:

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

如果wget失败怎么办?您的脚本将如何处理?如果脚本中的某些内容之后要求$ FILE包含正确的内容,那该怎么办?

您可能会争辩说,可以将echo "Hello world" > $FILE脚本放入脚本中,只是在第一个示例中,脚本必须在客户端上运行,而puppet在服务器上编译所有这些脚本。因此,如果您更改内容,则只需在服务器上进行更改,它就可以在要放入的任意数量的系统上进行更改。而puppet会自动处理依赖关系并为您转移问题。

没有可比性-正确的配置管理工具可以节省您的时间和复杂性。您尝试做的越多,似乎更多的shell脚本不足,并且通过使用puppet进行操作将节省更多的精力。


9
@Paul Gear,说配置管理工具是长远的路要走,这太简单了。例如,使用AWS,shell脚本可以从头开始构建服务器,运行一些测试,一旦确定AWS实例正常,就创建一个映像。然后,您可以将该图像部署到预览或暂存环境中以进行进一步的测试,一旦确认该图像适合您的目的,然后就可以进行生产了。在这种情况下,配置管理工具完全没有帮助。
德里克·里兹

现在,如果您要管理人们每天使用的100台专用服务器(无论您是否错误地控制它们的工作,您几乎都无法控制),那就应该使用配置管理工具。
Derek Litz 2013年

6
这不是一个非常令人信服的例子。我可以从wget开始,然后我不会陷入怪异的状态。文件是否像事务,如果任何步骤不成功,都会回滚?
PSkocik

33

这将是不受欢迎的观点,但是配置管理系统不一定更好。有时候简单确实是最好的。

您选择的配置系统有明确的学习曲线和管理开销。毕竟,您将引入依赖关系。与任何自动化一样,您还必须注意在已部署的配置中维护安全性。

我只有几个实例,我们在其中部署了配置管理,但一直没有成功。总是有大量具有重复配置的系统,并且需要执行可配置的cookie切割器部署。


10
如果管理环境的成本如此之高,以至于自动化管理的确便宜。如果编写Git中管理的更改脚本或在ssh多路复用器中设置脚本更简单,那么我们可以这样做。对我来说最重要的是,我监视系统并验证所有功能均按预期运行。只要在配置错误时收到警报,配置它就不是那么重要。
kenchilada

10
@ewwhite“您何时决定自动化与否?” xkcd.com/1205
MikeyB

3
比Chef或Puppet等更现代的工具(例如Ansible)具有更少的部署/管理开销,几乎不需要依赖(特别是Ansible是无代理的)。这确实降低了采用的门槛。
GomoX

2
@ewwhite当您想要提高个人生产率时,您可以实现自动化。您通过自动化学习,而不是通过执行普通任务学习。学习=生产率提高和迭代改进。自动化与此结合产生更多的积极影响。这是一个积极的雪球,而不是消极的雪球。技术进步与技术债务。
Derek Litz 2013年

2
@ABB不,这不是暗示。我什至没有提到shell脚本,我只是提到自动化。您可以使用Shell脚本使事情自动化并学习脚本抽象,而不是手动做事,这不仅可以节省您再次执行该任务的时间,而且还可以防止出错。同样,您应该能够比上一个脚本编写更好的下一个脚本。积极的雪球...但是,如果您是脚本编写专家,并且没有编写脚本,那么您将永远无法再次运行它,它不会以任何方式帮助您学习或节省时间。
德里克·利兹

23

您已经回答了自己的问题...

自动化正在变得更加可扩展和正规化。如今,木偶和厨师被视为标准(请查看招聘广告)。

拼凑在一起的shell脚本占有一席之地,但是在DevOps运动的背景下它们是不可扩展的。可读性是其中的一部分。


7
Shell脚本是否以某种方式不那么形式化?引用招聘广告是否能引起争论?devops很遗憾,因为他/他作为开发人员尚未得到充分利用。该链接并未真正说明可扩展性。是否声称Shell脚本不可扩展?我认为Puppet很有趣,但不一定出于答案的原因。
Acumenus 2014年

招聘广告反映了特定技能的实际市场。是的,将配置管理用于其预期目的比外壳程序脚本更具可扩展性,更强大且更易于记录。我去过很多环境,而且我看到的大多数脚本的构建方式都不像人们认为的“生产质量”,而是组织起来处理异常。请参阅已接受的答案以了解原因。
ewwhite

1
“开发人员实在是太可惜了,因为他/他作为开发人员尚未得到充分利用。” 这根本不是真的。就像Web开发一样,DevOps是开发专长。软件开发的模式和实践仍然适用。您应该阅读有关DevOps的信息。
Chaim Eliyah's

13

Chef使得管理和版本化复杂基础架构的设置变得更加容易,尤其是在任何类型的云环境中,与必须手动通过ftp或scp以非标准化方式组织的一堆shell脚本相比,Chef变得更加容易。取决于您需要管理的依赖项数量,获胜的规模可能会大不相同,这使得迁移到CM解决方案的决定对于很多人来说并不是一个显而易见的选择。

Chef的真正(常常是无名指)好处是幂等。不管是否有重复的利益而运行的配方的组合,都能够确定资源的状态,这是对Shell脚本配置的巨大好处。如果您现在有用于配置的Shell脚本,请问自己可以在没有意外/不希望的后果的情况下多次运行它们吗?

适当的CM解决方案通过简化跨平台自动化和团队协作,有助于确保大规模成功。尽管可以通过组织良好,维护得当的Shell脚本版本组来完成所有这些工作;您必须问自己“为什么”。Chef / Puppet和类似技术的出现是因为一群才华横溢的SysOps厌倦了不得不一遍又一遍地解决这些相同的问题,并着手为我们提供更好的选择。

关键件:

  • 幂等
  • 轻松的依赖性管理(版本控制)
  • 标准化组织(在行业级别接受)
  • 将服务器配置任务与系统级别详细信息分开的抽象
  • 利用社区知识的能力(保证包含所有上述原则)

3
ss几乎不可能实现幂等。依赖关系可以通过yum / apt等很好地管理。接受是无关紧要的。社区知识存在于SS。但是,我接受不必复制一堆脚本,也不必集中配置系统都是有用的。我听说木偶需要客户端代理。
Acumenus

10

诸如Puppet和Chef之类的现代配置管理工具使您可以定义系统的状态,而不必担心实现已配置服务器所需的活动

例如,您的chmod命令假定文件存在,拥有该文件的用户存在,目录已经创建,依此类推。因此,您的脚本必须考虑所有这些先决条件。

基于状态的配置管理工具更简单:您只需要关心文件具有正确的权限即可。该工具的问题是如何实现的。


1
实际上,我chmod不认为该文件存在是因为该文件是由脚本创建的,或者由脚本测试其是否存在。
Acumenus 2014年

9

如果服务器对您来说是一次性的,或者您一次只能站起来几个,那么成熟的CM系统将比一系列Shell脚本更好地满足您的需求。

如果您的构建需求适中(或喜欢手工制作有机自由散布的公平交易服务器),则保持简单。

就个人而言,在过去的演出中广泛使用Chef的情况下,我试图在此演出中“保持简单”,但我确实错过了Chef提供的原始,抽象和功能。即使遇到可以从几个shell命令中获得所需内容的情况,也可以简单地使用“ command”块运行那些命令,并完全按照在shell中编写它们的方式输入shell命令。

话虽如此,您可以在不使用服务器(chef-solo)的情况下运行Chef,并且我很确定Puppet具有类似的功能,您可以在其中运行其他人的食谱和食谱而无需运行中央服务器。

社区的另一个好处是:有很多人(其中许多人比您更聪明和/或更有经验)。就个人而言,当别人为我完成我的工作时,我会喜欢上它,通常情况下,我会比我做得更广泛。


1

我创建了一个基于shell脚本的服务器自动化框架:https : //github.com/myplaceonline/posixcube

我确定我不是第一个进行此类项目的人,但是找不到适合我需求的类似项目,因此我认为其他人可能会觉得这很有用。我只接触过Chef,但是当我开始环顾Ansible和其他应用程序时,我想尝试一下shell脚本,到目前为止,我仍然很喜欢结果。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.