高效工作之一：标准操作环境（SOE）详解

sunsili

高效工作之一：标准操作环境（SOE）详解

SOE的定义和益处

节选自《基于Linux的企业自动化》第一章。

本章详细探讨了Linux中的标准操作环境（Standard Operating Environment以下简称SOE）概念。尽管我们稍后将更详细地讨论，但简而言之，SOE是一个以标准方式来创建和修改所有内容的环境。例如，这意味着所有Linux服务器都以相同的方式，使用相同版本的软件构建。这是一个重要的概念，因为它使管理环境变得更加容易，并减少了那些看管环境的人的工作量。

1. 2 什么是SOE？

既然我们已经探讨了SOE对企业如此重要的原因，并且从较高的层次上理解了解决这些问题的方法，那么让我们来详细了解一下SOE。

我们将从定义SOE本身开始。

1.2.1 定义SOE

让我们从一个更实际的角度来快速看一下。我们已经说过，SOE是一个概念，而不是绝对的。在最简单的层次上，它是一个通用的服务器映像或构建标准，部署在整个公司的大量服务器上。在这里，所有必需的任务都是以已知的、文档化的方式完成的。

首先是基本操作系统，正如我们所讨论的，有数百种Linux发行版可供选择。从系统管理的角度来看，有些非常相似（例如，Debian和Ubuntu），而有些则明显不同（例如，Fedora和Manjaro）。举个简单的例子，假设你想在Ubuntu 18.04 LTS上安装Apache Web服务器，你可以输入以下命令：

# sudo apt-get update

# sudo apt-get install apache2

现在，如果你想在CentOS 7上执行相同的操作，你可以输入以下命令：

# sudo yum install httpd

如你所见，这些命令之间没有任何共同之处，甚至连软件包的名称都不同，尽管这两种情况的最终结果都是安装了Apache。在小规模时，这不是一个问题，但是当服务器数量众多并且随着服务器数量的增加，管理这样一个环境的复杂性也会增加。

基本操作系统只是一个开始。我们上面的例子是安装Apache，但是我们也可以安装nginx甚至lighttpd。毕竟，它们也是web服务器。

然后是配置。你希望用户能够通过SSH以root身份登录吗？为了审计或调试的目的，你需要一定级别的日志记录吗？你需要本机身份验证还是集中式身份验证？这份清单是无穷无尽的，如你所见，如果任其发展，可能会成为一个巨大的头痛问题。

这就是SOE的用武之地。它实际上是一个规范，在较宏观的层次上，它可能会规定：

·我们的标准基本操作系统是Ubuntu 18.04 LTS。

·我们的标准web服务器将是Apache 2.4。

·SSH登录已启用，但仅适用于具有SSH密钥的用户而不是root用户。

·所有用户登录都必须记录并存档，以便进行审核。

·除少数本机应急（break glass）账户外，所有账户都必须集中管理（例如，通过LDAP或Active Directory）。

·我们的公司监控解决方案必须集成（例如，必须安装并配置Nagios NCPA代理，以便与Nagios服务器通信）。

·所有系统日志必须发送到公司中央日志管理系统。

·必须对系统应用安全加固。

以上只是一个例子，绝不是完整的；但是，它应该开始让你了解SOE在宏观层次上的样子。随着本章的继续，我们将深入探讨这个问题，并给出更多的例子来建立一个明确的定义。

1.2.2 了解一下要包含哪些内容

在继续之前，我们先稍微更详细地了解一下环境中要包含哪些内容。在上一节中，我们概述了一个非常简单的SOE定义。任何一个好的SOE操作过程的一部分就是拥有一个预定义的操作系统构建，它可以随时被部署。有多种方法可以实现这一点，我们将在本书后面讨论这些，但是，目前，让我们假设已经建立了Ubuntu 18.04 LTS的基本映像，正如前面所建议的那样。

我们在这个标准构建中集成了什么？例如，我们知道我们的登录策略将应用于整个组织，因此，在创建构建时，/etc/ssh/sshd_config必须定制为包含PermitRootLogin no和PasswordAuthentication no。在部署后，再在配置中执行此步骤没有意义，因为这必须在每个部署上执行。很简单，这将是低效的。

对于我们的操作系统映像，还有一些重要的自动化考虑因素。我们知道Ansible本身是通过SSH进行通信的，因此我们知道需要某种凭据（很可能是基于SSH密钥的），以便Ansible在所有部署的服务器上运行。在实际执行任何自动化操作之前，必须手动将Ansible凭据推送到每台计算机是没有什么意义的，因此重要的是要考虑Ansible要使用的身份验证类型（例如，基于密码或SSH密钥的身份验证），并在构建映像此时创建账户和相应的凭据。具体方法取决于你的公司安全标准，但我建议将以下内容作为一种潜在的解决方案：

·在标准映像上创建一个本机账户，以便Ansible进行身份验证。

·授予此账户适当的sudo权限，以确保可以执行所有所需的自动化任务。

·设置此账户的本机口令，或者将从Ansible密钥对中取出的SSH公钥添加到你创建的本机Ansible账户的authorized_keys文件中。

提示

这样做当然会带来一些安全风险。Ansible很可能需要完全访问你服务器上的root，以便它有效地执行你可能要求它执行的所有自动化任务，因此如果凭据被泄露，此Ansible账户可能会成为后门。建议尽可能少的人可以访问你的凭据，并建议你使用诸如AWX或Ansible Tower（我们将在第3章“使用AWX优化基础设施管理”中探讨）之类的工具来管理你的凭据，从而防止人们不适当地获取凭据。你几乎肯定还希望启用对Ansible账户执行的所有活动的审计，并将这些活动记录到某个中央服务器上，以便你可以检查它们是否存在任何可疑活动，并根据需要对它们进行审计。

从用户账户和身份验证开始，还可以考虑Nagios跨平台代理（NCPA）。在我们的示例中，我们知道需要监视所有部署的服务器，因此必须安装NCPA代理，并定义令牌以便它可以与Nagios服务器通信。同样，在部署标准映像之后，再在每台服务器上执行此操作是没有意义的。

但是web服务器呢？制定一个标准是明智的，因为这意味着所有对环境负责的人都能对这项技术感到满意。这使得管理更容易，并且对于自动化特别有利，我们将在下一节中看到。但是，除非你只需要部署运行在Linux上的web服务器，否则这可能不应该作为标准构建的一部分包含在内。

作为一个合理的原则，标准构建应该尽可能简单和轻量级。当额外的服务都是多余的时，在服务器上面运行它们，占用内存和CPU周期是没有意义的。同样，拥有未配置的服务会增加任何潜在攻击者的攻击面，因此出于安全原因，建议将其排除在外。

简言之，标准构建应该只包含将对部署的每个服务器都通用的配置和/或服务。这种方法有时被称为刚刚够用操作系统（Just enough Operating System）或简称为JeOS，它是SOE的最佳起点。

在了解了SOE的基本原理之后，我们将在下一节中更详细地了解SOE给你的企业带来的好处。

1.3 探索SOE的好处

到目前为止，你应该对什么是SOE以及它如何为Linux环境带来规模经济和更高的效率有所了解。现在，让我们在此基础上更详细地看一个标准化重要性的例子。

1.3.1 在Linux环境中SOE的好处示例

说Linux环境中有共同点，也就是说组成SOE的服务器都共享一些属性和特性。例如，它们可能都是基于Ubuntu Linux构建的，或者它们都用Apache作为其web服务器。

我们可以用一个例子来探讨这个概念。假设在负载均衡器后面有10台Linux web服务器，它们都提供简单的静态内容。一切正常，但随后必须进行配置更改。也许这是为了更改每个web服务器的文档根目录，使其指向另一个团队已部署完成的新代码版本。

作为负责人，你知道，由于整个解决方案是负载均衡的，所以所有服务器都应该提供相同的内容。因此，每台服务器都需要进行配置更改。这意味着，如果你手工来做的话，你需要改变10个配置。

当然，你可以手工完成这项工作，但这将是一项乏味的工作，对于熟练的Linux管理员来说，这肯定不是最佳的时间利用方式。它也很容易出错——在10台服务器中的一台上可能会出现打字错误，但不会被发现。或者管理员可能会被其他地方的事情中断，最后只有服务器配置的一部分发生了更改。

更好的解决方案是编写一个脚本来进行更改。这正是自动化的基础，几乎可以肯定的是，在10台服务器上运行一次单个脚本要比在10台服务器上手动进行相同的更改更好地利用时间。它不仅效率更高，而且如果在一个月内需要进行相同的更改，那么只需稍加调整就可以重用脚本。

现在，让我们把计划打乱。如果由于未知的原因，有人在CentOS 7上使用Apache构建了五个web服务器，而在Ubuntu 18.04 LTS上使用nginx构建了另外五个服务器，会怎么样？最终的结果是相同的，毕竟，在一个基本的水平，它们都是网络服务器。但是，如果要在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版本的内容（如果存在）。

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:

# sed -i 's!DocumentRoot.*!DocumentRoot /var/www/newapp!g'

/etc/httpd/conf.d/webservice.conf

# systemctl reload httpd.service

根本不需要环境检测，只需两个简单的shell命令。这可能是一个非常简单的自动化脚本的基础，可以依次在10台服务器上运行，也可以通过SSH远程运行。不管是哪种方式，我们的自动化任务现在都非常简单，并且显示了通用性的重要性。重要的是，SOE在本质上提供了这种通用性。缺乏通用性不仅使自动化变得困难，而且还会妨碍测试，常常会扭曲测试结果，因为如果环境不同，测试结果可能不具有代表性。

在本章的下一节中，我们将在这些知识的基础上演示SOE如何为软件测试过程带来好处。

1.3.2 SOE对软件测试的好处

我在许多环境中看到的一个常见问题是，一个新的软件部署在一个隔离的预生产环境中成功地进行了测试，但在发布到生产环境中时却不能正常工作。通常，这个问题可以归结到生产环境和预生产环境之间的根本区别，因此很明显，要使测试有效，两个环境必须尽可能相似。

事实上，像Docker这样的容器化平台要解决的问题之一就是这个问题，因此可移植性是容器环境的一个核心特性。部署在Docker上的代码构建在容器映像之上，简单地说，就是一个精简的操作系统映像（还记得JeOS吗？）。实际上，这是一个非常小的SOE，只是在容器中运行，而不是在裸机服务器或虚拟机上运行。然而，值得考虑的是，如果通过环境标准化实现的可移植性是容器技术的一个关键特性，那么我们不应该尝试在不考虑基础设施的情况下全面实现这一点。

毕竟，如果生产服务器的配置与预生产服务器不同，那么测试的有效性如何？如果预生产环境是在CentOS 7.6上构建的，但是生产环境是落后于它的CentOS 7.4，那么你真的能确保在一个环境中成功的测试结果将保证在另一个环境中成功吗？从理论上讲，它应该可以工作，但由于环境之间的软件和库版本存在根本性差异，这永远无法得到保证。这甚至是在我们考虑配置文件和安装的软件之间可能存在的差异之前需要考虑的。

因此，如果所有的环境都按照相同的标准构建，那么从理论上讲，它们都应该是相同的，那么SOE在这方面可以提供帮助。你们中那些目光敏锐的人会注意到“应该”（should）这个词在前一句中的用法，这是有充分理由的。SOE在定义解决测试失败的方案方面向前迈出了一大步，但它们并不是全部。

一个环境只有在没有人修改它的情况下才是标准的，如果所有用户都有管理员级别的权限，那么很容易有人（善意的或其他的）登录并进行更改，这意味着环境偏离了标准。

这个问题的答案是，自动化，SOE不仅仅是促进和实现自动化，它们还依赖于自动化来保持最初要求的标准化水平。两者直接相互支持，理想情况下应该是不可分割的伙伴：SOE是环境本身的定义，自动化提供标准的实现、执行和审计。实际上，这正是本书的前提，即环境应该尽可能地标准化，并且应该让尽可能多的更改自动化。

本书的重点将放在这个等式的自动化方面，因为除了坚持本章概述的原则之外，所采用的标准对于每个环境都是独特的，本书的目标不是在微观级别上确定它们。以我们前面的示例为例，Apache和nginx都有它们的优点，适合一个用例的可能不适合另一个用例。

操作系统也是如此，一些机构可能依赖Red Hat Enterprise Linux提供的支持软件包，而其他机构则不需要支持软件包，但需要Fedora提供的前沿技术。定义一个标准没有对错之分，只要它满足它所支持的服务的需求。到目前为止，我们非常关注通用性和标准；然而，在需要替代解决方案的情况下，总会有一些边缘案例。在下一节中，我们将确定如何知道何时应该偏离标准。

...

要从Red Hat的角度了解更多关于SOE的信息，请参阅本文：https://servicesblog.redhat.com/ ... pts-and-structures/。