自动化服务器部署

Question

我发现我经常为我的许多客户设置几乎相同的服务器和 VPS，这可能非常耗时。通常，每次部署之间唯一变化的是要提供服务的不同网站。有没有一种简单的方法可以使所有这些自动化并消除设置 56 个相同服务器的无聊单调？

到目前为止，我部署的服务器只是 Ubuntu，但我可能会开始使用其他 linux 操作系统甚至 Windows。到目前为止，我已经看过 Capistrano，但它似乎专注于编写小的 ruby​​ 程序来完成这项工作，而我根本没有任何知识

Answer 1

Puppet听起来很适合您尝试做的事情，但需要注意的是，截至目前，不支持 Windows。

在您的情况下，您将根据跨机器相同的所有包定义服务器节点。然后，您将各个主机定义为从 Server 继承的节点，并为其设置特定的独特事物。

Puppet 是声明性的——它允许你根据每个盒子应该拥有的资源来描述你的盒子。因此，如果您愿意ssh- 您为该资源编写一个类 - 在该类中，您可以包含有关在 FreeBSD 与 Ubuntu 上如何调用 ssh 略有不同的逻辑。它还知道yum在 Redhat 内部和apt-get基于 Debian 的发行版以及portsBSD 中使用。现在在您的服务器节点中，您将只需要一行include ssh- 并且 puppet 会做正确的事情并将 SSH 放在机器上，而您不必记住那是 Ubuntu、Redhat 还是 FreeBSD。

好处是所有服务器的东西都集中在一个地方——如果你在任何时候添加到服务器节点定义，所有的机器都会相应地更新它们的配置。

现在，我只使用 Puppet 管理三个盒子 - 但它已经得到了回报。在花了一个星期设置了一个我们将在实验中用于刺激演示的盒子后，结果发现显卡驱动程序在我安装的 Ubuntu 版本 (8.04) 中太旧了。我必须安装最新的 Ubuntu (9.04)，但在那之后我只需要 apt-get 并运行 puppet - 我花了一个星期设置的所有东西都被恢复了。

Puppet 确实有一点学习曲线，但我已经成功地避免了学习 Ruby - 我知道我正在使用它，因为 puppet 就是用它编写的 - 但到目前为止我已经成功地修改了 Ruby 中的示例wiki 上的文档和食谱。另一个缺点是 puppet 第一次做事情确实需要更长的时间。好处是您在所有机器上更改的所有内容都存储在一个地方 - 将您的 puppet 配置保存在版本控制系统中是标准做法 - 这样您就可以随时回顾过去如何设置服务器- 或回滚一些不成功的更改。

最后，这是一个快速视频，它做了一个简单的木偶演示，让我快速入门。

Answer 2

我们使用Cobbler和Puppet实现真实和虚拟机的构建和配置自动化。

Cobbler 将 DHCP、PXE 启动和 Kickstart 结合在一起，使部署只不过是添加机器配置文件并按下电源按钮。对于虚拟机，该koan 命令执行（在我们的例子中）Xen 魔法来启动安装——dom0我只需输入：

koan --system vps.fqdn --server cobbler --no-gfx

然后virsh console在没有任何交互的情况下观看 VPS 建筑。

我们使用 RHEL 并设置了一堆配置文件来对磁盘进行分区、配置网络并为不同的服务器类安装基本包。Cobbler 支持 Debian 和 Ubuntu 品种，但我从未尝试过。旁白：Cobbler 的其他有趣用途包括运行memtest ISO 和HP 固件更新。

使用 Cobbler 构建我们的系统后，Puppet 会接管配置应用程序、系统守护进程、向 RHN 注册盒子等。Puppet 作为守护进程运行，它定期检查系统配置是否与定义的清单相匹配——您知道您的更新已经消失到所有服务器。这也是一种很好的方法，可以在您将其返回到实时服务之前确保已停机维护的盒子具有正确的配置。

傀儡真的很厉害。你不需要让你的配置的每个方面都在它的控制之下——首先让它管理一些你需要在每个盒子上配置的简单东西（sudoers是规范的例子），然后从那里开始。确保你的 Puppet 清单也是版本化的；没有什么比能够轻松回滚到已知良好的配置而不必记住要调整的内容更好的了。

Answer 3

我目前工作的地方，我们必须管理我们服务器场的 Linux 部分，它只有 300 多台 Linux 服务器。这主要包括 HP Proliants，其次是 IBM 3850s、一些 IBM 刀片、VMware ESX 和一些用于我们内部管理服务器的 KVM。

皮匠

我们查看了 cobbler，但问题是 cobbler 非常特定于 RHEL/Red Hat。我们至少需要支持 RHEL 和 SLES，接下来是 Ubuntu。

木偶

我们确实考虑过 puppet，但后来决定不使用它，因为它依赖于 Ruby，这意味着 Ruby 的升级可能会破坏我们的管理系统。

热线

Hotwire 是我们使用的（内部开发，但开源），并且在过去几年中一直如此。它首先清点将要构建的系统，即清点数据中心、机架、硬件、操作系统、网络等，然后进行快速构建和部署。系统建成后，hotwire 的自动盘点使盘点保持同步，而 cfengine 维护它们。Hotwire 通过python-dmidecode与 Bios 中的 SMBIOS/DMI 数据交谈来了解服务器硬件。

加分点是它将库存和构建过程合二为一，因此管理起来更少，而且实时库存功能非常棒，因为我们知道如果出现问题。

缺点是用户界面还需要打磨，bug多多，但开发依然火爆，上报的bug修复比较快。

引擎

我们使用 cfengine 是因为除了它和 puppet 之外，别无他物。它实际上是一个很好的工具，但“好”仅取决于您的政策有多好 - 如果您设置了危险的政策，那么一个小错误就会造成很大的损失。例如，根据政策，我们不“修改”文件，我们要么替换它们，要么不替换。此外，所有替换的文件都有一个标题，使编辑它的任何人都知道它将在下次运行时被替换（它每小时通过 cron 运行）。

cfengine 推送到服务器的配置和所有文件也保存在 SCM 中，并使用提交后钩子，在可能的情况下，我们检查语法，如果失败，则提交被拒绝。这对于 Apache 等优秀的应用程序来说很容易，但对于大多数企业应用程序来说就不是那么容易了。