傀儡和厨师工具新。 看起来像他们正在做的工作可以用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脚本一个镜头,我喜欢这个结果。