☰

为什么要使用 Chef/Puppet 而不是 shell 脚本？

tag-icon • tag-icon scripting puppet chef configuration-management provisioning
为什么要使用 Chef/Puppet 而不是 shell 脚本？

刚接触 Puppet 和 Chef 工具。似乎他们所做的工作可以用 shell 脚本来完成。也许在这些出现之前，这项工作都是用 shell 脚本完成的。

我同意它们更易读。但是，除了易读之外，与 shell 脚本相比还有其他优势吗？

答案1

领域特定语言会对您编写的代码量产生很大影响。例如，您可能会认为以下两者之间没有太大区别：

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 可以节省更多的精力。

答案2

这可能是一个不受欢迎的观点，但配置管理系统并不一定更好。有时简单才是最好的。

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

我只遇到过几次部署配置管理后卡住的情况。这种情况总是发生在有大量重复配置的系统，需要执行可配置的千篇一律的部署时。

答案3

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

自动化变得更加可扩展和规范化。Puppet 和 Chef 如今已被视为标准（查看招聘广告）。

拼凑起来的 shell 脚本有它们的作用，但它们不是在 DevOps 运动的背景下可扩展。可读性是其中的一部分。

答案4

Puppet 和 Chef 等现代配置管理工具允许您定义状态而不是担心活动需要实现一个配置好的服务器。

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

基于状态的配置管理工具更简单：你只需要关心文件是否具有正确的权限。如何实现这一点是工具的问题。

相关内容