我同意它们更具可读性。但是，除了可读性之外，shell脚本还有其他优点吗？
#1 楼
特定领域的语言在您编写的代码量上有很大的不同。例如，您可能会争辩说：chmod 640 /my/file
和
file { "/my/file":
mode => 640,
}
之间并没有太大区别，但是这些之间有很大的不同：您的脚本将如何处理？如果脚本中的某些内容之后要求$ FILE包含正确的内容，那会发生什么呢？该脚本必须在客户端上运行，而puppet在服务器上编译所有这些脚本。因此，如果您更改内容，则只需在服务器上进行更改，它就可以在要放入的尽可能多的系统上进行更改。而且，puppet会自动为您处理依赖关系和传输问题。
没有可比性-适当的配置管理工具可以节省您的时间和复杂性。您尝试做的越多，似乎更多的shell脚本不足，使用puppet进行操作将节省更多的精力。
#2 楼
这将是不受欢迎的观点，但是配置管理系统不一定更好。有时候简单确实是最好的选择。选择的配置系统有一定的学习曲线和管理开销。毕竟，您将引入依赖关系。与任何自动化一样，您还必须注意在已部署的配置中维护安全性。总是有大量具有重复配置的系统，并且需要执行可配置的cookie切割器部署。
评论
如果管理环境的成本如此之高，以至于自动化管理的确便宜。如果编写Git中管理的更改脚本或在ssh多路复用器中设置脚本更简单，我们可以这样做。对我来说最重要的是，我监视系统并验证所有功能均按预期运行。只要在配置错误时收到警报，配置它就并不重要。
– kenchilada
13年5月1日在16:15
@ewwhite“您何时决定自动化与否？” xkcd.com/1205
– MikeyB
13年5月1日在16:26
比Chef或Puppet等更现代的工具（例如Ansible）具有更少的部署/管理开销，几乎不需要依赖（特别是Ansible是无代理）。这确实降低了采用的门槛。
– GomoX
13年5月5日在19:25
@ewwhite当您想要提高个人生产率时，您可以实现自动化。您通过自动化学习，而不是通过执行普通任务学习。学习=生产力的提高和迭代的提高。自动化与此结合产生更多的积极影响。这是一个积极的雪球，而不是消极的雪球。技术进步与技术债务。
–德里克·丽兹（Derek Litz）
2013年12月12日18:22
@ A-B-B不，不是暗示的。我什至没有提到shell脚本，我只是提到自动化。您可以使用Shell脚本使事情自动化并学习脚本抽象，而不是手动做事，这不仅可以节省您再次执行该任务的时间，而且还可以防止出错。同样，您应该能够比上一个脚本编写更好的下一个脚本。积极的雪球...但是，如果您是脚本编写方面的专家，并且没有编写脚本，那么您将永远无法再次运行它，它无助于您学习或节省任何时间。
–德里克·丽兹（Derek Litz）
2014-09-25的3:53
#3 楼
您已经回答了自己的问题...自动化变得越来越可扩展且形式化。如今，木偶和厨师被视为标准（请查看招聘广告）。
拼凑在一起的shell脚本占有一席之地，但在DevOps运动的背景下它们无法扩展。可读性是其中的一部分。
评论
Shell脚本是否以某种方式不那么形式化？引用招聘广告是否能引起争论？ devops非常可惜，因为他/他没有被开发人员充分利用。该链接并未真正说明可伸缩性。是否声称Shell脚本不可扩展？我认为Puppet很有趣，但不一定出于答案的原因。
–触角
2014年9月24日16:19
招聘广告反映了特定技能的实际市场。是的，与外壳程序脚本相比，将配置管理用于其预期的目的更具伸缩性，更强大且更易于记录。我去过很多环境，而且我看到的大多数脚本的构建方式都不像人们认为的“生产质量”，而是组织起来处理异常。请参阅已接受的答案以了解原因。
–ewwhite
2014年9月24日在16:42
“开发人员实在是太可惜了，因为他/他作为开发人员尚未得到充分利用。”这根本不是真的。就像Web开发一样，DevOps是开发的专长。软件开发的模式和实践仍然适用。您应该阅读有关DevOps的信息。
– Chaim Eliyah
17年11月20日在0:14
#4 楼
Chef使得管理和版本化复杂基础架构的设置变得更加容易，尤其是在任何类型的云环境中，与必须手动ftp或scp一堆以非标准化方式组织的shell脚本相比。取决于您需要管理的依赖项数量，获胜的规模可能会大不相同，因此决定迁移到CM解决方案的决定对于很多人来说并不是显而易见的。厨师通常的好处是等幂。不管是否有重复的利益而运行的配方的组合，都能够确定资源的状态，这是对Shell脚本配置的巨大好处。如果您现在有用于配置的Shell脚本，请问自己自己可以多次运行它们而不会产生意想不到的/不希望的后果？适当的CM解决方案通过简化跨平台自动化和团队协作，有助于确保大规模成功。尽管可以通过组织良好，维护得当的Shell脚本版本组来完成所有这些工作；您必须问自己“为什么”。 Chef / Puppet和类似技术的出现是因为一群才华横溢的SysOps厌倦了不得不一遍又一遍地解决这些相同的问题，并着手为我们提供更好的选择。 />
幂等性
依赖关系管理（版本控制）的实现
标准化组织（在行业级别上接受）
抽象将服务器配置任务与系统级别详细信息分开
利用社区知识的能力（保证包含所有上述原则）
评论
ss几乎不可能实现幂等。依赖关系可以通过yum / apt等很好地管理。接受无关紧要。社区知识存在于SS。但是，我接受不必复制一堆脚本，也不必集中配置系统都是有用的。我听说木偶需要客户端代理。
–触角
2014-09-24 16:45
#5 楼
现代化的配置管理工具（例如Puppet和Chef）使您可以定义系统状态，而不必担心实现已配置服务器所需的活动。例如，您的chmod命令假定文件存在，存在拥有该文件的用户，已经创建目录等等。因此，您的脚本必须考虑所有这些先决条件。基于状态的配置管理工具更简单：您只需要关心文件具有正确的权限即可。工具的问题是如何实现的。
评论
实际上，我的chmod不假定该文件存在，因为该文件是由脚本创建的，或者由脚本测试了其存在性。
–触角
2014年9月24日下午16:27
#6 楼
如果服务器对您而言是一次性的，或者您一次只能站立几个，那么成熟的CM系统将比一系列shell脚本更好地满足您的需求。您的构建需求适中，（或喜欢手工制作有机的自由散布的公平交易服务器），然后保持简单。我个人在过去的演出中广泛使用过Chef在这次演出中“保持简单”，但我确实错过了Chef提供的原始，抽象和功能。即使遇到可以从几个shell命令中获得所需内容的情况，也可以简单地使用“ command”块运行那些命令，并完全按照在shell中编写的方式输入shell命令。
话虽如此，您可以在不使用服务器（chef-solo）的情况下运行Chef，而且我很确定Puppet具有类似的功能，您仍然可以在无需运行中央服务器的情况下利用他人的食谱和食谱。 />
社区的另一个好处是：有很多人（其中许多人比您更聪明和/或更有经验）。就个人而言，当别人为我完成我的工作时，我会喜欢它。
#7 楼
我创建了一个基于外壳脚本的服务器自动化框架：https://github.com/myplaceonline/posixcube我确定我不是第一个进行此类项目的人，但是我做不到找不到适合我需要的东西，所以我认为其他人可能会觉得这很有用。我只接触过Chef，但是当我开始环顾Ansible和其他应用程序时，我想尝试一下shell脚本，到目前为止，我仍然很喜欢结果。
评论
@Paul Gear，说配置管理工具是长远的路要走，这太简单了。例如，使用AWS，shell脚本可以从头开始构建服务器，运行一些测试，一旦确定AWS实例正常，就创建一个映像。然后，您可以将该映像部署到预览或临时环境中以进行进一步的测试，一旦您确认该映像可以满足您的目的，然后就可以进行生产了。在这种情况下，配置管理工具完全没有帮助。
–德里克·丽兹（Derek Litz）
2013年12月12日18:13
现在，如果您要管理人们每天使用的100台专用服务器（无论是否错误地对它们的工作都几乎没有控制），那就应该使用配置管理工具。
–德里克·丽兹（Derek Litz）
2013年12月12日18:16
这不是一个非常令人信服的例子。我可以从wget开始，然后我不会陷入怪异的状态。文件是否像事务，如果任何步骤不成功，都会回滚？
– PSkocik
15年5月16日在12:10