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

81

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

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

— 休息的
source

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进行操作将节省更多的精力。

— 保罗·吉尔
source

9

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

— 德里克·里兹

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

— Derek Litz 2013年

6

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

— PSkocik

33

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

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

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

— 凯奇拉达
source

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运动的背景下它们是不可扩展的。可读性是其中的一部分。

— 怀特
source

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厌倦了不得不一遍又一遍地解决这些相同的问题，并着手为我们提供更好的选择。

关键件：

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

— 马特·苏拉比安
source

3

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

— Acumenus

10

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

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

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

— 乔恩·贾罗克（Jon Jaroker）
source

1

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

— Acumenus 2014年

9

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

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

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

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

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

— 沃尔多
source

1

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

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

— 凯文
source