下载掌阅APP，畅读海量书库
立即打开
到目前为止，你应该对什么是SOE以及它如何为Linux环境带来规模经济和更高的效率有所了解。现在，让我们在此基础上更详细地看一个标准化重要性的例子。
在Linux环境中有共同点指组成SOE的服务器都共享一些属性和特性。例如，它们可能都是基于Ubuntu Linux构建的，或者它们都用Apache作为其Web服务器。
我们可以用一个例子来探讨这个概念。假设在负载均衡器后面有10台Linux Web服务器，它们都提供简单的静态内容。一切正常，但随后必须进行配置更改。也许这是为了更改每个Web服务器的文档根目录，使其指向另一个团队已部署完成的新代码版本。
由于整个解决方案是负载均衡的，所以所有服务器都应该提供相同的内容。因此，每台服务器都需要进行配置更改。这意味着，如果你手工更改的话，需要更改10个配置。
手工完成这项工作将是一项乏味的工作，对于熟练的Linux管理员来说，这肯定不是最佳的方式。它也很容易出错——在10台服务器中的一台上可能会出现打字错误，但不会被发现。或者管理员可能会被其他事情中断，最后只更改了服务器配置的一部分。
更好的解决方案是编写一个脚本来进行更改。这正是自动化的基础，几乎可以肯定的是，在10台服务器上运行一次单个脚本要比在10台服务器上手动进行相同的更改更节省时间。它不仅效率更高，而且如果在一个月内需要进行相同的更改，那么只需稍加调整就可以重用脚本。
现在，让我们把计划打乱。如果由于未知的原因，有人在CentOS 7上使用Apache构建了5个Web服务器，而在Ubuntu 18.04 LTS上使用nginx构建了另外5个服务器，会怎么样？最终的结果是相同的，毕竟，在一个基本的水平，它们都是网络服务器。但是，如果要在CentOS 7上的Apache中更改文档根目录，则需要执行以下操作：
1.在/etc/httpd/conf.d中找到相应的配置文件。
2.对DocumentRoot参数进行所需的更改。
3.使用systemctl reload httpd.service重新加载Web服务器。
如果必须在Ubuntu18.04 LTS上对nginx执行相同的操作，你可以执行以下操作：
1.在/etc/nginx/sites-available中找到正确的配置文件。
2.对root参数进行所需的更改。
3.确保已使用a2ensite命令启用站点配置文件。否则，Apache将看不到配置文件。
4.使用systemctl reload apache2.service重新加载Web服务器。
从这个相当简单（尽管是人为的）的例子中可以看出，缺乏通用性是自动化的敌人。为了应对这种情况，你需要执行以下操作：
1.检测每台服务器上的操作系统。没有一种方法可以检测Linux操作系统，因此你的脚本必须经过一系列检查，包括以下内容：
1）/etc/os-release的内容（如果存在）。
2）lsb_release的输出（如果已安装）。
3）/etc/redhat-release的内容（如果存在）。
4）/etc/debian_version的内容（如果存在）。
5）如果上述步骤没有产生有意义的结果，则根据需要提供其他操作系统所需的特定文件。
2.在不同的目录中运行不同的修改命令以影响更改，如前所述。
3.运行不同的命令来重新加载Web服务器，同样如前所述。
因此，脚本变得复杂，更难编写和维护，当然也更难使其可靠。
尽管这个特殊的例子在现实生活中不太可能出现，但它确实有助于说明一个重要的问题：当环境按照给定的标准构建时，自动化更容易实现。如果决定所有Web服务器都基于CentOS 7且都运行Apache 2，并以服务名称命名站点配置，那么自动化就变得简单多了。实际上，你甚至可以运行一个简单的sed命令来完成更改。例如，假设新的Web应用程序部署到/var/www/newapp:
根本不需要环境检测，只需两个简单的shell命令。这是一个非常简单的自动化脚本的基础，可以依次在10台服务器上运行，也可以通过SSH远程运行。不管是哪种方式，我们的自动化任务现在都非常简单，并且显示了通用性的重要性。重要的是，SOE在本质上提供了这种通用性。缺乏通用性不仅使自动化变得困难，而且还会妨碍测试，常常会扭曲测试结果，因为如果环境不同，测试结果可能不具有代表性。
下面我们将在这些知识的基础上演示SOE如何为软件测试过程带来好处。
我在许多环境中看到的一个常见问题是，一个新的软件部署在一个隔离的预生产环境中成功地进行了测试，但在发布到生产环境中时却不能正常工作。通常，这个问题可以归结到生产环境和预生产环境之间的根本区别。因此，要使测试有效，两个环境必须尽可能相似。
事实上，像Docker这样的容器化平台要解决的问题之一就是这个问题，因此可移植性是容器环境的一个核心特性。部署在Docker上的代码构建在容器映像之上，简单地说，就是一个精简的操作系统映像（还记得JeOS吗？）。实际上，这是一个非常小的SOE，只是在容器中运行，而不是在裸机服务器或虚拟机上运行。然而，值得考虑的是，如果通过环境标准化实现的可移植性是容器技术的一个关键特性，那么我们不应该尝试在不考虑基础设施的情况下全面实现这一点。
毕竟，如果生产服务器的配置与预生产服务器不同，那么测试的有效性如何？如果预生产环境是在CentOS 7.6上构建的，但是生产环境是落后于它的CentOS 7.4，那么你真的能确保在一个环境中成功的测试结果将保证在另一个环境中成功吗？从理论上讲，它应该可以工作，但由于环境之间的软件和库版本存在根本性差异，这永远无法得到保证。这甚至是在我们考虑配置文件和安装的软件之间可能存在的差异之前需要考虑的。
因此，如果所有的环境都按照相同的标准构建，那么从理论上讲，它们都应该是相同的，那么SOE在这方面可以提供帮助。那些目光敏锐的人会注意到“应该”这个词在前一句中的用法，这是有充分理由的。SOE在定义解决测试失败的方案方面向前迈出了一大步，但它们并不是全部。
一个环境只有在没有人修改它的情况下才是标准的，如果所有用户都有管理员级别的权限，那么很容易有人登录并进行更改，这意味着环境偏离了标准。
这个问题的答案是自动化，SOE不仅仅是促进和实现自动化，它们还依赖于自动化来保持最初要求的标准化水平。两者直接相互支持，理想情况下应该是不可分割的伙伴：SOE是环境本身的定义，自动化提供标准的实现、执行和审计。实际上，这正是本书的前提，即环境应该尽可能地标准化，并且应该尽可能多地更改自动化。
本书的重点将放在这个等式的自动化方面，因为除了坚持本章概述的原则之外，所采用的标准对于每个环境都是独特的，本书的目标不是在微观级别上确定它们。以前面的示例为例，Apache和nginx都有它们的优点，适合一个用例的可能不适合另一个用例。
操作系统也是如此，一些机构可能依赖Red Hat Enterprise Linux提供的支持软件包，而其他机构则不需要支持软件包，但需要Fedora提供的前沿技术。定义一个标准没有对错之分，只要满足它所支持的服务的需求。到目前为止，我们非常关注通用性和标准；然而，在需要替代解决方案的情况下，总会有一些边缘案例。在下一节中，我们将确定如何知道何时应该偏离标准。