下载掌阅APP，畅读海量书库
立即打开
没有两个企业环境是完全相同的。一些企业仍然严重依赖于裸机服务器，而另一些企业现在依赖于（私有或公共）虚拟化或云提供商。了解哪些环境对你可用是决策过程的关键部分。
让我们探讨各种环境以及每个环境的相关构建策略。
裸机环境无疑是所有企业环境中的先行者。在整个21世纪的虚拟化革命和云技术革命之前，构建环境的唯一方法是使用裸机。
如今，在裸机上运行的环境并不常见，但是在物理硬件上运行某些关键组件的环境很常见，尤其是需要某些物理硬件协助的数据库或计算任务（例如，GPU加速或硬件随机数生成器）。
使用裸机构建服务器时，适用于大多数环境的有两种基本方法。第一种方法是使用光盘介质或者USB驱动器手动构建服务器。这是一个缓慢的交互式过程，不可大规模重复，因此不建议将其用于所有环境，它只适用于包含少量物理服务器的环境，因为在这些环境中，对构建新机器的要求很低，而且很少发生。
另一个最可行的方法是使用 预执行环境（Pre-eXecution Environment，PXE） 在网络上引导物理服务器，以可重复的、一致的方式进行大规模构建，我们在本书中一直提倡这种方法。这涉及从网络服务器加载一个微小的引导环境，然后使用它加载Linux内核和相关数据。用这种方式，可以在不需要任何形式的物理介质的情况下启动安装环境。一旦环境启动，我们将使用无人值守的安装方法来在没有用户干预的情况下完成整个安装。
我们将在本书后面详细介绍这些方法，以及在构建服务器后用于配置服务器的可重复技术。这里只需简单地说明一下，对于在企业中构建物理Linux服务器，PXE引导加上无人值守的安装是最容易实现自动化并产生可重复结果的途径。
传统的虚拟化环境早于云环境，也就是说，它们是运行操作系统的简单的虚拟机管理程序。像VMware这样的商业化例子是很常见的，还有它们的开源对应产品，比如Xen和KVM（以及基于它们构建的框架，比如oVirt）。
由于这些技术最初是为了补充传统的物理环境而构建的，因此它们为构建企业Linux环境提供了几种选择。例如，这些平台中的大多数都支持与裸机对应的相同的网络引导功能，因此我们实际上可以假装它们是裸机，对其继续使用网络引导方法。
然而，虚拟化环境带来了一些在物理环境中很难实现的东西（比如模板），因为运行虚拟机的裸机设备之间的硬件配置不同。模板化虚拟机只是预配置虚拟机的可部署快照。因此，你可以为企业构建完美的CentOS 7映像，集成监控平台，执行所有所需的安全加固，然后使用虚拟化平台本身内置的工具，将其转换为模板。以下是作者实验室环境中CentOS 7模板如图4-1所示。
图 4-1
这些模板中的每一个都是一个完全配置的CentOS 7基本映像，可以随时部署，所有预部署工作（如删除SSH主机密钥）都已完成。因此，管理员需要选择适当的模板，然后单击New VM按钮，在RHV以外的平台上，这个过程将是类似的，因为大多数主流虚拟化解决方案都以某种形式提供此功能。
注意，为了保持示例的易操作性，使用GUI作为创建新VM的主要过程。几乎所有的虚拟化和云平台都有API、命令行接口，甚至可以用来部署虚拟机的Ansible模块，在企业环境中，这些模块的可扩展性要远远好于GUI本身。考虑到可用环境的多样性，这留作练习。
这本身就是一个相当简单的过程，但需要小心。例如，现在几乎所有的Linux服务器都启用了SSH，并且每台服务器上的SSH守护进程都有一个唯一的主机标识密钥，用于防止中间人攻击。如果对预配置的操作系统进行模板化，还将对这些密钥进行模板化，这意味着在整个环境中可能存在重复的密钥。这大大降低了安全性。因此，在将虚拟机转换为模板之前，执行几个步骤来准备虚拟机是非常重要的，其中一个常见的步骤是删除SSH主机密钥。
使用PXE方法创建的服务器不会遇到这个问题，因为它们都是从头开始安装的，因此既没有要清理的历史日志条目，也没有重复的SSH密钥。
在第5章中，我们将详细介绍如何创建适用于使用Ansible模板的虚拟机模板。
尽管PXE引导和模板部署方法对虚拟化环境都同样有效，但大多数人发现模板化途径更高效、更易于管理，因此，我也主张使用它（例如，大多数PXE引导环境需要知道物理层上使用的网络接口的MAC地址）或正在部署的虚拟服务器（在模板部署中，这些不是必要的步骤）。
最新的企业Linux架构（当然容器除外，这完全是另一个话题）是云供应环境。这可能是通过公有云（public cloud）解决方案实现的，比如 Amazon Web Services（AWS） 、 Microsoft Azure、Google Cloud Platform（GCP） 。它同样可以通过一个内部解决方案来实现，比如OpenStack项目的一个变体或一个专有平台。
这些云环境从根本上改变了企业中Linux机器的生命周期。在裸机或传统的虚拟化架构上，Linux机器在发生故障时会得到维护、升级和修复，而云架构建立在这样的前提上：每台机器或多或少都是可牺牲的，如果它发生故障，只需在它的位置部署一台新的机器。
因此，PXE部署方法甚至不可能在这样的环境中实现，而只能依赖于预先构建的操作系统映像。这些基本上只是由第三方供应商创建或由企业准备的模板。
无论是与商业提供商合作，还是构建内部OpenStack体系结构，你都可以找到可用操作系统映像的目录供你选择。一般来说，云提供商自己提供的服务是值得信赖的，但是根据安全需求，你可能会发现外部第三方提供的服务也是合适的。
例如，图4-2是OpenStack可用的推荐操作系统映像。
正如你从目录中所看到的，这里显示了大多数主要的Linux发行版，为你节省了构建基本操作系统本身的任务。AWS也是如此，如图4-3所示。
简言之，如果使用的是云环境，那么你将被宠坏，无法选择从基本操作系统映像中开始。即便如此，这种选择也不太可能满足所有企业。例如，使用预构建的、云就绪的映像并不能否定对企业安全标准、监控或日志转发代理集成等方面的要求，以及对企业非常重要的其他许多方面的要求。在我们继续之前，值得注意的是，你当然可以为你选择的云平台创建自己的映像。不过，为了提高效率，如果有人已经为你完成了这一步，为什么还要重新发明轮子呢？
尽管大多数现成的操作系统映像都是可信的，但在选择新映像时应始终保持谨慎，特别是如果它是由你不熟悉的作者创建的。我们无法确定映像包含哪些内容，在选择要处理的映像时，你应该始终进行尽职调查。
图 4-2
图 4-3
假设你选择使用预先制作好的云就绪映像，安装后的配置工作都可以由Ansible轻松处理。事实上，在云平台上所需的步骤与为传统虚拟化平台构建模板所需的步骤几乎相同，本书稍后将再次详细介绍此过程。
Docker部署是我们在Linux环境中讨论的一个特例。实际上，它们与云环境有很多共同点，Docker映像是基于预先存在的最小OS映像构建的，并且通常使用本机Docker工具链构建，尽管使用Ansible的自动化是完全可能的。
由于Docker是一个特例，因此我们在本书中不重点讨论，不过需要注意的是，Docker作为Linux在企业中的一个新成员，它实际上是围绕我们在本书中已经考虑过的许多原则而设计的。让我们简要地研究一下用于创建官方nginx容器的Dockerfile。
对于那些不熟悉Docker的人来说，Dockerfile就是一个纯文本文件，其中包含构建用于部署的容器映像所需的所有指令和命令。
在编写本书时，此文件包含以下内容：
虽然不是基于Ansible，但我们可以在前面的代码块中看到以下内容：
1.靠近开头的FROM行定义了一个最小的Ubuntu基映像，在该映像上执行其余的配置，这可以被认为是我们已经针对其他平台讨论的SOE Linux映像。
2.RUN命令执行安装nginx软件包并采取必需的步骤执行一些内务处理，以保持映像整洁和最小化（减少空间需求和混乱）。
代码继续如下：
继续分析这个文件，我们可以看到以下内容：
1.VOLUME行定义了主机文件系统中哪些目录可以挂载在容器内。
2.WORKDIR指令告诉Docker在哪个目录运行它后面的CMD，我们可以把它看作一个引导时配置。
3.CMD行定义了容器启动时要运行的命令，这是在一个完整的Linux系统映像中定义哪些服务将在引导时启动的过程的缩影。
4.EXPOSE行定义容器应该向网络公开哪些端口。这可能有点像防火墙，允许某些端口通过。
简言之，构建Docker容器的本机过程与我们为企业Linux环境定义的构建过程非常一致，因此，我们可以放心地继续这个过程。考虑到这一点，我们现在将探索确保构建尽可能整洁和高效的过程。