当我撰写专栏时，我尽量坚持使用您可以用来让 Linux 生活更轻松的特定技巧或窍门。通常，我会非常详细地描述如何完成特定任务，包括命令行和配置文件示例。然而，这一次，我偏离了这条经过实践检验的技术技巧之路，转而讨论更通用、更高级的概念、策略，坦率地说，是关于系统管理的个人观点。

在本文中，我将讨论当前服务器部署的最新技术水平。多年来，系统管理员安装和配置服务器的方式发生了变化，因为他们一直在寻找使工作更轻松的方法。每一次改变都带来了基于过去经验的改进，但也带来了自身的新缺陷。在这里，我将确定几种不同代的服务器部署策略，并讨论我认为系统管理员的最佳实践。

最初，服务器完全是手动配置的。例如，当需要 Web 服务器时，系统管理员首先会逐个问题地完成 Linux 操作系统安装。在分区时，系统管理员会仔细考虑应该有多少个分区，以及对于此特定应用程序，/、/home、/var、/usr 和 /boot 真正需要多少空间。一旦操作系统安装完成，系统管理员要么会通过发行版的软件包管理器下载并安装 Apache 软件包（如果感觉偷懒），要么更可能下载最新稳定版本的源代码，并运行 ./configure; make; make install 流程，并使用自定义编译时选项。一旦所有软件都安装完成，系统管理员将仔细研究每个配置文件，并调整和优化每个选项以符合要求。

甚至服务器的主机名也是经过深思熟虑的，选择的名称专门用于适合该服务器的特定个性（尽管它可能在系统管理员职业生涯的某个时候以某个希腊或罗马神的名字命名——系统管理员似乎喜欢这种命名方案）。最终，您将拥有一个非常定制、高度优化、调整和优化的服务器，对于创建它的系统管理员来说，它更像是一个宠物，而不是一台机器。这台服务器真是一片独一无二的雪花，一年后，当您想要第二个与它完全相同的服务器时，如果最初的系统管理员还在那里（并且如果他或她能记住过去一年中对服务器所做的一切），您或许可以接近目标；否则，下一个可怜的系统管理员就得当侦探了。更糟糕的是，如果该服务器发生故障，您必须希望有良好的备份，否则不知道需要多长时间才能构建一个替代品。

事实上，今天仍然有很多系统管理员以这种方式部署服务器，如果您只负责少数服务器，或者如果您的公司能够负担得起每十台服务器左右配备一名管理员（多年前的旧建议），那也没关系。但在大多数情况下，管理员已经从完全手动配置服务器转向以下三种服务器部署自动化方式之一。

系统管理员开始意识到，对于大量的服务器来说，完全手动部署服务器是不可持续的，特别是当您需要多种类型的服务器时。作为回应，管理员会一丝不苟地完成所有步骤，从头开始制作一台新服务器，一旦完成这项工作，他们就会创建该服务器的完整磁盘镜像，并锁定其全新安装状态。当他们需要另一台与它完全相同的服务器时，他们只需使用 Ghost 或甚至是 dd 等软件将该镜像应用到新硬件上，然后进入并更改一些服务器特定的设置，如主机名和网络信息（如果他们想进一步自动化，可能会通过脚本），服务器就准备好了。他们可以在几个小时内启动并运行这台服务器，而不是几天或几周才能部署一台服务器。当系统管理员想要 Web 服务器时，他们只需找到并将他们之前创建的 Web 服务器镜像应用到裸机上，在许多情况下，大约一个小时左右，他们就会拥有一台新的功能正常的 Web 服务器。

镜像的问题最终变成了维护。每当您决定升级服务器上的软件时，您都会面临一个两难境地：要么经历痛苦的步骤来创建具有升级软件的新镜像，要么部署旧镜像并在之后手动运行任何软件升级。无论哪种方式，您仍然必须弄清楚如何处理现场的现有服务器。您是否使用更新的镜像重新镜像它们，并经历备份和恢复镜像后制作的任何唯一数据的麻烦，或者您是否手动应用您刚刚对镜像所做的更改？此外，您可能会遇到两台服务器，它们大部分相同，但差异足以证明需要使用不同的镜像，最终您会发现自己维护着一个不断增长的大型磁盘镜像库，即使它们可能共享 90% 的相同软件。

为了应对维护服务器镜像的所有麻烦，一些管理员意识到他们可以绕过由于他们将相同的基本操作系统安装到所有机器而导致的重新生成磁盘镜像的痛苦，并且之后他们才应用任何特定更改。正是从这种认识中，诞生了下一代——使用安装后脚本的自动化安装。

使用自动化安装（例如基于 Red Hat 发行版的 kickstart 或基于 Debian 发行版的 preseeding），管理员可以创建一个配置文件，其中包含他们在安装时手动选择的所有选项，然后在启动时将其提供给安装程序，去喝杯咖啡，当他们回来时，服务器会在没有他们的情况下完成整个安装过程。如果管理员想要 Web 服务器，他们只需选择 Web 服务器的安装程序配置文件，该文件将列出一组发行版软件包，包括 Web 服务器软件，供安装程序自动选择和安装。

当然，自动化安装程序通常只为您留下一个带有已安装但未配置的额外软件包的基本操作系统。这些自动化安装程序真正的魔力在于它们的安装后脚本。简而言之，安装后脚本是安装程序在基本安装完成后将在系统上执行的 shell 脚本。安装后脚本变成了系统管理员的自动化梦想。如果您可以将您想要对系统进行的所有命令和配置文件更改描述在一个 shell 脚本中，您可以将其放入安装后脚本中，并拥有一个完全自动化的服务器安装。

与镜像相比，安装后脚本的好处很快变得显而易见。每当您想要更改安装程序时，您所要做的就是更改安装程序配置文件或您的安装后脚本——无需重新生成镜像。这些文件是文本文件，并且占用磁盘空间非常小。这些文件很容易更改，但与镜像不同，当您更改安装后脚本时，通常您需要完成整个自动化安装以确保您没有引入错误。

事实上，使用安装后脚本自定义的自动化安装可能是自动化服务器部署的有效方法，并且它仍然是当今广泛使用的一种方法。尽管如此，它并非没有自身的问题。安装后脚本方法的主要问题是自动化在服务器最初创建时就停止了。您对 Web 服务器安装后脚本所做的任何改进都只会对任何新服务器有所帮助——在这些改进之前创建的任何服务器都将有所不同。您将面临尝试将改进反向移植到现有服务器或基于新的安装脚本完全重建它们的困境。尽管尝试将任何改进应用于现有服务器更容易，但您永远不会确信您六个月前设置的服务器和您今天设置的服务器是相同的。曾经有一段时间，我为了解决这个困境所做的事情是将我所有的配置文件更改都放入软件包中，我会将这些软件包放在本地软件包存储库中，然后在任何相关的服务器上安装。

最后一代服务器部署尝试解决安装后脚本的主要问题：对配置的任何更改仅适用于新安装的服务器；因此，新旧服务器往往彼此失去同步。为了解决这个问题，管理员现在正在转向配置管理系统，如 Puppet 和 Chef。使用集中式配置管理，您需要进行的任何更改都在配置管理服务器上进行，然后部署到所有相关服务器，无论它们已经存在一年还是今天刚刚创建。只要您通过中央服务器进行更改，您就可以确信服务器的配置是相同的。

使用集中式配置管理，自动化安装和安装后脚本不会被抛弃，它们只是变得更加通用。自动化安装不再是通过安装后脚本完成所有配置，而是仅安装操作系统的基本要素，而安装后脚本仅执行使配置管理软件可以签入所需的任何操作。配置管理系统从那里接管，并进行任何它需要进行的更改，包括软件包安装和配置文件更改，以使服务器准备好使用。因为您可以更确信新服务器将与旧服务器匹配，所以您最终会减少对任何单个服务器发生故障的恐惧——毕竟，如果您可以在几分钟内重新创建它，为什么要担心呢？

希望本文为您改进服务器部署策略提供了一些想法，或者以其他方式验证了您已经做出的服务器部署决策。只是要小心；这种自动化功能强大，如果您不小心，您可能会在某天上班时发现您已经被一个 shell 脚本取代了。