题 为什么使用Chef / Puppet而不是shell脚本?


Puppet和Chef工具的新功能。看起来他们正在做的工作可以通过shell脚本来完成。也许它是在shell脚本中完成的,直到它们出现。

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


78
2018-05-01 10:13






答案:


特定于域的语言会对您编写的代码量产生很大影响。例如,你可以说,之间没有太大区别:

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做的就越省力。


55
2018-05-01 11:14



@Paul Gear,从长远来看,配置管理工具是可行的方法,这简直过于简单了。例如,使用AWS,shell脚本可以从头开始构建服务器,运行一些测试,一旦确定AWS instaces正常,就可以创建一个映像。然后,您可以将此映像部署到预览或暂存环境以进行进一步测试,一旦您验证映像是否适合您的目的,那么您将进入生产阶段。在这种情况下,配置管理工具根本没有帮助。 - Derek Litz
现在,如果您想管理人们每天使用的100个专用服务器(并且您几乎无法控制他们的工作,错误与否),那就是应该使用配置管理工具的地方。 - Derek Litz
这不是一个非常有说服力的例子。我可以从wget开始,然后我不会以一种奇怪的状态结束。文件就像一个事务,如果任何步骤不成功将被回滚? - PSkocik


这将是一个不受欢迎的意见,但配置管理系统不一定更好。有时简单真的是最好的。

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

我只有几个实例,我们部署了配置管理并且卡住了。始终存在大量具有重复配置且需要执行可配置的千篇一律的部署的系统。


31
2018-05-01 14:58



当管理环境的成本太高以至于管理自动化真的更便宜。如果更简单地编写在Git中管理的更改或在ssh多路复用器中进行设置,我们就这样做了。对我来说最重要的是我监控系统并验证一切是否按预期运行。只要在配置错误的情况下我收到警报,它的配置就不那么重要了。 - kenchilada
@ewwhite“你什么时候决定自动化而不是” xkcd.com/1205 - MikeyB
更多现代工具(如Ansible)的部署/管理开销要比Chef或Puppet少得多,几乎不需要依赖(Ansible特别是无代理)。这确实降低了采用率。 - GomoX
@ewwhite当您想要个人生产力时,您可以自动化。通过自动化学习,你不会通过做平凡的任务来学习。学习=提高生产力和迭代改进。自动化与此相结合,产生更多积极因素。这是一个积极的雪球,而不是一个负面的雪球。技术进步与技术债务。 - Derek Litz
@ A-B-B不,这并不暗示。我甚至没有提到shell脚本,我提到自动化作为一般做法。您可以使用shell脚本自动执行操作并学习脚本抽象,而不是手动执行操作,这不仅可以节省您再次执行该任务的时间,还可以防止错误。此外,您应该能够比最后一个脚本更好地编写下一个脚本。一个积极的雪球...但是,如果你是编写脚本的专家而且你没有脚本,那么你将再次运行它,它无助于你以任何方式学习或节省时间。 - Derek Litz


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

自动化正在变得更具可扩展性和形式化。这些天木偶和厨师被认为是标准(检查 招聘广告)。

拼凑在一起的shell脚本有它们的位置,但它们是  在DevOps运动的上下文中可扩展。可读性是其中的一部分。


23
2018-05-01 10:40



shell脚本在某种程度上不太正式化吗?引用招聘广告是否有说服力?由于他/她作为一名开发人员未被充分利用,因此他们非常羞耻。该链接没有说明可伸缩性。声称shell脚本不可伸缩吗?我认为Puppet很有趣,但不一定是答案中的原因。 - A-B-B
招聘广告反映了特定技能的真实市场。是的,使用配置管理实现其预期目的比shell脚本更具可伸缩性,更强大和更容易记录。我一直在很多环境中,我看到的大多数脚本都不是以一种人们认为“生产质量”和组织来处理异常的方式构建的。请参阅接受的答案以了解原因。 - ewwhite
“因为他/她作为一名开发人员未被充分利用,所以他们非常羞耻。”这根本不是真的。 DevOps是一个开发专业,就像Web开发一样。软件开发的模式和实践仍然适用。你应该阅读有关DevOps的内容。 - Chaim Eliyah


厨师使管理更容易  设置复杂的基础设施,特别是在任何类型的云环境中,而不是手动ftp或scp以非标准化的方式组织的一堆shell脚本。根据您需要管理的依赖项数量,此次获胜的大小可能会有很大差异,因此,对于很多人来说,转移到CM解决方案的决定是非常明显的。

Chef的真正(通常是无名)好处是 幂等。能够确定资源的状态,无论具有重叠兴趣的配方组合,都比shell脚本配置具有巨大的优势。如果您现在有配置的shell脚本,请问自己有多少可以多次运行而没有意外/不良后果?

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

关键部分:

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

13
2018-05-03 19:11



ss几乎不可能出现幂等性。 yum / apt等可以很好地管理依赖关系。接受是无关紧要的。 ss存在社区知识。但是,我接受的是,不必复制一堆脚本,也无需集中配置系统,这两者都很有用。我听说puppet需要一个客户端代理。 - A-B-B


现代配置管理工具(如Puppet和Chef)允许您定义  系统而不是担心 活动 实现配置的服务器所必需的。

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

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


10
2018-05-20 02:19



其实我的 chmod 不假定文件存在,因为该文件是由脚本创建的或由脚本测试存在的。 - A-B-B


如果服务器对您来说是一次性的,或者您有理由一次支持多个服务器,那么完整的CM系统将比一系列shell脚本更好地满足您的需求。

如果您的构建需求适度,(或者喜欢手工制作有机自由范围的公平交易服务器),那么请保持简单。

就个人而言,在过去的演出中广泛使用了Chef,我试图在这场演出中“保持简单”,但我真的很想念Chef提供的原语,抽象和力量。即使你遇到了从一些shell命令中得到你需要的东西的情况,你也可以简单地运行那些带有'command'块的东西,输入你的shell命令就像在shell中编写它们一样。

话虽如此,你可以在没有服务器的情况下运行Chef(chef-solo),我很确定Puppet有一个模拟器,你可以在不运行中央服务器的情况下利用其他人的烹饪书和食谱。

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


9
2018-05-01 22:32





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

我确信我不是第一个做这类项目的人,但我找不到合适的东西来满足我的需求,所以我认为其他人可能觉得这很有用。我只有Chef的经验,但是当我开始环顾Ansible和其他人时,我想给shell脚本一个镜头,我喜欢到目前为止的结果。


1
2017-12-25 01:15