安装设计

了解安装过程的工作原理

可以构建一个防弹系统。构建过程完成后，您将会有一个包含安装和运行所需全部组件的工件。拥有一个工件可以让我们做一些假设和保证。

  • 位元在每个主机都相同，但角色不同，它们只是使用不同的组件子集。
  • 升级是不可再分的，不存在奇数组件不兼容的问题。

设计目标

了解您正在使用的约束很重要。以下是 DC/OS 的设计目标：

  • 最大程度降低对主机 OS 的依赖性。这让 DC/OS 能够在尽可能多的环境中运行。
  • 主机 OS 应完全可自定义。每个人都有一套不同的工具在使用。这些工具工作时应没有任何变化或移植。谈到硬件特定功能（如内核模块）时，这一点尤为重要。
  • 最大程度降低对主机的依赖性。很难编排依赖性主机出现的顺序（管理节点、代理节点）。它们应能按任何顺序出现，并且只在依赖关系确立并提供给群集时才开始工作。
  • 应需要最少的外部基础架构。外部基础架构很少存在，例如 PXE 启动映像和 NFS 存储。
  • 应该可以选择用于部署的方法。如果您对现有系统感到满意，则无需了解新系统。集成应具有清晰的接口，并尽可能简单。
  • 可在 DC/OS 和现有系统之间轻松集成，例如配置管理工具和 CloudFormation。集成接口必须简单且记录在案。
  • 将所有依赖关系和库捆绑成单个工件。正常生命周期流程将会升级或降级软件库以及完全在 DC/OS 之外的依赖关系。如果不依靠这些，系统将变得不那么脆弱，而且将更稳定。
  • 必要时，允许用户修改实时系统中的代码和配置。虽然这是一种反面模式，但它有助于在关键时刻将基础架构保持在高水平上。
  • 安装必须尽可能接近 100% 起作用。即使在运行 1000 个主机群集时有 1% 的故障率也会导致 10 个需要人为干预的故障情况。
  • 升级和升级的退回在主机级别都必须不可再分。
  • 可以审核群集的状态。当运行大型群集时，很容易会遇到难以依赖单个主机状态的情况。

我们选择 tarball 作为封装格式，因为它们在任何地方都有用。tarball 是一种可压缩文件格式，将多个文件捆绑到一个档案中。有许多常见的封装格式（deb、rpm、wheel、gem、jar 等），但它们都只是 tarball。遗憾的是，几乎所有的常见格式都是围绕单一分布或语言构建的，使得它们难以跨各种不同的分布和语言使用。一些功能（如安装前和安装后脚本）非常方便，可帮助推动系统进入正确的“状态”。这不存在可预测的结果和/或未经测试的极端情况这种可能性。因此，我们简化了流程，并使包安装成为一个步骤：tarball 提取。不需要执行任意代码，而且保证了可重复性。

DC/OS 中的所有组件均内置在一个提取至主机系统上 的 tarball 中。在这个目录内，它看起来很像 /usr/local。每个组件都在自己的包目录中。重要文件链接至 bin 和 lib 等重要目录。

必须组装主工件。DC/OS 构建由不断变化的组件列表组成，因此构建工具看起来像自己的小包管理器。每个组件都必须从来源构建，以可重复的方式配置，然后添加到主工件中。

既然有一个所有已构建组件的包来运行 DC/OS，因此必须先配置每个安装，然后才能将其置于主机上。如果保持此配置小且长期不变，便能确保群集中的每个主机都会以同样的方式行事。

配置工具将所有组件构建成一个包，其含有可让群集运行的所有内容。您将从 DNS 配置和 bootstrap 信息等简短详情列表中选择。这将被添加到您构建的单个 tarball 上。然后，您将拥有针对硬件自定义的软件包，并可再三重复性地创建任何大小的群集。

很难编排安装的推出，尤其是当您需要按特定顺序执行某些操作时。为了尽可能简单地保留所有内容，在主机级别，DC/OS 对群集状态未做任何假设。您可以安装代理节点，然后安装管理节点，或者同时安装这两者！

一旦您的包被构建，便可通过运行每个主机上的 dcos_install.sh 来开始。此脚本仅做三件事：

  • 将包提取到 /opt/mesosphere 中。
  • 使用 启动安装。
一旦 ZooKeeper 群集在管理节点上达到法定数量且 Mesos 出现，每个代理节点都将加入群集。我们已将步骤保持至最低限度，以确保其尽可能可靠。 ## 权衡 显然，还有其他方式可以对其进行构建。让我们看看一些常见问题以及当前决定的原因。 ## 不可改变的配置 每个群集的配置在开始时生成，并且不可改变。这使得我们可以保证在安装后每个主机上的配置正确。请记住，您将对数千个节点进行此操作。这些有关配置的保证减少了运行 DC/OS 所需的文档数量，使得更易于支持。 如果配置不可改变，主机将没有机会更新或更改其配置的一部分。我们遇到的许多生产问题均通过此设计决策进行了改善。 ### 我应该绑定什么 IP？ 决定可访问网络和 Mesos 管理节点的 IP 和网络接口是非常重要的事。以下是我们无法作出默认假设的环境的示例：
  • 在诸如 AWS 等水平分割环境中，主机名可能解析为外部 IP 地址，而不是内部 IP 地址。
  • 在没有 DNS 的环境中，您必须告诉 DC/OS 它具有哪些 IP 地址。
  • 在具有多个接口的环境中，我们无法自动选择要使用的接口。
  • 并非所有机器都有可解析的主机名，因此您无法进行反向查找。
因为这些约束，因此默认值是固定的但却复杂。要尽可能使其可配置，我们有一个可以写入的脚本，以便返回我们在每个主机上应该绑定到的 IP 地址。文档中有多个示例解释如何针对不同环境编写 ip-detect 脚本，应涵盖大多数使用情形。对于默认情况下不起作用的环境，您将能够编写自己的 ip-detect，并将其与您的配置进行整合。配置的最重要部分是 ，这是群集能够成功出现的唯一方式。 ### 单个包与多个包、每个提供商的包（RPM、DEB 等） 不是将所有包都捆绑到一个镜像中，我们采取了最常用的默认路线并全部单独安装这些包。这可能会马上产生几个问题：
  • 分发之间的移动需要移植和检测各个包。
  • 包安装的故障率不为零。我们在尝试安装包时发现故障率为 10-20%。这会阻止群集成功启动，使其更难操作。
  • 输送多个包比提供一个 tarball 要困难得多。确保多个包稳健会产生经常费用。
  • 升级必须不可再分。在多个包之间要保证这一点更加困难。

我们可以将 DC/OS 封装为大量容器（或具有多个进程的单个容器）。这种方法结合了多个包的缺点和 Docker 守护程序的不稳定性。我们发现 Docker 守护程序会定期崩溃；虽然这对于某些应用是可接受的，但这不是您想从基础架构中获得的。

由于难以维护 bash，因此我们尽可能简化了安装方法。构建的“镜像”可放置在运行主机之上，并且独立运行。提取是进行此项安装所需的全部操作。这是一个很小的简单 bash 脚本，可在任何地方工作，并可与其他工具轻松集成。暴露的整个表面积最小，且未给予对内部的访问权限，如果更改的话，会使您的群集不受支持并使保修无效。

可以制作已配置的整个主机镜像，而不是顶部的 tarball。以下为这不是唯一安装方法的原因：

  • 不计其数的分发更新。RHEL 每次发布包更新时，我们都需要对其进行测试、捆绑和分发。这对于 CorEos 来说变得更加困难，因为我们实际上最终会放弃该项目。
  • 您想配置基本 OS。存在必须对主机运用的安全策略和配置。
主机镜像是分发和安装 DC/OS 的绝佳方式。使用 bash 安装方法，为您的基础架构创建新的主机镜像就跟把它与 Puppet 等工具集成一样容易。

DC/OS 包括大量具有配置选项的组件。我们花了很长时间把正确的组件拼凑起来。这些保证能够在规模生产中提供最佳运行。如果我们暴露这些选项，则会增加运行 DC/OS 群集所需的知识量。