下载掌阅APP，畅读海量书库
立即打开
如前所述，了解Linux环境的基本原理对于制定部署方法至关重要。尽管构建过程本身（尤其是传统的虚拟机管理程序和云环境）之间存在一些相似之处，但是了解它们有哪些差异可以让你对如何在整个企业中部署Linux做出明智的决定。
一旦你选择了最适合环境的方法体系，就必须考虑一些原则，以确保流程得到优化和高效（再次强调，这些是企业Linux部署的代名词）。我们将在这里介绍这些内容，以便在本书的其余部分继续进行真正深入的实际工作。让我们先看看构建中对简单性的需求。
让我们从前面讨论的SOE对Linux构建过程的重要性的一些实际应用开始。无论选择什么路线，也不管你的环境是什么样子，都应该保持你的构建标准尽可能简单和简洁。
没有两个完全相同的企业环境，因此每个企业的构建需求肯定是不同的。尽管如此，这里给出了一组常见的示例需求：
·监控代理
·日志转发配置
·安全加固
·核心企业软件需求
·时间同步的NTP配置
此列表只是一个开始，每个企业都会有所不同，但它会让你对构建过程中要用到的东西有一个概念。不过，让我们开始看看构建过程中的一些边缘案例。公平地说，每台Linux服务器的构建都会考虑到一个用途，因此，它将运行某种形式的应用程序栈。
同样，应用程序栈在企业之间肯定会有所不同，但通常需要的应用程序类型示例如下：
·Web服务器（如Apache或nginx）
·运行Java工作负载的OpenJDK环境
·MariaDB数据库服务器
·PostgreSQL数据库服务器
·NFS文件共享工具和内核扩展
现在，在标准化过程中，当最初定义SOE时，你可能已经竭尽全力指定了OpenJDK 8和MariaDB 10.1的用途（仅作为示例）。这是否意味着在构建过程中包含这些应用程序呢？
答案几乎总是否定的。很简单，添加这些应用程序会增加构建的复杂性以及增加安装后的配置和调试工作。它也会降低安全性，而且不久之后会有更多的问题。
假设我们在MariaDB 10.1上进行了标准化，并将其包含在基本操作系统映像中（因此部署的每台Linux机器都包含该映像），我们知道只有一部分正在运行的机器会真正使用它。
不将MariaDB包含在基本映像中有如下几个原因：
·仅安装MariaDB 10.1的服务器组件大约需要120 MB的空间，这取决于你的操作系统和打包，也依赖软件包。尽管现在存储空间便宜且充足，但如果在整个环境中部署100台服务器（实际上对于大多数企业来说，这只是一个很小的数字），那么对于你不需要的软件包来说，大约需要11.7 GB的空间。实际的数字会高得多，因为还会有依赖软件包需要安装。
·这也可能会对备份和备份所需的存储产生连锁反应，如果你在企业中使用虚拟机快照，甚至会对任何虚拟机快照都产生连锁反应。
·如果一个应用程序需要MariaDB 10.3（或者实际上，企业决定将其标准更新为10.3），那么在安装10.3之前，需要升级映像或者卸载版本10.1。当一个最小的Linux映像可能刚收到一个更新的MariaDB工作负载时，这带来了不必要的复杂性。
·你需要确保在不需要时关闭MariaDB和防火墙，以防止任何误用，这是一个额外的审计和强制执行要求，它们在许多没有使用MariaDB的服务器上也是不必要的。
还有其他安全方面的考虑，但这里的关键信息是它浪费了资源和时间。当然，这不仅仅适用于MariaDB 10.1，这只是一个示例，但它表明，作为一项规则，应用程序工作负载不应包含在基本操作系统定义中。现在让我们更详细地了解一下构建的安全需求。
我们已经谈到了安全性，以及不要安装或运行不必要的软件包。任何运行中的服务都为入侵者提供了潜在的攻击面，同时，希望在企业网络内永远不会有一个攻击面，但以尽可能安全的方式构建环境仍然是一个很好的实践。对于配置了默认口令的服务来说尤其如此（在某些情况下，根本没有配置口令，不过现在这种情况已经很少了）。
这些原则也适用于定义构建本身。例如，不要创建具有弱静态口令的构建。理想情况下，每个构建都应该配置为从外部源获取甚至初始的凭据，尽管有很多方法可以实现这一点，但是如果cloud-init对你是一个新概念，我们鼓励你查阅一下它的相关资料。有些情况下，特别是在传统环境中，可能需要一些初始凭据来允许访问新构建的服务器，但是重用弱口令是危险的，并且新构建的服务器可能会在配置完成之前被拦截，并在其上植入某种恶意软件。
简言之，下面的列表提供了一些关于确保安全构建的合理指导：
·不要安装不需要的应用程序或服务。
·确保默认情况下禁用对所有构建都通用但需要部署后配置的服务。
·如果可能的话，即使在初始访问和配置时也不要重复使用口令。
·请尽可能早地在映像或服务器的构建过程中应用企业安全策略（如果可能），但如果没有，请在安装后尽快应用。
这些原则既简单又基本，必须坚持。希望构建在应用这些原则的情况下不会出现严重状况，但如果发生了这种状况，它们可能会停止或充分阻止对你的基础结构的入侵或攻击。当然，这是一个值得单独写一本书的主题，但希望这些指南，以及第13章将为你指明正确的方向。现在让我们简单地看看如何确保构建过程是高效的。
高效的过程在很大程度上需要自动化的支持，因为这确保了最少的人力参与和一致的、可重复的最终结果。标准化也支持这一点，因为这意味着大部分决策过程已经完成，因此所有相关人员都确切地知道他们在做什么，以及应该如何做。
简言之，坚持本书中概述的这些原则，你的构建过程将是高效的。某种程度的手动干预是不可避免的，即使它涉及选择一个唯一的主机名（尽管这可以是自动的），或者用户首先请求Linux服务器的过程。但是，从这里开始，你希望尽可能实现自动化和标准化。下面我们将看看构建过程中一致性的重要性。