主页 / server / 问题 / 504070
Accepted
resting
Asked: 2013-05-02 02:13:17 +0800 CST

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

  • 772

Puppet 和 Chef 工具的新功能。似乎他们正在做的工作可以用 shell 脚本来完成。也许它是在 shell 脚本中完成的，直到这些脚本出现。

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

scripting

7 个回答

  1. Best Answer

    特定领域的语言对您编写的代码量有很大的影响。例如，您可能会争辩说：

    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 做它会节省更多的精力。

    • 57

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

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

    我只有几个部署配置管理的实例，但它卡住了。总是有大量系统重复配置，需要执行可配置的千篇一律部署。

    • 33

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

    自动化正变得更具可扩展性和形式化。如今，Puppet 和 Chef 已被视为标准（查看招聘广告）。

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

    • 24

  4. Chef 使复杂基础设施的设置管理和版本化变得更加容易，特别是在任何类型的云环境中，而不是必须手动 ftp 或 scp 以非标准化方式组织的一堆 shell 脚本。根据您需要管理的依赖项数量，这种胜利的大小可能会有很大差异，这使得转向 CM 解决方案的决定对很多人来说并不是显而易见的。

    Chef 的真正（通常是不为人知的）好处是幂等性。与 shell 脚本配置相比，无论以重叠兴趣运行的配方组合如何，都能够确定资源的状态是一个巨大的优势。如果您现在有用于配置的 shell 脚本，问问自己有多少脚本可以多次运行而不会产生意外/不良后果？

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

    关键部分：

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

  5. Puppet 和 Chef 等现代配置管理工具允许您定义系统的状态，而不用担心实现配置服务器所需的活动。

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

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

    • 11

  6. 如果服务器对您来说是一次性的，或者您有理由一次站多个服务器，那么成熟的 CM 系统将比一系列 shell 脚本更好地满足您的需求。

    如果您的构建需求不大，（或者喜欢手工制作有机自由放养公平贸易服务器），那么请保持简单。

    就个人而言，在过去的演出中广泛使用了 Chef，我试图在这次演出中“保持简单”，但我真的很怀念 Chef 提供的原语、抽象和强大功能。即使您遇到可以从几个 shell 命令获得所需内容的情况，您也可以简单地使用“命令”块运行这些命令，输入您的 shell 命令，就像在 shell 中编写它们一样。

    话虽如此，您可以在没有服务器的情况下运行 Chef (chef-solo)，而且我很确定 Puppet 有一个类似的东西，您仍然可以在没有运行中央服务器的情况下利用其他人的食谱和食谱。

    另一个好处是社区：有很多人（其中许多人比你更聪明和/或更有经验）。就我个人而言，我喜欢别人为我完成工作，通常比我做的更广泛。

    • 9

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

    我确定我不是第一个进行此类项目的人，但我找不到满足我需要的类似项目，所以我认为其他人可能会觉得这很有用。我只有 Chef 的经验，但当我开始环顾 Ansible 和其他工具时，我想尝试一下 shell 脚本，到目前为止我喜欢这个结果。

    • 1

相关问题