☰

自动化服务器部署

tag-icon • tag-icon vps deployment automation
自动化服务器部署

我发现我经常为我的许多客户设置几乎相同的服务器和 VPS，这可能非常耗时。通常，每次部署之间唯一的变化就是要服务的网站不同。有没有一种简单的方法可以自动完成所有这些工作，并免去设置 56 台相同服务器的单调乏味？

到目前为止，我部署的服务器只有 Ubuntu，但我可能会开始使用其他 Linux 操作系统甚至 Windows。到目前为止，我已经看过 Capistrano，但它似乎专注于编写小型 Rub​​y 程序来完成工作，而我对此一无所知

答案1

木偶这听起来非常适合您要做的事情，但需要注意的是，截至目前，它还不支持 Windows。

在您的案例中，您将根据所有机器上相同的包来定义一个服务器节点。然后，您将各个主机定义为从服务器继承的节点，并为其设置特定的唯一内容。

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 配置保存在版本控制系统中是标准做法 - 因此您可以随时回顾并查看您过去如何设置服务器 - 或回滚一些不成功的更改。

最后，这是快速视频这是一个简单的木偶演示，可以帮助我快速入门。

答案2

我们使用皮匠和木偶用于真实机和虚拟机的构建和配置自动化。

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

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

然后virsh console无需任何交互即可观看 VPS 构建。

我们使用 RHEL，并设置了一系列配置文件来分区磁盘、配置网络和安装不同服务器类别的基础包。Cobbler 支持 Debian 和 Ubuntu 版本，但我从未尝试过。另外：Cobbler 的其他有趣用途包括运行记忆测试ISO 和HP 固件更新。

一旦我们的系统使用 Cobbler 构建完成，Puppet 就会接管配置应用程序、系统守护程序、向 RHN 注册设备等。Puppet 作为守护程序运行，定期检查系统的配置是否与定义的清单相匹配 - 您知道您的更新已发送到所有服务器。这也是一种很好的方法，可以在您将因维护而停机的设备恢复到实时服务之前确保其配置正确。

Puppet 真的很棒。您不需要让其控制配置的每个方面——首先让它管理您需要在每个框上配置的简单内容（sudoers这是典型示例），然后从那里开始。确保您的 Puppet 清单也已版本化；没有什么比能够轻松回滚到已知良好的配置而不必记住要调整什么更好的了。

答案3

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

皮匠

我们研究了 cobbler，但问题是 cobbler 只针对 RHEL/Red Hat。我们至少需要支持 RHEL 和 SLES，接下来是 Ubuntu。

木偶

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

热线

我们使用的是 Hotwire（内部开发，但开源），过去几年一直使用。它首先盘点将要构建的系统，这意味着盘点数据中心、机架、硬件、操作系统、网络等，然后执行快速构建和部署。系统构建完成后，hotwire 的自动盘点功能会保持盘点同步，而 cfengine 会维护它们。Hotwire 通过以下方式与 Bios 中的 SMBIOS/DMI 数据通信来了解服务器硬件python-dmidecode。

额外的好处是它将库存和构建过程合二为一，因此需要管理的工作更少，而且实时库存功能非常棒，因为我们知道是否有某些东西不太对劲。

缺点是用户界面仍然需要完善，并且到处都有错误，但开发仍然很热门，报告的错误修复相对较快。

CF引擎

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

cfengine 推送到服务器的配置和所有文件也保存在 SCM 中，并使用提交后挂钩（如果可能）检查语法，如果语法不合格，则拒绝提交。这对于 Apache 等优秀应用程序来说很容易，但对于大多数企业应用程序来说却不那么容易。

答案4

根据目标系统自动安装：

  • Debian/Ubuntu：FAI 或 di 预置
  • RedHat/Fedora：Kickstart
  • Novell/openSuSE：AutoYaST
  • Solaris：快速启动
  • Windows：unattended.sourceforge.net

对于上面的配置管理，我建议使用 puppet。

相关内容