傀儡和厨师工具新。 看起来像他们正在做的工作可以用shell脚本来完成。 也许这是在shell脚本中完成，直到这些脚本出现。
我会同意他们更可读。 但是，除了可读性外，还有别的优点吗？
特定领域的语言对您编写的代码量有很大的影响。 例如，你可以争辩说，没有太多的区别：
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来正确的内容呢？
你可能会争辩说，除了在第一个例子中脚本必须在客户端运行，而puppet在服务器上编译所有这一切之外，可以在脚本中放置echo "Hello world" > $FILE 。 所以，如果你改变了内容，你只需要在服务器上改变它，并且改变了你想要放置的系统。 傀儡会自动处理依赖关系并为您传输问题。
没有比较 – 适当的configurationpipe理工具可以节省您的时间和复杂性。 你越想做，越多的shell脚本似乎不足够，你用傀儡做更多的努力。
这将是一个不受欢迎的意见，但configurationpipe理系统不一定更好。 有时简单真的是最好的。
有一个确定的学习曲线和pipe理开销与您select的configuration系统相关联。 毕竟你引入了依赖。 与任何自动化一样，您还必须小心在部署的configuration中保持安全。
我只有几个实例，我们部署了configurationpipe理，并停滞不前。 总是有大量系统重复configuration，并需要执行可configuration的cookies部署。
你已经回答了你自己的问题
自动化正在变得更加可扩展和正式化 。 木偶和厨师这些天被认为是标准（检查招聘广告 ）。
拼凑在一起的shell脚本有其自己的位置，但是在DevOps运动的背景下它们不具有可扩展性。 可读性是其中的一部分。
Chef使得pipe理和版本设置复杂的基础架构变得容易很多，尤其是在任何types的云环境中，而不必手动ftp或scp以非标准化方式组织的一组shell脚本。 取决于你需要pipe理多less依赖关系，这个胜利的大小可能会有很大的差异，因此决定转移到一个CM解决scheme对于很多人来说是非显而易见的。
厨师的真正（通常是无名的）好处是幂等性的 。 能够确定某个资源的状态，而不考虑运行着重叠兴趣的配方组合，这与shell脚本configuration相比是一个巨大的好处。 如果现在有用于configuration的shell脚本，问问自己可以多less次运行它们，而没有意外/不期望的后果？
合适的CM解决scheme通过简化跨平台自动化和团队协作来帮助确保规模的成功。 虽然可以通过组织良好，维护良好，版本化的shell脚本来完成所有这些工作; 你必须问自己“为什么”。 厨师/木偶和类似的技术出现了，因为一群天才的SysOps厌倦了一遍又一遍地解决这些相同的问题，并开始给我们一个更好的select。
像Puppet和Chef这样的现代configurationpipe理工具允许你定义一个系统的状态 ，而不用担心实现configuration服务器所需的活动 。
例如，您的chmod命令假定文件存在，拥有文件的用户存在，目录已经创build等等。 因此，您的脚本必须考虑所有这些先决条件。
基于状态的configurationpipe理工具更简单：您只需要关心文件是否具有正确的权限。 这是如何实现的工具的问题。
如果服务器对你来说是一次性的，或者你一次只能站起来，一套完整的CM系统将比一系列shell脚本更好地满足你的需求。
如果你的构build需求不大，（或者喜欢手工制作有机自由放送的公平交易服务器），那么保持简单。
就个人而言，在过去的演出中广泛地使用过厨师，我试图在这个演出中“简单化”，但是我真的错过了厨师提供的原始，抽象和力量。 即使你遇到了可以从shell命令中获得所需内容的情况，也可以简单地使用'command'命令块来运行这些命令，然后像在shell中一样inputshell命令。
有了这个说法，你可以在没有服务器（厨师独奏）的情况下运行Chef，而且我很确定Puppet有一个类似的东西，你可以在没有中央服务器的情况下利用别人的食谱和食谱。
社区的另一个好处是：有很多人（其中许多人比你更聪明和/或更有经验）。 就我个人而言，当别人为我完成我的工作时，我喜欢它，这通常比我的工作要广泛得多。
我创build了一个基于shell脚本的服务器自动化框架： https ： //github.com/myplaceonline/posixcube
我确定我不是第一个做这种项目的人，但是我找不到适合自己需求的东西，所以我想其他人可能会觉得这很有用。 我只有厨师的经验，但是当我开始环视Ansible和其他人的时候，我想给shell脚本一个镜头，我喜欢这个结果。