精通 KVM 虚拟化（四）

原文：zh.annas-archive.org/md5/937685F0CEE189D5B83741D8ADA1BFEE

译者：飞龙

协议：CC BY-NC-SA 4.0

第十一章：Ansible 和编排自动化

Ansible 已经成为当今开源社区的事实标准，因为它提供了很多功能，同时对您和您的基础设施要求很少。在基于内核的虚拟机（KVM）中使用 Ansible 也是很有意义的，特别是当您考虑到更大的环境。无论您只是想要简单地配置 KVM 主机（安装 libvirt 和相关软件），还是想要统一配置主机上的 KVM 网络 - Ansible 对于这两者都非常有价值。例如，在本章中，我们将使用 Ansible 来部署托管在 KVM 虚拟机内的虚拟机和多层应用程序，这在更大的环境中是非常常见的用例。然后，我们将转向更加严谨的主题，结合 Ansible 和 cloud-init，因为它们在应用时间轴和完成方式上有所不同。Cloud-init 是一种理想的自动化初始虚拟机配置的方式（主机名、网络和 SSH 密钥）。然后，我们通常转向 Ansible，以便在初始配置后执行额外的编排 - 添加软件包，对系统进行更大的更改等等。让我们看看如何在 KVM 中使用 Ansible 和 cloud-init。

在这一章中，我们将涵盖以下主题：

• 理解 Ansible

• 使用kvm_libvirt模块来配置虚拟机

• 使用 Ansible 和 cloud-init 进行自动化和编排

• 在 KVM 虚拟机上编排多层应用程序部署

• 通过示例学习，包括如何在 KVM 中使用 Ansible 的各种示例

让我们开始吧！

理解 Ansible

一个称职管理员的主要职责之一是尽可能自动化自己的工作。有一句话说，你必须手动做一次所有的事情。如果你必须再做一次，你可能会对此感到恼火，第三次你必须做的时候，你会自动化这个过程。当我们谈论自动化时，它可能意味着很多不同的东西。

让我们通过一个例子来解释这个问题和解决方案，因为这是描述问题和解决方案最方便的方式。假设你在一家公司工作，需要部署 50 台 Web 服务器来托管一个 Web 应用程序，具有标准配置。标准配置包括需要安装的软件包、需要配置的服务和网络设置、需要配置的防火墙规则，以及需要从网络共享复制到虚拟机内部的本地磁盘上的文件，以便我们可以通过 Web 服务器提供这些文件。你将如何实现这一点？

有三种基本的方法：

• 手动做所有事情。这将花费很多时间，也会有很多机会出错，因为毕竟我们是人类，会犯错误（故意的）。

• 尝试通过部署 50 台虚拟机来自动化流程，然后将整个配置方面放入脚本中，这可以成为自动安装过程的一部分（例如，kickstart）。

• 尝试通过部署一个包含所有组件的单个虚拟机模板来自动化流程。这意味着我们只需要从虚拟机模板部署这 50 台虚拟机，并进行一些定制，以确保我们的虚拟机准备好使用。

有不同类型的自动化可用。纯脚本编写是其中之一，它涉及将需要多次运行的所有内容创建成脚本。做了多年工作的管理员通常都有一堆有用的脚本。优秀的管理员通常至少懂一种编程语言，即使他们不愿承认，因为作为管理员意味着在别人弄坏东西后需要修复，有时需要相当多的编程。

因此，如果你考虑通过脚本进行自动化，我们完全同意这是可行的。但问题在于，你将花费多少时间来覆盖脚本的每一个方面，以确保脚本始终正常工作。此外，如果脚本出现问题，你将不得不进行大量的手动劳动来修复它，而没有任何真正的方法在之前不成功的配置之上进行额外的修正。

这就是基于过程的工具如 Ansible 派上用场的地方。Ansible 生成模块，将其推送到端点（在我们的示例中是虚拟机），将我们的对象带到期望的状态。如果你来自 Microsoft PowerShell 世界，是的，Ansible 和 PowerShell 期望状态配置（DSC）基本上是在尝试做同样的事情。它们只是以不同的方式去做。所以，让我们讨论这些不同的自动化过程，看看 Ansible 在其中的定位。

自动化方法

总的来说，所有这些都适用于管理系统及其部件，安装应用程序，并且通常照顾已安装系统内部的事务。这可以被认为是一种旧的管理方法，因为它通常处理的是服务，而不是服务器。与此同时，这种自动化明显地专注于单个服务器或少量服务器，因为它的扩展性不强。如果我们需要处理多个服务器，使用常规脚本会带来新的问题。因为脚本更难以扩展到多个服务器上（而在 Ansible 中很容易），我们需要考虑很多额外的变量（不同的 SSH 密钥、主机名和 IP 地址）。

如果一个脚本不够，那么我们就必须使用多个脚本，这就产生了一个新问题，即脚本管理。想想看 - 当我们需要在脚本中做一些更改时会发生什么？我们如何确保所有服务器上的所有实例都使用相同的版本，特别是如果服务器 IP 地址不是顺序的呢？因此，总之，虽然旧的和经过测试，这种自动化方式有严重的缺点。

在 DevOps 社区中，还有另一种自动化方式正在受到关注 - 大写字母 A 的自动化。这是一种在不同机器上自动化系统操作的方式 - 甚至在不同操作系统上也是如此。有一些自动化系统可以实现这一点，它们基本上可以分为两组：使用代理的系统和无代理系统。

使用代理的系统

使用代理的系统更常见，因为它们比无代理系统有一些优势。首要的优势是它们能够跟踪不仅需要进行的更改，还能跟踪用户对系统所做的更改。这种更改跟踪意味着我们可以跟踪系统上发生的事情并采取适当的行动。

几乎所有的工作方式都是一样的。一个小应用程序 - 称为代理 - 安装在我们需要监视的系统上。应用程序安装完成后，它连接或允许来自中央服务器的连接，中央服务器处理自动化的所有事务。由于你正在阅读这篇文章，你可能对这样的系统很熟悉。这样的系统有很多，很有可能你已经遇到过其中的一个。为了理解这个原理，看一下下面的图表：

图 11.1 - 管理平台需要代理连接到需要编排和自动化的对象

在这些系统中，代理有双重目的。它们在这里运行需要在本地运行的任何东西，并不断监视系统的变化。这种变化跟踪能力可以通过不同的方式实现，但结果是相似的 - 中央系统将知道发生了什么变化以及以何种方式发生了变化。变化跟踪在部署中是一件重要的事情，因为它能够实时进行合规性检查，并防止由未经授权的变化引起的许多问题。

无代理系统

无代理系统的行为不同。在需要管理的系统上没有安装任何东西；相反，中央服务器（或服务器）使用某种命令和控制通道执行所有操作。在 Windows 上，这可能是PowerShell，WinRM或类似的东西，而在 Linux 上，通常是SSH或其他远程执行框架。中央服务器创建一个任务，然后通过远程通道执行，通常以脚本的形式在目标系统上复制并启动。这就是这个原则的样子：

图 11.2 - 管理平台不需要代理连接需要编排和自动化的对象

无论其类型如何，这些系统通常被称为自动化或配置管理系统，尽管这两者是两个事实上的标准，但在现实中它们被不加区分地使用。在撰写本文时，最受欢迎的两个是 Puppet 和 Ansible，尽管还有其他的（Chef、SaltStack 等）。

在本章中，我们将介绍 Ansible，因为它易于学习，无代理，并且在互联网上有大量用户。

Ansible 介绍

Ansible 是一个 IT 自动化引擎 - 有些人称其为自动化框架 - 它使管理员能够自动化配置、配置管理和许多系统管理员可能需要完成的日常任务。

关于 Ansible 最简单（也太过简化）的思考方式是，它是一组复杂的脚本，旨在以大规模的方式（无论是在复杂性还是它可以控制的系统数量方面）完成管理任务。Ansible 运行在一个安装了 Ansible 系统所有部分的简单服务器上。它不需要在所控制的机器上安装任何东西。可以说 Ansible 完全无代理，并且为了实现其目标，它使用不同的方式连接到远程系统并向其推送小型脚本。

这也意味着 Ansible 无法检测所控制系统上的变化；完全取决于我们创建的配置脚本来控制如果某些情况不如预期发生时会发生什么。

在做其他事情之前，我们需要定义一些东西 - 我们可以将其视为构建块或模块。Ansible 喜欢称自己为一个根本简单的 IT 引擎，它只有几个使其能够工作的这些构建块。

首先，它有清单 - 定义了某个任务将在哪些主机上执行的主机列表。主机在一个简单的文本文件中定义，可以是一个简单的包含每行一个主机的直接列表，也可以是一个在 Ansible 执行任务时创建的动态清单。我们将在展示它们如何使用时更详细地介绍这些内容。要记住的是，主机在文本文件中定义，没有涉及数据库（尽管可以有），主机可以被分组，这是一个你会广泛使用的功能。

其次，有一个称为play的概念，我们将其定义为 Ansible 在目标主机上运行的一组不同任务。我们通常使用一个 playbook 来启动一个 play，这是 Ansible 层次结构中的另一种对象。

就 playbooks 而言，将它们视为一项政策或一组任务/操作，这些任务/操作需要在特定系统上执行某些操作或达到某种状态。Playbooks 也是文本文件，专门设计为可读性强，由人类创建。Playbooks 用于定义配置或更准确地说是声明配置。它们可以包含以有序方式启动不同任务的步骤。这些步骤称为 plays，因此得名 playbook。Ansible 文档对此有所帮助，将 plays 比作体育比赛中提供的任务清单，并需要进行记录，但同时可能不会被调用。在这里需要理解的重要一点是，我们的 playbooks 可以在其中包含决策逻辑。

Ansible 拼图的第四个重要部分是它的模块。将模块视为在您试图控制的机器上执行的小程序，以实现某些目标。Ansible 软件包中包含了数百个模块，它们可以单独使用或在您的 playbooks 中使用。

模块允许我们完成任务，其中一些模块是严格声明性的。其他模块返回数据，要么作为模块执行的任务的结果，要么作为模块通过称为事实收集的过程从运行中的系统获取的显式数据。这个过程基于一个称为gather_facts的模块。收集关于系统的正确事实是我们开始开发自己的 playbooks 后可以做的最重要的事情之一。

以下架构显示了所有这些部分如何一起工作：

图 11.3 - Ansible 架构 - Python API 和 SSH 连接

在 IT 领域工作的人普遍认为，通过 Ansible 进行管理比通过其他工具更容易，因为它不需要您在设置或 playbook 开发上浪费几天的时间。然而，不要误解：您必须学习如何使用 YAML 语法来广泛使用 Ansible。也就是说，如果您对基于 GUI 的方法感兴趣，您可以考虑购买 Red Hat Ansible Tower。

Ansible Tower 是一个基于 GUI 的实用工具，您可以使用它来管理基于 Ansible 的环境。这最初是一个名为 AWX 的项目，今天仍然非常活跃。但是 AWX 发布的方式与 Ansible Tower 发布的方式有一些关键区别。主要区别在于 Ansible Tower 使用特定的发布版本，而 AWX 采用了更像是 OpenStack 的方法 - 一个项目在快速前进并经常发布新版本。

正如 Red Hat 在www.ansible.com/products/awx-project/faq上明确说明的那样：

“Ansible Tower 是通过选择 AWX 的特定版本、加固以支持长期可维护性，并将其作为 Ansible Tower 产品提供给客户而生产的。”

基本上，AWX 是一个社区支持的项目，而 Red Hat 直接支持 Ansible Tower。以下是来自 Ansible AWX 的屏幕截图，这样您就可以看到 GUI 的样子：

图 11.4 - Ansible AWX GUI for Ansible

还有其他可用于 Ansible 的 GUI，例如 Rundeck、Semaphore 等。但不知何故，AWX 似乎是那些不想为 Ansible Tower 支付额外费用的用户最合乎逻辑的选择。在继续进行常规的 Ansible 部署和使用之前，让我们花点时间来研究 AWX。

部署和使用 AWX

AWX 被宣布为一个开源项目，为开发人员提供对 Ansible Tower 的访问，无需许可证。与几乎所有其他红帽项目一样，这个项目也旨在弥合付费产品和社区驱动项目之间的差距，后者在较小的规模上具有几乎所有所需的功能，但没有为企业客户提供的所有功能。但这并不意味着 AWX 在任何方面都是一个小项目。它构建了 Ansible 的功能，并启用了一个简单的 GUI，帮助您在 Ansible 部署中运行所有内容。

我们这里没有足够的空间来演示它的外观和用途，所以我们只会介绍安装和部署最简单的场景。

谈到 AWX 时，我们需要知道的最重要的地址是github.com/ansible/awx。这是项目所在的地方。最新的信息在这里，在readme.md中，在 GitHub 页面上显示。如果您不熟悉从 GitHub 克隆，不用担心-我们基本上只是从一个特殊的源复制，这将使您只能复制自上次获取文件版本以来发生变化的内容。这意味着为了更新到新版本，您只需要再次使用完全相同的命令克隆一次。

在 GitHub 页面上，有一个直接链接到我们将要遵循的安装说明。请记住，这次部署是从头开始的，因此我们需要再次构建我们的演示机器，并安装所有缺少的东西。

我们需要做的第一件事是获取必要的 AWX 文件。让我们将 GitHub 存储库克隆到我们的本地磁盘上：

图 11.5-Git 克隆 AWX 文件

请注意，我们使用 13.0.0 作为版本号，因为这是撰写时 AWX 的当前版本。

然后，我们需要解决一些依赖关系。显然，AWX 需要 Ansible、Python 和 Git，但除此之外，我们还需要支持 Docker，并且我们需要 GNU Make 来准备一些文件。我们还需要一个环境来运行我们的虚拟机。在本教程中，我们选择了 Docker，因此我们将使用 Docker Compose。

此外，这也是一个好地方提到，我们的机器至少需要 4GB 的 RAM 和 20GB 的空间才能运行 AWX。这与我们习惯使用的低占用空间有所不同，但这是有道理的，因为 AWX 不仅仅是一堆脚本。让我们从安装先决条件开始。

Docker 是我们将安装的第一个软件。我们在这里使用 CentOS 8，因此 Docker 不再是默认软件包的一部分。因此，我们需要添加存储库，然后安装 Docker 引擎。我们将使用-ce软件包，代表 Community Edition。我们还将使用--nobest选项来安装 Docker-如果没有此选项，CentOS 将报告我们缺少一些依赖项：

图 11.6-在 CentOS 8 上部署 docker-ce 软件包

之后，我们需要运行以下命令：

dnf install docker-ce -y --nobest

总体结果应该看起来像这样。请注意，您特定安装的每个软件包的版本可能会有所不同。这是正常的，因为软件包一直在变化：

图 11.7-启动和启用 Docker 服务

然后，我们将使用以下命令安装 Ansible 本身：

dnf install ansible

如果您正在运行完全干净的 CentOS 8 安装，可能需要在可用 Ansible 之前安装epel-release。

接下来是 Python。仅使用dnf命令不会安装 Python，因为我们将不得不提供我们想要的 Python 版本。为此，我们会做这样的事情：

图 11.8-安装 Python；在这种情况下，版本 3.8

之后，我们将使用 pip 安装 Python 的 Docker 组件。只需输入pip3 install docker，您需要的一切都将被安装。

我们还需要安装make包：

图 11.9-部署 GNU Make

现在，是时候进行 Docker Compose 部分了。我们需要运行pip3 install docker-compose命令来安装 Python 部分，以及以下命令来安装 docker-compose：

curl -L https://github.com/docker/compose/releases/download/1.25.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

这个命令将从 GitHub 获取必要的安装文件，并使用必要的输入参数（通过执行uname命令）来启动 docker-compose 的安装过程。

我们知道这是很多依赖关系，但是 AWX 在内部是一个非常复杂的系统。然而，在表面上，事情并不那么复杂。在我们进行最后的安装之前，我们需要验证我们的防火墙是否已停止并且已禁用。我们正在创建一个演示环境，firewalld将阻止容器之间的通信。一旦系统运行起来，我们可以稍后解决这个问题。

一旦一切都运行起来，安装 AWX 就很简单。只需转到awx/installer目录并运行以下命令：

ansible-playbook -i inventory -e docker_registry_password=password install.yml

安装应该需要几分钟。结果应该是一个以以下内容结尾的长列表：

PLAY RECAP *********************************************************************
localhost  : ok=16   changed=8    unreachable=0    failed=0    skipped=86   rescued=0    ignored=0   

这意味着本地 AWX 环境已成功部署。

现在，有趣的部分开始了。AWX 由四个小的 Docker 图像组成。为了使其工作，所有这些图像都需要配置和运行。您可以使用docker ps和docker logs -t awx_task来查看它们。

第一个命令列出了部署的所有图像，以及它们的状态：

图 11.10-检查拉取和启动的 docker 图像

第二个命令向我们显示了awx_task机器正在创建的所有日志。这些是整个系统的主要日志。一段时间后，初始配置将完成：

图 11.11-检查 awx_task 日志

将有大量的日志记录，您将不得不使用Ctrl + C来中断此命令。

在整个过程之后，我们可以将我们的 Web 浏览器指向http://localhost。我们应该会看到一个看起来像这样的屏幕：

图 11.12-AWX 默认登录屏幕

默认用户名是admin，密码是password。成功登录后，我们应该会看到以下 UI：

图 11.13-登录后的初始 AWX 仪表板

这里有很多东西需要学习，所以我们只会简单介绍一下基础知识。基本上，AWX 代表的是 Ansible 的智能 GUI。如果我们快速打开模板（在窗口的左侧）并查看演示模板，我们就可以看到这一点：

图 11.14-在 AWX 中使用演示模板

我们将在本章的下一部分更加熟悉这里看到的内容，当我们部署 Ansible 时。所有这些属性都是 Ansible playbook 的不同部分，包括 playbook 本身、清单、使用的凭据以及使使用 Ansible 变得更容易的其他一些东西。如果我们向下滚动一点，那里应该有三个按钮。按job：

图 11.15 – 通过单击启动按钮，我们可以启动我们的模板作业

这个想法是我们可以创建模板并随时运行它们。运行它们后，运行的结果将出现在作业下（在窗口左侧的第二个项目中找到）：

图 11.16 – 模板作业详情

作业的详细信息基本上是发生了什么，何时发生，以及使用了哪些 Ansible 元素的总结。我们还可以看到我们刚刚运行的 playbook 的实际结果：

图 11.17 – 检查演示作业模板的文本输出

AWX 的真正作用是自动化自动化。它使您能够在使用 Ansible 时更加高效，因为它为 Ansible 使用的不同文件提供了一个更直观的界面。它还使您能够跟踪已完成的工作及其时间，以及结果是什么。所有这些都可以使用 Ansible CLI 实现，但 AWX 在我们控制整个过程的同时节省了大量精力。

当然，因为本章的目标是使用 Ansible，这意味着我们需要部署所有必要的软件包，以便我们可以使用它。因此，让我们继续进行我们的 Ansible 过程的下一个阶段，并部署 Ansible。

部署 Ansible

在所有设计用于编排和系统管理的类似应用程序中，Ansible 可能是最简单的安装。由于它在管理的系统上不需要代理，因此安装仅限于一台机器 - 将运行所有脚本和 playbook 的机器。默认情况下，Ansible 使用 SSH 连接到机器，因此其使用的唯一先决条件是我们的远程系统上有一个正在运行的 SSH 服务器。

除此之外，没有数据库（Ansible 使用文本文件），没有守护程序（Ansible 按需运行），也没有管理 Ansible 本身的必要。由于没有后台运行任何东西，因此可以轻松升级 Ansible - 唯一可能改变的是 playbook 的结构方式，而这可以很容易地修复。Ansible 基于 Python 编程语言，但其结构比标准 Python 程序更简单。配置文件和 playbook 要么是简单的文本文件，要么是 YAML 格式的文本文件，YAML 是用于定义数据结构的文件格式。学习 YAML 超出了本章的范围，因此我们只是假设您了解简单的数据结构。我们将使用的 YAML 文件示例足够简单，几乎不需要解释，但如果需要，我们会提供解释。

安装可以简单地运行以下命令：

yum install ansible 

您可以以 root 用户身份运行此命令，也可以使用以下命令：

apt install ansible 

选择取决于您的发行版（Red Hat/CentOS 或 Ubuntu/Debian）。更多信息可以在 Ansible 网站上找到docs.ansible.com/。

RHEL8 用户首先需要启用包含 Ansible RPM 的存储库。在撰写本文时，可以通过运行以下命令来实现：

sudo subscription-manager repos --enable ansible-2.8-for-rhel-8-x86_64-rpms

运行上述命令后，使用以下代码：

dnf install ansible

这就是安装 Ansible 所需的全部内容。

有一件事可能会让您感到惊讶，那就是安装的大小：它确实如此小（约 20 MB），并且会根据需要安装 Python 依赖项。

安装了 Ansible 的机器也被称为控制节点。它必须安装在 Linux 主机上，因为 Windows 不支持这个角色。Ansible 控制节点可以在虚拟机内运行。

我们控制的机器称为受控节点，默认情况下，它们是通过SSH协议控制的 Linux 系统。有一些模块和插件可以扩展到 Windows 和 macOS 操作系统，以及其他通信渠道。当你开始阅读 Ansible 文档时，你会注意到大多数支持多个架构的模块都有清晰的说明，关于如何在不同的操作系统上完成相同的任务。

我们可以使用/etc/ansible/ansible来配置 Ansible 的设置。这个文件包含了定义默认值的参数，并且本身包含了很多被注释掉的行，但包含了 Ansible 用于工作的所有默认值。除非我们改变了什么，否则这些值就是 Ansible 要使用的值。让我们实际使用 Ansible 来看看所有这些是如何配合在一起的。在我们的场景中，我们将使用 Ansible 来通过其内置模块配置虚拟机。

使用 kvm_libvirt 模块配置虚拟机

一个你可能会或可能不会包括的设置是定义 SSH 如何用于连接 Ansible 将要配置的机器。在我们这样做之前，我们需要花一点时间来谈谈安全和 Ansible。与几乎所有与 Linux（或*nix一般）相关的事物一样，Ansible 不是一个集成的系统，而是依赖于已经存在的不同服务。为了连接到它管理的系统并执行命令，Ansible 依赖于SSH（在 Linux 中）或其他系统，如 Windows 上的WinRM或PowerShell。我们将在这里专注于 Linux，但请记住，关于 Ansible 的相当多的信息是完全与系统无关的。

SSH是一个简单但非常强大的协议，它允许我们通过安全通道传输数据（安全 FTP，SFTP 等）并在远程主机上执行命令（SSH）。Ansible 直接使用 SSH 连接，然后执行命令和传输文件。当然，这意味着为了使 Ansible 工作，SSH 至关重要。

使用SSH连接时需要记住的几件事：

• 第一个是密钥指纹，从 Ansible 控制节点（服务器）看到的。在首次建立连接时，SSH要求用户验证和接受远程系统呈现的密钥。这旨在防止中间人攻击，并且在日常使用中是一个很好的策略。但如果我们处于必须配置新安装系统的位置，所有它们都将要求我们接受它们的密钥。这是耗时且复杂的，一旦我们开始使用 playbooks，就很难做到，所以你可能会开始的第一个 playbook 是禁用密钥检查和登录到机器。当然，这只应该在受控环境中使用，因为这会降低整个 Ansible 系统的安全性。

• 第二件你需要知道的事情是 Ansible 作为一个普通用户运行。话虽如此，也许我们不想以当前用户连接到远程系统。Ansible 通过在单独的计算机或组上设置一个变量来解决这个问题，该变量指示系统将用于连接到这台特定计算机的用户名。连接后，Ansible 允许我们以完全不同的用户身份在远程系统上执行命令。这是一个常用的功能，因为它使我们能够完全重新配置机器并像在控制台上一样更改用户。

• 第三件我们需要记住的事情是密钥 - SSH可以通过交互式身份验证登录，意思是通过密码或使用一次交换的预共享密钥来建立 SSH 会话。还有ssh-agent，它可以用于身份验证会话。

虽然我们可以在清单文件（或特殊的密钥库）中使用固定密码，但这是一个坏主意。幸运的是，Ansible 使我们能够脚本化许多事情，包括将密钥复制到远程系统。这意味着我们将有一些 playbooks 来自动部署新系统，并且这些将使我们能够控制它们进行进一步的配置。

总之，部署系统的 Ansible 步骤可能会像这样开始：

1. 安装核心系统，并确保SSHD正在运行。

2. 定义一个在系统上具有管理员权限的用户。

3. 从控制节点运行一个播放列表，将建立初始连接并将本地的SSH密钥复制到远程位置。

4. 使用适当的 playbooks 来安全地重新配置系统，而无需在本地存储密码。

现在，让我们深入了解一下。

每个合理的管理者都会告诉你，为了做任何事情，你需要定义问题的范围。在自动化中，这意味着定义 Ansible 将要处理的系统。这是通过位于/etc/Ansible的清单文件hosts完成的。

Hosts可以被分组或单独命名。在文本格式中，可以这样写：

[servers]
srv1.local
srv2.local
srv3.local
[workstations]
wrk1.local
wrk2.local
wrk3.local

计算机可以同时属于多个组，组也可以是嵌套的。

我们在这里使用的格式是纯文本。让我们用 YAML 来重写这个：

All:
  Servers:
     Hosts:
	Srv1.local:
Srv2.local:
Srv3.local:
 Workstations:
     Hosts:
	Wrk1.local:
Wrk2.local:
Wrk3.local:
Production:
   Hosts:
	Srv1.local:
	Workstations:

重要提示

我们创建了另一个名为 Production 的组，其中包含所有工作站和一个服务器。

任何不属于默认或标准配置的内容都可以作为变量单独包含在主机定义或组定义中。每个 Ansible 命令都有一些方式可以在配置或清单中部分或完全覆盖所有项目的灵活性。

清单支持主机定义中的范围。我们之前的示例可以写成如下形式：

[servers]
Srv[1:3].local
[workstations]
Wrk[1:3].local

这也适用于字符，所以如果我们需要定义名为srva、srvb、srvc和srvd的服务器，我们可以通过以下方式来说明：

srv[a:d]

也可以使用 IP 范围。因此，例如，10.0.0.0/24将被写成如下形式：

10.0.0.[1:254]

还有两个预定义的默认组也可以使用：all和ungrouped。顾名思义，如果我们在 playbook 中引用all，它将在清单中的每台服务器上运行。Ungrouped将仅引用那些不属于任何组的系统。

未分组的引用在设置新计算机时特别有用-如果它们不属于任何组，我们可以将它们视为新，并设置它们加入特定的组。

这些组是隐式定义的，无需重新配置它们，甚至在清单文件中提及它们。

我们提到清单文件可以包含变量。当我们需要在计算机组、用户、密码或特定于该组的设置中定义一个属性时，变量是有用的。假设我们想要定义一个将在servers组上使用的用户：

1. 首先，我们定义一个组：

[servers]
srv[1:3].local

1. 然后，我们定义将用于整个组的变量：

[servers:vars]
ansible_user=Ansibleuser
ansible_connection=ssh

当要求执行 playbook 时，这将使用名为Ansibleuser的用户使用SSH进行连接。

重要提示

请注意，密码不在此处出现，如果密码没有单独提及或密钥在此之前没有交换，此 playbook 将失败。有关变量及其使用的更多信息，请参阅 Ansible 文档。

现在我们已经创建了我们的第一个实用的 Ansible 任务，是时候谈谈如何让 Ansible 一次执行多个任务了，同时使用更客观的方法。能够创建单个任务或一对任务，并通过一个称为playbook的概念将它们组合起来是非常重要的。

使用 playbooks

一旦我们决定如何连接到我们打算管理的机器，并且一旦我们创建了清单，我们就可以开始实际使用 Ansible 来做一些有用的事情。这就是 playbooks 开始变得有意义的地方。

在我们的示例中，我们配置了四台 CentOS7 系统，为它们分配了连续的地址范围内的地址10.0.0.1到10.0.0.4，并将它们用于一切。

Ansible 已安装在 IP 地址为10.0.0.1的系统上，但正如我们已经说过的，这完全是任意的。Ansible 在用作控制节点的系统上占用空间很小，并且只要它与我们打算管理的网络的其余部分有连接，就可以安装在任何系统上。我们只是选择了我们小型网络中的第一台计算机。还要注意的一件事是，控制节点可以通过 Ansible 自身进行控制。这很有用，但同时也不是一个明智的做法。根据您的设置，您不仅要测试 playbooks，还要测试部署到其他机器之前的单个命令-在控制服务器上进行这样的操作是不明智的。

现在 Ansible 已安装，我们可以尝试使用它做一些事情。Ansible 有两种不同的运行方式。一种是运行 playbook，其中包含要执行的任务。另一种方式是使用单个任务，有时称为临时执行。无论哪种方式都有使用 Ansible 的原因- playbooks 是我们的主要工具，你可能会大部分时间使用它们。但临时执行也有其优势，特别是如果我们有兴趣做一些我们需要一次完成的事情，但是要跨多台服务器进行。一个典型的例子是使用一个简单的命令来检查已安装应用程序的版本或应用程序状态。如果我们需要检查某些东西，我们不会编写一个 playbook。

为了查看一切是否正常工作，我们将从简单地使用 ping 开始，以检查机器是否在线。

Ansible 喜欢称自己为根本简单的自动化，我们要做的第一件事就证明了这一点。

我们将使用一个名为 ping 的模块，该模块尝试连接到主机，验证它是否可以在本地 Python 环境中运行，并在一切正常时返回一条消息。不要将此模块与 Linux 中的ping命令混淆；我们不是通过网络进行 ping 操作；我们只是从控制节点向我们试图控制的服务器进行ping。我们将使用一个简单的ansible命令来 ping 所有已定义的主机，发出以下命令：

ansible all -m ping

运行上述命令的结果如下：

图 11.18-我们的第一个 Ansible 模块-ping，检查 Python 并报告其状态

我们在这里做的是运行一个名为ansible all -m ping的单个命令。

ansible是可用的最简单的命令，运行单个任务。all参数表示在清单中的所有主机上运行它，-m用于调用将要运行的模块。

这个特定的模块没有参数或选项，所以我们只需要运行它以获得结果。结果本身很有趣；它是以 YAML 格式呈现的，并包含除命令结果之外的一些内容。

如果我们仔细看一下，我们会发现 Ansible 为清单中的每个主机返回了一个结果。我们可以看到的第一件事是命令的最终结果-SUCCESS表示任务本身顺利运行。之后，我们可以看到一个数组形式的数据-ansible_facts包含模块返回的信息，在编写 playbooks 时被广泛使用。以这种方式返回的数据可能会有所不同。在下一节中，我们将展示一个更大的数据集，但在这种特殊情况下，显示的唯一内容是 Python 解释器的位置。之后，我们有changed变量，这是一个有趣的变量。

当 Ansible 运行时，它会尝试检测它是否正确运行以及是否已更改系统状态。在这个特定的任务中，运行的命令只是提供信息，并不会更改系统上的任何内容，因此系统状态没有改变。

换句话说，这意味着运行的任何命令都没有安装或更改系统上的任何内容。在以后需要检查某些东西是否已安装或未安装（例如服务）时，状态将更有意义。

我们可以看到的最后一个变量是ping命令的返回。它简单地声明pong，因为这是模块在一切设置正确时给出的正确答案。

让我们做类似的事情，但这次带有一个参数，比如我们希望在远程主机上执行的临时命令。因此，请输入以下命令：

ansible all -m shell -a "hostname"

以下是输出：

图 11.19 - 使用 Ansible 在 Ansible 目标上显式执行特定命令

在这里，我们调用了另一个名为shell的模块。它只是将给定的参数作为 shell 命令运行。返回的是本地主机名。这在功能上与我们使用SSH连接到清单中的每个主机，执行命令，然后注销的操作是一样的。

对于 Ansible 可以做的简单演示来说，这是可以的，但让我们做一些更复杂的事情。我们将使用一个特定于 CentOS/Red Hat 的名为yum的模块来检查我们的主机上是否安装了 Web 服务器。我们要检查的 Web 服务器将是lighttpd，因为我们想要轻量级的东西。

当我们谈到状态时，我们触及了一个起初有点令人困惑，但一旦开始使用就非常有用的概念。当调用这样的命令时，我们正在声明一个期望的状态，因此如果状态不是我们要求的状态，系统本身将发生变化。这意味着，在这个例子中，我们实际上并不是在测试lighttpd是否已安装 - 我们是在告诉 Ansible 去检查它，如果它没有安装就安装它。即使这也不完全正确 - 该模块接受两个参数：服务的名称和它应该处于的状态。如果我们检查的系统状态与调用模块时发送的状态相同，我们将得到changed: false，因为没有发生任何变化。但是，如果系统的状态不同，Ansible 将使系统的当前状态与我们请求的状态相同。

为了证明这一点，我们将看看服务在 Ansible 术语中是未安装或不存在的。请键入以下命令：

ansible all -m yum -a "name=lighttpd state=absent" 

这是运行前述命令后应该得到的结果：

图 11.20 - 使用 Ansible 检查服务状态

然后，我们可以说我们希望它出现在系统上。Ansible 将根据需要安装服务：

图 11.21 - 在所有 Ansible 目标上使用 yum install 命令

在这里，我们可以看到 Ansible 只是检查并安装了服务，因为它之前不存在。它还为我们提供了其他有用的信息，比如系统上做了什么更改以及它执行的命令的输出。信息以变量数组的形式提供；这通常意味着我们需要进行一些字符串操作，以使其看起来更好。

现在，让我们再次运行该命令：

ansible all -m yum -a "name=lighttpd state=absent" 

这应该是结果：

图 11.22 - 在服务安装后使用 Ansible 检查服务状态

正如我们所看到的，这里没有任何变化，因为服务已安装。

这些只是一些起步示例，以便我们能够稍微了解一下 Ansible。现在，让我们扩展一下，并创建一个 Ansible playbook，它将在我们预定义的一组主机上安装 KVM。

安装 KVM

现在，让我们创建我们的第一个 playbook，并使用它在所有主机上安装 KVM。对于我们的 playbook，我们使用了 GitHub 存储库中的一个很好的例子，由 Jared Bloomer 创建，我们稍微修改了一下，因为我们已经配置了我们的选项和清单。原始文件可在github.com/jbloomer/Ansible---Install-KVM-on-CentOS-7.git找到。

这个 playbook 将展示我们需要了解的关于自动化简单任务的一切。我们选择了这个特定的例子，因为它不仅展示了自动化的工作原理，还展示了如何创建单独的任务并在不同的 playbook 中重用它们。使用公共存储库的一个额外好处是你将始终获得最新版本，但它可能与这里呈现的版本有很大不同：

1. 首先，我们创建了我们的主要 playbook – 将被调用的那个 – 并命名为installkvm.yaml：

图 11.23–检查虚拟化支持并安装 KVM 的主要 Ansible playbook

正如我们所看到的，这是一个简单的声明，所以让我们逐行分析一下。首先，我们有 playbook 名称，一个可以包含我们想要的任何内容的字符串：

hosts变量定义了这个 playbook 将在清单的哪一部分上执行 – 在我们的情况下，是所有主机。我们可以在运行时覆盖这一点（以及所有其他变量），但将 playbook 限制在我们需要控制的主机上是有帮助的。在我们的特定情况下，这实际上是我们清单中的所有主机，但在生产中，我们可能会有多个主机组。

下一个变量是执行任务的用户的名称。我们在这里做的事情在生产中是不推荐的，因为我们使用超级用户帐户来执行任务。Ansible 完全能够使用非特权帐户并在需要时提升权限，但就像所有演示一样，我们会犯错误，这样你就不必犯错误，所有这些都是为了更容易理解事情。

现在是实际执行我们任务的部分。在 Ansible 中，我们为系统声明角色。在我们的例子中，有两个角色。角色实际上只是要执行的任务，这将导致系统处于某种状态。在我们的第一个角色中，我们将检查系统是否支持虚拟化，然后在第二个角色中，我们将在所有支持虚拟化的系统上安装 KVM 服务。

1. 当我们从 GitHub 下载脚本时，它创建了一些文件夹。在名为roles的文件夹中，有两个子文件夹，每个文件夹都包含一个文件；一个叫做checkVirtualization，另一个叫做installKVM。

你可能已经看到这是怎么回事了。首先，让我们看看checkVirtualization包含什么：

图 11.24–通过 lscpu 命令检查 CPU 虚拟化

这个任务只是调用一个 shell 命令，并尝试使用grep来查找包含 CPU 虚拟化参数的行。如果找不到，它就会失败。

1. 现在，让我们看看另一个任务：

图 11.25–用于安装必要的 libvirt 软件包的 Ansible 任务

第一部分是一个简单的循环，如果它们不存在，将安装五个不同的软件包。我们在这里使用的是包模块，这与我们在第一次演示中如何安装软件包的方法不同。我们在本章早些时候使用的模块称为yum，它是特定于 CentOS 作为发行版的。package模块是一个通用模块，将转换为特定发行版使用的任何软件包管理器。一旦我们安装了所有需要的软件包，我们需要确保libvirtd已启用并已启动。

我们使用一个简单的循环来遍历我们正在安装的所有软件包。这不是必需的，但这比复制和粘贴单个命令更好，因为它使我们需要的软件包列表更加可读。

然后，作为任务的最后一部分，我们验证 KVM 是否已加载。

正如我们所看到的，playbook 的语法很简单。即使是对脚本编程只有少量知识的人也可以轻松阅读。我们甚至可以说，对 Linux 命令行工作原理的深刻理解更为重要。

1. 为了运行 playbook，我们使用ansible-playbook命令，后面跟着 playbook 的名称。在我们的情况下，我们将使用ansible-playbook main.yaml命令。这里是结果：

图 11.26 - 交互式 Ansible playbook 监控

1. 在这里，我们可以看到 Ansible 将在每个主机上做的每一项更改进行了详细的拆分。最终结果是成功的：

图 11.27 - Ansible playbook 报告

现在，让我们检查我们新安装的 KVM 集群是否正常工作。

1. 我们将启动virsh并列出集群各部分的活动 VM：

图 11.28 - 使用 Ansible 检查所有 Ansible 目标上的虚拟机

完成了这个简单的练习后，我们在四台机器上都运行了 KVM，并且可以从一个地方控制它们。但是我们的主机上还没有运行任何 VM。接下来，我们将向您展示如何在 KVM 环境中创建一个 CentOS 安装，但我们将使用最基本的方法 - virsh。

我们将做两件事：首先，我们将从互联网上下载一个 CentOS 的最小 ISO 镜像。然后，我们将调用virsh。本书将向您展示完成此任务的不同方法；从互联网上下载是最慢的方法之一：

1. 像往常一样，Ansible 有一个专门用于下载文件的模块。它期望的参数是文件所在的 URL 和保存文件的位置：

图 11.29 - 在 Ansible playbook 中下载文件

1. 运行 playbook 后，我们需要检查文件是否已经下载：

图 11.30 - 状态检查 - 检查文件是否已经下载到我们的目标

1. 由于我们没有自动化这个过程，而是创建了一个单独的任务，我们将在本地 shell 中运行它。要运行此命令，可以使用类似以下的命令：

ansible all -m shell -a "virt-install --name=COS7Core --ram=2048 --vcpus=4 --cdrom=/var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-1810.iso --os-type=linux --os-variant=rhel7 --disk path=/var/lib/libvirt/images/cos7vm.dsk,size=6"

1. 没有 kickstart 文件或其他类型的预配置，这个 VM 是没有意义的，因为我们将无法连接到它，甚至无法完成安装。在下一个任务中，我们将使用 cloud-init 来解决这个问题。

现在，我们可以检查一切是否都正常工作：

图 11.31 - 使用 Ansible 检查我们的所有 VM 是否正在运行

在这里，我们可以看到所有的 KVM 都在运行，并且每个 KVM 都有自己的虚拟机在线并运行。

现在，我们将清除我们的 KVM 集群，并重新开始，但这次使用不同的配置：我们将部署 CentOS 的云版本，并使用 cloud-init 重新配置它。

使用 Ansible 和 cloud-init 进行自动化和编排

Cloud-init是私有和混合云环境中机器部署的更受欢迎的方式之一。这是因为它使机器能够快速重新配置，以便启用足够的功能，使它们能够连接到诸如 Ansible 之类的编排环境。

更多细节可以在cloud-init.io找到，但简而言之，cloud-init 是一个工具，可以创建特殊文件，可以与 VM 模板结合，以便快速部署它们。cloud-init 和无人值守安装脚本之间的主要区别在于，cloud-init 更多或更少地与发行版无关，并且更容易使用脚本工具进行更改。这意味着在部署过程中工作量更少，从部署开始到机器在线并工作的时间更短。在 CentOS 上，可以使用 kickstart 文件来实现这一点，但这远不及 cloud-init 灵活。

Cloud-init 使用两个单独的部分工作：一个是我们正在部署的操作系统的分发文件。这不是通常的 OS 安装文件，而是一个特别配置的机器模板，旨在用作 cloud-init 镜像。

系统的另一部分是配置文件，它是从一个包含机器配置的特殊 YAML 文本文件中编译 - 或者更准确地说，打包出来的。这个配置很小，非常适合网络传输。

这两个部分旨在作为一个整体用于创建多个相同虚拟机实例。

它的工作方式很简单：

1. 首先，我们分发一个完全相同的机器模板，用于创建我们将要创建的所有机器。这意味着有一个主模板副本，并且可以从中创建所有实例。

2. 然后，我们将模板与使用 cloud-init 创建的一个特制文件配对。我们的模板，无论使用的操作系统是什么，都能够理解可以在 cloud-init 文件中设置的不同指令，并将被重新配置。这可以根据需要重复进行。

让我们更简化一下：如果我们需要使用无人值守安装文件创建具有四种不同角色的 100 台服务器，我们将不得不启动 100 个镜像，并等待它们逐个完成所有安装步骤。然后，我们需要为我们需要的任务重新配置它们。使用 cloud-init，我们在 100 个实例中启动一个镜像，但系统只需要几秒钟就能启动，因为它已经安装好了。只需要关键信息将其上线，之后我们可以接管并使用 Ansible 完全配置它。

我们不会过多讨论 cloud-init 的配置；我们需要的一切都在这个例子中：

图 11.32 - 使用 cloud-init 进行附加配置

像往常一样，我们将一步一步地解释发生了什么。我们从一开始就可以看到它使用直接的 YAML 表示法，与 Ansible 相同。第一个指令是为了确保我们的机器已更新，因为它可以自动更新云实例上的软件包。

然后，我们正在配置用户。我们将创建一个名为ansible的用户，他将属于wheel组。

Lock_passwd表示我们将允许使用密码登录。如果没有配置任何内容，则默认情况下只允许使用SSH密钥登录，并完全禁用密码登录。

然后，我们有哈希格式的密码。根据发行版的不同，可以以不同的方式创建这个哈希。在这里不要放置明文密码。

然后，我们有一个 shell，这个用户将能够使用，如果需要向/etc/sudoers文件添加内容。在这种情况下，我们给予这个用户对系统的完全控制。

最后一件事可能是最重要的。这是我们系统上的公共SSH密钥。它用于授权用户登录时使用。这里可以有多个密钥，并且它们将最终出现在SSHD配置中，以便用户可以进行无密码登录。

这里有很多变量和指令可以使用，因此请查阅cloud-config文档以获取更多信息。

创建完这个文件后，我们需要将其转换为一个.iso文件，该文件将用于安装。执行此操作的命令是cloud-localds。我们将我们的 YAML 文件用作一个参数，.iso文件用作另一个参数。

运行cloud-localds config.iso config.yaml之后，我们准备开始部署。

我们需要的下一件事是 CentOS 的云镜像。正如我们之前提到的，这是一种专门设计用于这个特定目的的特殊镜像。

我们将从cloud.centos.org/centos/7/images获取它。

这里有很多文件，表示 CentOS 镜像的所有可用版本。如果您需要特定版本，请注意表示镜像发布的月/年的数字。还要注意，镜像有两种类型 - 压缩和未压缩。

镜像以qcow2格式存在，旨在作为云盘使用。

在我们的例子中，在 Ansible 机器上，我们创建了一个名为/clouddeploy的新目录，并将两个文件保存在其中：一个包含 OS 云镜像的文件和使用cloud-init创建的config.iso：

图 11.33 - 检查目录内容

现在剩下的就是创建一个部署这些内容的 playbook。让我们按照以下步骤进行：

1. 首先，我们将复制云镜像和我们的配置到我们的 KVM 主机上。之后，我们将创建一个机器，并启动它：

图 11.34 - 将下载所需镜像、配置 cloud-init 并启动 VM 部署过程的 playbook

由于这是我们的第一个复杂的 playbook，我们需要解释一些事情。在每个 play 或 task 中，有一些重要的事情。名称用于简化运行 playbook；这是 playbook 运行时将显示的内容。这个名称应该足够解释性，以帮助理解，但不要太长以避免混乱。

在名称之后，我们有每个任务的业务部分 - 被调用的模块的名称。在我们的例子中，我们使用了三个不同的模块：copy、command和virt。copy用于在主机之间复制文件，command在远程机器上执行命令，virt包含控制虚拟环境所需的命令和状态。

阅读时您会注意到copy看起来很奇怪；src表示本地目录，而dest表示远程目录。这是有意设计的。为了简化事情，copy在本地机器（运行 Ansible 的控制节点）和远程机器（正在配置的机器）之间工作。如果目录不存在，将会创建目录，并且copy将应用适当的权限。

之后，我们将运行一个命令，该命令将处理本地文件并创建一个虚拟机。这里的一个重要事情是，我们基本上运行了我们复制的镜像；模板在控制节点上。同时，这节省了磁盘空间和部署时间 - 没有必要将机器从本地复制到远程磁盘，然后再次在远程机器上复制；一旦镜像在那里，我们就可以运行它。

回到重要的部分 – 本地安装。我们正在创建一个具有 1GB RAM 和一个 CPU 的机器，使用我们刚刚复制的磁盘映像。我们还将config.iso文件作为虚拟 CD/DVD 附加。然后，我们导入此映像并不使用图形终端。

1. 最后一个任务是在远程 KVM 主机上启动 VM。我们将使用以下命令来执行：

ansible-playbook installvms.yaml

如果一切正常运行，我们应该看到类似于这样的东西：

图 11.35 – 检查我们的安装过程

我们也可以使用命令行来检查：

ansible cloudhosts -m shell -a "virsh list –all"

此命令的输出应该看起来像这样：

图 11.36 – 检查我们的虚拟机

让我们再检查两件事 – 网络和机器状态。输入以下命令：

ansible cloudhosts -m shell -a "virsh net-dhcp-leases –-network default"

我们应该得到类似于这样的东西：

图 11.37 – 检查我们的 VM 网络连接和网络配置

这验证了我们的机器是否正常运行，并且它们连接到本地 KVM 实例的本地网络。在本书的其他地方，我们将更详细地处理 KVM 网络，因此重新配置机器以使用公共网络应该很容易，无论是通过在 KVM 上桥接适配器，还是通过创建一个跨主机的独立虚拟网络。

我们想要展示的另一件事是所有主机的机器状态。重点是，这次我们不是使用 shell 模块；相反，我们依靠virt模块来显示如何从命令行使用它。这里只有一个细微的区别。当我们调用 shell（或command）模块时，我们正在调用将被调用的参数。这些模块基本上只是在远程机器上生成另一个进程，并使用我们提供的参数运行它。

相比之下，virt模块以变量声明作为其参数，因为我们正在使用command=info运行virt。在使用 Ansible 时，您会注意到，有时变量只是状态。如果我们想要启动特定的实例，我们只需添加state=running，以及一个适当的名称，Ansible 会确保虚拟机正在运行。让我们输入以下命令：

ansible cloudhosts -m virt -a "command=info"

以下是预期的输出：

图 11.38 – 使用 virt 模块与 Ansible

我们还没有涵盖的一件事是如何安装多层应用程序。将定义推到最小的极端，我们将使用简单的 playbook 安装 LAMP 服务器。

在 KVM VM 上编排多层应用程序部署

现在，让我们学习如何安装多层应用程序。将定义推到最小的极端，我们将使用简单的 Ansible playbook 安装 LAMP 服务器。

需要完成的任务非常简单 – 我们需要安装 Apache、MySQL 和 PHP。LAMP 的L部分已经安装好了，所以我们不会再次进行安装。

困难的部分是软件包名称：在我们的演示机器上，我们使用 CentOS7 作为操作系统，其软件包名称有些不同。Apache 被称为httpd，mysql被替换为与 MySQL 兼容的另一个引擎mariaDB。PHP 幸运地与其他发行版上的相同。我们还需要另一个名为python2-PyMySQL的软件包（名称区分大小写）以使我们的 playbook 工作。

接下来要做的事情是通过启动所有服务并创建最简单的.php脚本来测试安装。之后，我们将创建一个数据库和一个将使用它的用户。需要警告的是，在本章中，我们专注于 Ansible 的基础知识，因为 Ansible 太复杂，无法在一本书的一章中涵盖。此外，我们假设了很多事情，我们最大的假设是我们正在创建的演示系统并不打算用于生产。特别是这个 playbook 缺少一个重要的步骤：创建一个 root 密码。不要在未设置 SQL 密码的情况下投入生产。

还有一件事：我们的脚本假设在我们的 playbook 运行的目录中有一个名为index.php的文件，并且该文件将被复制到远程系统中：

图 11.39 - Ansible LAMP playbook

正如我们所看到的，没有发生复杂的事情，只是一系列简单的步骤。我们的.php文件如下所示：

图 11.40 - 测试 PHP 是否正常工作

事情不可能比这更简单了。在正常的部署场景中，我们在 web 服务器目录中会有更复杂的东西，比如 WordPress 或 Joomla 安装，甚至是自定义应用程序。唯一需要改变的是被复制的文件（或一组文件）和数据库的位置。我们的文件只是打印有关本地.php安装的信息：

图 11.41 - 使用 Web 浏览器检查 PHP 在 Apache 上是否正常工作和之前配置的 PHP 文件

Ansible 比我们在本章中展示的要复杂得多，因此我们强烈建议您进行进一步阅读和学习。我们在这里所做的只是如何在多个主机上安装 KVM 并使用命令行一次性控制它们的最简单示例。Ansible 最擅长的是节省我们的时间 - 想象一下有几百个 hypervisor 并且必须部署成千上万台服务器。使用 playbooks 和一些预配置的镜像，我们不仅可以配置 KVM 来运行我们的机器，还可以重新配置机器上的任何东西。唯一真正的先决条件是运行的 SSH 服务器和一个能够使我们对机器进行分组的清单。

通过示例学习 - 使用 Ansible 与 KVM 的各种示例

现在我们已经介绍了简单和更复杂的 Ansible 任务，让我们考虑如何使用 Ansible 来进一步提高我们的配置技能和整体合规性，基于某种政策。以下是一些我们将留给您作为练习的事项：

• 任务 1：

我们配置并运行了每个 KVM 主机上的一台机器。创建一个将形成一对主机的 playbook - 一个运行网站，另一个运行数据库。您可以使用任何开源 CMS 来实现这一点。

• 任务 2:

使用 Ansible 和virt-net模块重新配置网络，以便整个集群可以通信。KVM 接受网络的.xml配置，virt-net可以读取和写入 XML。提示：如果感到困惑，请使用单独的 RHEL8 机器在 GUI 中创建一个虚拟网络，然后使用virsh net-dumpxml语法将虚拟网络配置输出到标准输出，然后可以将其用作模板。

• 任务 3：

使用ansible和virsh自动启动您在主机上创建/导入的特定 VM。

• 任务 4：

根据我们的 LAMP 部署 playbook，通过以下方式改进它：

a）创建一个可以在远程机器上运行的 playbook。

b）创建一个将在不同服务器上安装不同角色的 playbook。

c）创建一个部署更复杂应用程序（如 WordPress）的 playbook。

如果您成功解决了这五个任务，那么恭喜您——您正在成为一个可以使用大写字母A的自动化管理员。

摘要

在本章中，我们讨论了 Ansible——一个用于编排和自动化的简单工具。它可以在开源和基于 Microsoft 的环境中使用，因为它本身支持这两种环境。可以通过 SSH 密钥访问开源系统，而可以通过 WinRM 和 PowerShell 访问 Microsoft 操作系统。我们学到了许多关于简单的 Ansible 任务和更复杂的任务，因为部署托管在多个虚拟机上的多层应用程序并不是一件容易的事情——特别是如果您手动解决问题。即使在多个主机上部署 KVM hypervisor 也可能需要相当长的时间，但我们成功地用一个简单的 Ansible playbook 解决了这个问题。请注意，我们只需要大约 20 行配置来做到这一点，而由此带来的好处是我们可以轻松地将数百个主机添加为此 Ansible playbook 的目标。

下一章将带我们进入云服务的世界——具体来说是 OpenStack——在那里我们的 Ansible 知识将对大规模虚拟机配置非常有用，因为使用任何手动工具都无法配置所有的云虚拟机。除此之外，我们将通过集成 OpenStack 和 Ansible 来扩展我们对 Ansible 的了解，以便我们可以同时使用这两个平台来做它们擅长的事情——管理云环境和配置其可消耗资源。

问题

1. 什么是 Ansible？

2. Ansible playbook 的作用是什么？

3. Ansible 使用哪种通信协议连接到其目标？

4. 什么是 AWX？

5. 什么是 Ansible Tower？

进一步阅读

有关本章内容的更多信息，请参考以下链接：

• 什么是 Ansible？：www.ansible.com/

• Ansible 文档：docs.ansible.com/

• Ansible 概述：www.ansible.com/overview/it-automation

• Ansible 用例：www.ansible.com/use-cases

• 用于持续交付的 Ansible：www.ansible.com/use-cases/continuous-delivery

• 将 Ansible 与 Jenkins 集成：www.redhat.com/en/blog/integrating-ansible-jenkins-cicd-process

第四部分：可扩展性、监控、性能调优和故障排除

在本书的这部分，您将学习基于 KVM 的虚拟机和 hypervisor 的可扩展性、监控、高级性能调优和故障排除。

本书的这部分包括以下章节：

• 第十二章，使用 OpenStack 扩展 KVM

• 第十三章，使用 AWS 扩展 KVM

• 第十四章，监控 KVM 虚拟化平台

• 第十五章，KVM 虚拟机性能调优和优化

• 第十六章，KVM 平台故障排除指南

第十二章：使用 OpenStack 扩展 KVM

能够虚拟化一台机器是一件大事，但有时，仅仅虚拟化是不够的。问题在于如何给予个人用户工具，使他们可以在需要时虚拟化他们需要的任何东西。如果我们将以用户为中心的方法与虚拟化相结合，我们将得到一个需要能够连接到 KVM 作为虚拟化机制（不仅仅是 KVM）并使用户能够在自助环境中通过 Web 浏览器获取其虚拟机并自动配置的系统。OpenStack 增加了一件事情，因为它完全免费并且完全基于开源技术。由于其复杂性，配置这样的系统是一个大问题，在本章中，我们将向您展示 - 或者更准确地说，指向您 - 关于是否需要这样的系统的正确方向。

在本章中，我们将涵盖以下主题：

• 介绍 OpenStack

• 软件定义网络

• OpenStack 组件

• 额外的 OpenStack 用例

• 配置 OpenStack 环境

• 将 OpenStack 与 Ansible 集成

• 让我们开始吧！

介绍 OpenStack

根据其自己的说法，OpenStack是一个云操作系统，用于控制大量不同的资源，以提供基础设施即服务（IaaS）和编排的所有基本服务。

但这意味着什么？OpenStack 旨在完全控制数据中心中的所有资源，并提供对可以用于部署其自身和第三方服务的任何资源的集中管理和直接控制。基本上，对于我们在本书中提到的每项服务，在整个 OpenStack 景观中都有一个可以使用该服务的地方。

OpenStack 本身由几个不同的相互连接的服务或服务部分组成，每个都有自己的功能集，每个都有自己的 API，可以完全控制该服务。在本书的这一部分，我们将尝试解释 OpenStack 的不同部分的功能，它们如何相互连接，它们提供的服务以及如何利用这些服务来获得优势。

OpenStack 存在的原因是因为需要一个开源的云计算平台，可以创建独立于任何商业云平台的公共和私有云。OpenStack 的所有部分都是开源的，并且根据 Apache 许可证 2.0 发布。该软件是由大型混合个人和大型云提供商创建的。有趣的是，第一个主要版本的发布是 NASA（美国政府机构）和 Rackspace Technology（美国大型托管公司）合并其内部存储和计算基础设施解决方案的结果。这些发布后来被指定为 Nova 和 Swift，并且我们将在后面更详细地介绍它们。

你将注意到关于 OpenStack 的第一件事是它的服务，因为没有单一的OpenStack服务，而是一整套服务。名称OpenStack直接来自这个概念，因为它正确地将 OpenStack 识别为一个作为服务的开源组件，这些服务又被分组成功能集。

一旦我们了解到我们正在谈论自主服务，我们还需要了解 OpenStack 中的服务是按其功能分组的，并且某些功能下有不止一个专门的服务。我们将尽量在本章中涵盖尽可能多的不同服务，但是其中有太多的服务，甚至无法在这里提及所有。所有文档和白皮书都可以在openstack.org找到，我们强烈建议您查阅其中任何未在此处提及的内容，甚至对我们提到但在您阅读时可能已经发生变化的内容也要查阅。

我们需要澄清的最后一件事是命名——OpenStack 中的每个服务都有其项目名称，并且在文档中以该名称来引用。乍一看，这可能看起来令人困惑，因为其中一些名称与特定服务在整个项目中的具体功能完全无关，但一旦你开始使用 OpenStack，使用名称而不是官方指示符来表示功能会更容易。例如，Swift。Swift 的全名是OpenStack 对象存储，但在文档或其实施中很少提到。其他服务或在 OpenStack 下的项目，如 Nova、Ironic、Neutron、Keystone 以及其他 20 多个不同的服务也是如此。

如果你暂时离开 OpenStack，那么你需要考虑云服务的本质。云服务的本质就是扩展——无论是计算资源、存储、网络、API 等。但是，就像生活中的一切一样，随着事物的扩展，你会遇到问题。这些问题有它们自己的名称和解决方案。所以，让我们讨论一下这些问题。

云服务提供商可扩展性的基本问题可以分为三组需要大规模解决的问题：

• 计算问题（计算=CPU+内存能力）：这些问题解决起来相当简单——如果你需要更多的 CPU 和内存能力，你就购买更多的服务器，这意味着更多的 CPU 和内存。如果你需要服务质量/服务级别协议（SLA）类型的概念，我们可以引入计算资源池的概念，这样我们可以根据需要切割计算饼并在我们的客户之间分配这些资源。无论我们的客户是私人还是购买云服务的公司，这都无关紧要。在云技术中，我们称我们的客户为租户。

• 存储问题：随着云环境的扩展，存储容量、管理、监控以及性能方面变得非常混乱。性能问题有一些最常用的变量——读写吞吐量和读写 IOPS。当你将环境从 100 个主机扩展到 1,000 个或更多时，性能瓶颈将成为一个难以解决的主要问题。因此，存储问题可以通过增加额外的存储设备和容量来解决，但它比计算问题更复杂，需要更多的配置和资金。记住，每个虚拟机对其他虚拟机的性能有统计上的影响，虚拟机越多，这种熵就越大。这是存储基础设施中最难管理的过程。

• A无法与租户B的网络流量通信。与此同时，你仍然需要提供一个能够让租户拥有多个网络（通常在非云基础设施中通过 VLAN 实现）并在这些网络之间进行路由的能力，如果这是租户需要的话。

这个网络问题是一个基于技术的可扩展性问题，因为 VLAN 背后的技术在 VLAN 数量成为可扩展性问题之前已经标准化了多年。

让我们继续通过解释云环境的最基本主题来了解 OpenStack，即通过软件定义网络（SDN）扩展云网络。这样做的原因非常简单——没有 SDN 概念，云对于客户来说就不够可扩展，这将是一个完全的停滞。所以，系好你的安全带，让我们进行 SDN 入门。

软件定义网络

云的一个直接的故事——至少表面上是这样——应该是关于云网络的故事。为了理解这个故事应该有多简单，我们只需要看一个数字，那个数字就是VLAN 1。

所以，基本上，在现实场景中，我们剩下了 4,093 个单独的逻辑网络，这可能已经足够用于任何公司的内部基础设施。然而，对于公共云提供商来说，这远远不够。同样的问题也适用于使用混合云类型服务的公共云提供商，例如将他们的计算能力扩展到云端。

所以，让我们稍微关注一下这个网络问题。从云用户的角度来看，数据隐私对我们来说至关重要。如果从云提供商的角度来看这个问题，那么我们希望我们的网络隔离问题对我们的租户来说不成问题。这就是云服务在更基本层面上的全部意义——无论技术背景的复杂性如何，用户都必须能够以尽可能用户友好的方式访问所有必要的服务。让我们通过一个例子来解释这一点。

如果我们的公共云环境中有 5,000 个不同的客户（租户）会发生什么？如果每个租户都需要拥有五个或更多的逻辑网络会发生什么？我们很快意识到我们有一个大问题，因为云环境需要被分隔、隔离和围栏起来。出于安全和隐私原因，它们需要在网络层面相互分隔。然而，如果租户需要那种服务，它们也需要可路由。除此之外，我们需要能够扩展，以便在需要超过 5,000 或 50,000 个隔离网络的情况下不会困扰我们。再次回到我们之前的观点——大约 4,000 个 VLAN 根本不够用。

我们之所以说这应该是一个简单的故事，是有原因的。我们中的工程师们将这些情况看得很黑白分明——我们专注于问题并试图找到解决方案。解决方案似乎相当简单——我们需要扩展 12 位 VLAN ID 字段，以便我们可以拥有更多可用的逻辑网络。这有多难呢？

事实证明，这是非常困难的。如果历史教会我们任何东西，那就是各种不同的利益、公司和技术会在 IT 技术方面争夺多年的顶级地位。只需想想 DVD+R、DVD-R、DVD+RW、DVD-RW、DVD-RAM 等旧日的情形。简化一下，当云网络的初始标准被引入时，同样的情况也发生了。我们通常将这些网络技术称为云覆盖网络技术。这些技术是 SDN 的基础，它描述了云网络在全球、集中管理层面上的工作方式。市场上有多种标准来解决这个问题——VXLAN、GRE、STT、NVGRE、NVO3 等等。

实际上，没有必要一一解释它们。我们将采取更简单的方式——我们将描述其中一个在今天环境中最有价值的标准（VXLAN），然后转向被认为是明天统一标准的东西（GENEVE）。

首先，让我们定义什么是叠加网络。当我们谈论叠加网络时，我们指的是建立在同一基础设施中另一个网络之上的网络。叠加网络背后的想法很简单 - 我们需要将网络的物理部分与逻辑部分分开。如果我们想要以绝对方式进行配置（在 CLI 中配置物理交换机、路由器等，而不需要花费大量时间），我们也可以这样做。如果我们不想以这种方式做，而且仍然希望直接与我们的物理网络环境一起工作，我们需要在整体方案中添加一层可编程性。然后，如果我们愿意，我们可以与我们的物理设备进行交互，并向它们推送网络配置，以实现更自上而下的方法。如果我们以这种方式做事情，我们将需要更多来自我们的硬件设备的支持，以满足能力和兼容性方面的要求。

现在我们已经描述了什么是网络叠加，让我们谈谈 VXLAN，这是最重要的叠加网络标准之一。它还作为开发其他网络叠加标准（如 GENEVE）的基础，因此 - 您可能会想象到 - 了解其工作原理非常重要。

了解 VXLAN

让我们从令人困惑的部分开始。VXLAN（IETF RFC 7348）是一种可扩展的叠加网络标准，使我们能够在 Layer 3 网络中聚合和隧道多个 Layer 2 网络。它是如何做到的呢？通过在 Layer 3 数据包内封装 Layer 2 数据包。在传输协议方面，默认情况下使用 UDP，在端口4789上（稍后会详细介绍）。在 VXLAN 实现的特殊请求方面 - 只要您的物理网络支持 MTU 1600，您就可以轻松实现 VXLAN 作为云叠加解决方案。您可以购买的几乎所有交换机（除了廉价的家用交换机，但我们在这里谈论的是企业）都支持巨型帧，这意味着我们可以使用 MTU 9000 并完成。

从封装的角度来看，让我们看看它是什么样子的：

图 12.1 – VXLAN 帧封装

更简单地说，VXLAN 使用两个 VXLAN 端点（称为 VTEP；即 VXLAN 隧道端点）之间的隧道，检查VXLAN 网络标识符（VNIs），以便它们可以决定数据包的去向。

如果这看起来很复杂，那就不用担心 - 我们可以简化这个过程。从 VXLAN 的角度来看，VNI 与 VLAN ID 对 VLAN 的作用是一样的。它是一个唯一的网络标识符。区别只是大小 - VNI 字段有 24 位，而 VLAN 有 12 位。这意味着我们有 2²⁴ 个 VNI，而 VLAN 有 2¹² 个。因此，就网络隔离而言，VXLAN 是 VLAN 的平方。

为什么 VXLAN 使用 UDP？

在设计叠加网络时，通常希望尽量减少延迟。此外，您不希望引入任何形式的开销。当您考虑这两个基本设计原则，并将其与 VXLAN 隧道 Layer 2 流量封装在 Layer 3 内（无论流量是单播、组播还是广播）的事实相结合时，这实际上意味着我们应该使用 UDP。无论如何，TCP 的两种方法 - 三次握手和重传 - 都会妨碍这些基本设计原则。简而言之，TCP 对于 VXLAN 来说太复杂了，因为这意味着在规模上会产生太多的开销和延迟。

就 VTEP 而言，只需将它们想象成两个接口（以软件或硬件实现），可以根据 VNI 封装和解封流量。从技术角度来看，VTEP 将各种租户的虚拟机和设备映射到 VXLAN 段（由 VXLAN 支持的隔离网络），执行包检查，并根据 VNI 封装/解封网络流量。让我们借助以下图表描述这种通信：

图 12.2-单播模式下的 VTEP

在我们基于开源的云基础设施中，我们将使用 OpenStack Neutron 或 Open vSwitch 来实现云覆盖网络，后者是一个免费的开源分布式交换机，支持几乎所有你能想到的网络协议，包括前面提到的 VXLAN、STT、GENEVE 和 GRE 覆盖网络。

此外，在云网络中有一种绅士协议，即在大多数情况下不使用 VXLANs 从1-4999。这样做的原因很简单-因为我们仍然希望以简单且不易出错的方式保留 VLAN 的保留范围为0-4095。换句话说，按设计，我们将网络 ID 0-4095 留给 VLAN，并以 VNI 5000 开始 VXLAN，这样很容易区分两者。在 1670 万个 VXLAN 支持的网络中，不使用 5000 个 VXLAN 支持的网络并不是为了良好的工程实践而做出的太大牺牲。

VXLAN 的简单性、可扩展性和可扩展性也意味着更多真正有用的使用模型，例如以下内容：

• 在站点之间拉伸第 2 层：这是关于云网络的最常见问题之一，我们将很快描述。

• 第 2 层桥接：将 VLAN 桥接到云覆盖网络（如 VXLAN）在我们将用户引入我们的云服务时非常有用，因为他们可以直接连接到我们的云网络。此外，当我们想要将硬件设备（例如物理数据库服务器或物理设备）插入 VXLAN 时，这种使用模型也被广泛使用。如果没有第 2 层桥接，想象一下我们将会有多么痛苦。我们所有运行 Oracle 数据库设备的客户将无法将他们的物理服务器连接到我们基于云的基础设施。

• 各种卸载技术：包括负载平衡、防病毒、漏洞和恶意软件扫描、防火墙、IDS、IPS 集成等。所有这些技术使我们能够拥有简单管理概念的有用、安全的环境。

我们提到在站点之间拉伸第 2 层是一个基本问题，因此很明显我们需要讨论它。我们将在下一节讨论。如果没有解决这个问题的方法，你几乎没有机会有效地创建多个数据中心的云基础设施。

在站点之间拉伸第 2 层

云提供商面临的最常见一组问题之一是如何在站点或大陆之间扩展其环境。在过去，当我们没有诸如 VXLAN 之类的概念时，我们被迫使用某种第 2 层 VPN 或基于 MPLS 的技术。这些类型的服务非常昂贵，有时，我们的服务提供商并不完全满意我们的给我 MPLS或给我第 2 层访问的要求。如果我们在同一句中提到组播这个词，他们会更不高兴，这在过去是一组经常使用的技术标准。因此，具备通过第 3 层传输第 2 层的能力从根本上改变了这种对话。基本上，如果你有能力在站点之间创建基于第 3 层的 VPN（你几乎总是可以做到的），你就不必再讨论这个问题。此外，这显著降低了这些类型基础设施连接的价格。

考虑以下基于组播的示例：

图 12.3-在组播模式下跨站扩展 VXLAN 段

让我们假设这个图表的左侧是第一个站点，右侧是第二个站点。从VM1的角度来看，VM4在其他远程站点并不重要，因为它的段（VXLAN 5001）跨越这些站点。怎么做？只要底层主机可以通过 VXLAN 传输网络相互通信（通常也通过管理网络），第一个站点的 VTEP 可以与第二个站点的 VTEP 进行通信。这意味着在一个站点由 VXLAN 段支持的虚拟机可以通过上述的第 2 层到第 3 层封装与另一个站点中相同的 VXLAN 段进行通信。这是解决一个复杂且昂贵问题的一个非常简单而优雅的方法。

我们提到，作为一种技术，VXLAN 作为开发其他标准的基础，其中最重要的是 GENEVE。随着大多数制造商朝着 GENEVE 兼容性迈进，VXLAN 将慢慢消失。让我们讨论一下 GENEVE 协议的目的，以及它如何成为云覆盖网络的标准。

理解 GENEVE

我们之前提到的基本问题是，云覆盖网络中的历史重演了很多次。不同的标准，不同的固件，不同的制造商支持一种标准而不是另一种，所有这些标准都非常相似，但仍然不兼容。这就是为什么 VMware、微软、红帽和英特尔提出了 GENEVE，这是一个新的云覆盖标准，只定义封装数据格式，而不干涉这些技术的控制平面，这些技术在根本上是不同的。例如，VXLAN 使用 24 位字段宽度的 VNI，而 STT 使用 64 位。因此，GENEVE 标准不提出固定的字段大小，因为你不可能知道未来会发生什么。此外，从现有用户群的角度来看，我们仍然可以愉快地使用我们的 VXLAN，因为我们不认为它们会受到未来 GENEVE 部署的影响。

让我们看看 GENEVE 标头是什么样的：

图 12.4-GENEVE 云覆盖网络标头

GENEVE 的作者从其他一些标准（BGP、IS-IS 和 LLDP）中学到了一些东西，并认为做正确的事情的关键是可扩展性。这就是为什么它被 Linux 社区在 Open vSwitch 和 VMware 在 NSX-T 中采用。自 Windows Server 2016 以来，VXLAN 也被支持为Hyper-V 网络虚拟化（HNV）的网络覆盖技术。总的来说，GENEVE 和 VXLAN 似乎是两种肯定会留下来的技术-从 OpenStack 的角度来看，两者都得到了很好的支持。

现在我们已经解决了云的最基本问题-云网络-我们可以回过头来讨论 OpenStack。具体来说，我们下一个主题与 OpenStack 组件有关-从 Nova 到 Glance，然后到 Swift，以及其他组件。所以，让我们开始吧。

OpenStack 组件

当 OpenStack 最初作为一个项目形成时，它是从两种不同的服务设计的：

• 一个计算服务，旨在管理和运行虚拟机本身

• 一个旨在进行大规模对象存储的存储服务

这些服务现在被称为 OpenStack Compute 或Nova，以及 OpenStack Object Store 或Swift。这些服务后来又加入了Glance或 OpenStack 镜像服务，旨在简化与磁盘映像的工作。此外，在我们的 SDN 入门之后，我们需要讨论 OpenStack Neutron，OpenStack 的网络即服务（NaaS）组件。

以下图表显示了 OpenStack 的组件：

图 12.5-OpenStack 的概念架构（来源：https://docs.openstack.org/）

我们将按照没有特定顺序进行介绍，并包括其他重要的服务。让我们从Swift开始。

Swift

我们需要谈论的第一个服务是 Swift。为此，我们将从 OpenStack 官方文档中获取项目的定义，并解析它，以尝试解释这个项目实现了哪些服务，以及它的用途。Swift 网站 (docs.openstack.org/swift/latest/)中陈述了以下内容：

“Swift 是一个高度可用的、分布式的、最终一致的对象/大块存储。组织可以使用 Swift 高效、安全、廉价地存储大量数据。它专为规模而构建，并针对整个数据集的耐用性、可用性和并发性进行了优化。Swift 非常适合存储可以无限增长的非结构化数据。”

读完这段话后，我们需要指出一些可能对你来说完全新的事情。首先，我们谈论的是以一种特定的方式存储数据，这在计算中并不常见，除非你使用过非结构化数据存储。非结构化并不意味着这种存储数据的方式缺乏结构；在这个上下文中，它意味着我们定义数据的结构，但服务本身不关心我们的结构，而是依赖于对象的概念来存储我们的数据。这种方式的一个结果是，我们存储在 Swift 中的数据不能直接通过任何文件系统或我们习惯通过机器操作文件的其他方式直接访问。相反，我们是以对象的方式操作数据，必须使用 Swift 提供的 API 来获取数据对象。我们的数据存储在大块或对象中，系统本身只是标记和存储以确保可用性和访问速度。我们应该知道我们的数据的内部结构以及如何解析它。另一方面，由于这种方法，Swift 可以以惊人的速度处理任意数量的数据，并且以一种几乎不可能使用普通的经典数据库实现的方式进行水平扩展。

值得一提的是，这项服务提供了高度可用、分布式和最终一致的存储。这意味着，首先，优先级是数据分布和高可用性，这两点在云中非常重要。一致性在此之后，但最终会实现。一旦你开始使用这项服务，你就会明白这意味着什么。在几乎所有通常的情况下，数据被读取而很少被写入，这根本不值得考虑，但也有一些情况下，这可能改变我们需要思考如何提供服务的方式。文档中陈述了以下内容：

“因为对象存储中的每个副本都是独立运行的，客户端通常只需要大多数节点简单响应即可认为操作成功，瞬时故障如网络分区可能会迅速导致副本发散。这些差异最终由异步的点对点复制进程协调一致。复制进程遍历其本地文件系统，并以一种平衡负载的方式同时执行操作。”

我们可以粗略地翻译一下。假设你有一个三节点的 Swift 集群。在这种情况下，Swift 对象在PUT操作至少在两个节点上确认已完成后，才会对客户端可用。因此，如果你的目标是创建一个低延迟、同步的 Swift 存储复制，那么还有其他解决方案可供选择。

在搁置了有关 Swift 提供的所有抽象承诺之后，让我们进一步详细讨论一下。高可用性和分布是使用“区域”概念以及将相同数据写入多个存储服务器的直接结果。区域只是一种简单的逻辑划分我们可用的存储资源的方式，并决定我们愿意提供的隔离类型以及我们需要的冗余类型。我们可以按照服务器本身、机架、数据中心内的服务器集、跨不同数据中心的组以及任何这些的组合来对服务器进行分组。一切都取决于可用资源的数量以及我们需要和想要的数据冗余和可用性，当然还有伴随我们配置的成本。

根据我们拥有的资源，我们应该根据它将我们的存储系统配置为它将保存多少副本以及我们准备使用多少区域。Swift 中特定数据对象的副本被称为副本，目前，最佳实践要求至少在不少于五个区域中拥有至少三个副本。

区域可以是服务器或一组服务器，如果我们正确配置了一切，失去任何一个区域对数据的可用性或分布都不会产生影响。由于区域可以小到一个服务器，大到任意数量的数据中心，我们构建区域的方式对系统对任何故障和变化的反应有巨大影响。副本也是如此。在推荐的方案中，配置的副本数量比区域数量少，因此只有一些区域将持有这些副本。这意味着系统必须平衡数据的写入方式，以均匀分布数据和负载，包括数据的写入和读取负载。同时，我们构建区域的方式将对成本产生巨大影响-冗余在服务器和存储硬件方面具有实际成本，而增加副本和区域会对我们 OpenStack 安装需要分配多少存储和计算能力提出额外要求。能够正确做到这一点是数据中心架构师必须解决的最大问题。

现在，我们需要回到最终一致性的概念。在这个背景下，最终一致性意味着数据将被写入 Swift 存储，并且对象将被更新，但系统将无法完全同时将所有数据写入所有副本中。Swift 将尽快协调差异，并意识到这些变化，因此为尝试读取它们的任何人提供对象的新版本。由于系统的某些部分失败而导致数据不一致的情况存在，但它们应被视为系统的异常状态，并需要修复，而不是系统被设计为忽略它们。

Swift 守护程序

接下来，我们需要讨论 Swift 在架构方面的设计。数据通过三个独立的逻辑守护程序进行管理：

• Swift-account用于管理包含所有定义的对象存储服务帐户的 SQL 数据库。它的主要任务是读取和写入所有其他服务需要的数据，主要是为了验证和查找适当的身份验证和其他数据。

• Swift-container是另一个数据库进程，但它严格用于将数据映射到容器中，这是一种类似于 AWS buckets的逻辑结构。这可以包括任意数量的对象，它们被分组在一起。

• Swift-object管理到实际对象的映射，并跟踪对象本身的位置和可用性。

所有这些守护程序都负责数据，并确保一切都被正确映射和复制。数据被架构的另一层使用：表示层。

当用户想要使用任何数据对象时，首先需要通过一个令牌进行身份验证，这个令牌可以是外部提供的，也可以是由 Swift 内部的身份验证系统创建的。之后，编排数据检索的主要过程是 Swift-proxy，它处理与处理数据的三个守护程序的通信。只要用户提供了有效的令牌，就可以将数据对象交付给用户请求。

这只是关于 Swift 工作原理的最简要的概述。为了理解这一点，你不仅需要阅读文档，还需要使用某种系统来执行低级对象的检索和存储到 Swift 中。

如果没有编排服务，云服务就无法扩展或高效使用，这就是为什么我们需要讨论我们列表上的下一个服务 - Nova。

Nova

另一个重要的服务或项目是 Nova - 一个编排服务，用于在大规模上提供计算实例的供应和管理。它的基本作用是允许我们使用 API 结构直接分配、创建、重新配置和删除或销毁虚拟服务器。以下是 Nova 服务结构的逻辑图：

图 12.6 - Nova 服务的逻辑结构（openstack.org）

大部分 Nova 是一个非常复杂的分布式系统，几乎完全由 Python 编写，包括一些执行编排部分的工作脚本和一个接收和执行 API 调用的网关服务。API 也是基于 Python 的；它是一个Web 服务器网关接口（WSGI）兼容的应用程序，用于处理调用。而 WSGI 则是定义 Web 应用程序和服务器应该如何交换数据和命令的标准。这意味着理论上，任何能够使用 WSGI 标准的系统也可以与这个服务建立通信。

除了这个多方面的编排解决方案，还有另外两个服务是 Nova 的核心 - 数据库和消息队列。这两者都不是基于 Python 的。我们将首先讨论消息传递和数据库。

几乎所有分布式系统都必须依赖队列来执行它们的任务。消息需要被转发到一个中央位置，这将使所有守护程序能够执行它们的任务，使用正确的消息传递和排队系统对于系统的速度和可靠性至关重要。Nova 目前使用 RabbitMQ，这是一个高度可扩展和可用的系统。使用这样一个生产就绪的系统意味着不仅有工具来调试系统本身，还有很多报告工具可用于直接查询消息队列。

使用消息队列的主要目的是完全解耦任何客户端和服务器，并在不同客户端之间提供异步通信。关于实际消息传递的工作有很多要说的，但在本章中，我们将只是引用官方文档docs.openstack.org/nova/latest/，因为我们不是在谈论服务器上的一些功能，而是一个完全独立的软件堆栈。

数据库负责保存当前正在执行的任务的所有状态数据，并使 API 能够返回有关 Nova 不同部分当前状态的信息。

总的来说，系统包括以下内容：

• nova-api实际上是指这个守护程序，有时称其为 API、控制器或云控制器。我们需要更详细地解释一下 Nova，以便理解将 nova-api 称为控制器是错误的，但由于守护程序中存在一个名为 CloudController 的类，许多用户将这个守护程序误认为是整个分布式系统。

nova-api 是一个强大的系统，因为它可以自行处理和整理一些 API 调用，从数据库获取数据并找出需要做什么。在更常见的情况下，nova-api 将只是启动一个任务，并以消息的形式转发给 Nova 内的其他守护程序。

• 另一个重要的守护程序是调度程序。它的主要功能是浏览队列，并确定特定请求应该在何时何地运行。这听起来足够简单，但鉴于系统可能的复杂性，这个“何时何地”可能导致性能的极端增益或损失。为了解决这个问题，我们可以选择调度程序在选择执行请求的正确位置时如何做出决策。用户可以选择编写自己的请求，也可以使用预定的请求。

如果我们选择 Nova 提供的存储卷，我们有三种选择：

a) 简单调度程序根据主机的负载确定请求将在哪里运行 - 它将监视所有主机，并尝试分配在特定时间片内负载最小的主机。

b) Chance是默认的调度方式。顾名思义，这是最简单的算法 - 从列表中随机选择一个主机并给出请求。

c) 区域调度也会随机选择主机，但是会在区域内进行选择。

现在，我们将看一下workers，实际执行请求的守护程序。这些守护程序有三个 - 网络、存储和计算。

• nova-network负责网络。它将执行与网络相关的队列中的任何任务，并根据需要创建接口和规则。它还负责 IP 地址分配；它将分配固定和动态分配的地址，并处理外部和内部网络。实例通常使用一个或多个固定 IP 来实现管理和连接，这些通常是本地地址。还有浮动地址用于从外部进行连接。自 2016 年 OpenStack Newton 版本发布以来，这项服务已经过时，尽管在一些传统配置中仍然可以使用。

• nova-volume 处理存储卷，或者更准确地说，处理数据存储与任何实例连接的所有方式。这包括诸如 iSCSI 和 AoE 之类的标准，这些标准旨在封装已知的常见协议，以及诸如 Sheepdog、LeftHand 和 RBD 之类的提供者，这些提供者涵盖了与开源和闭源存储系统（如 CEPH 或 HP LeftHand）的连接。

• nova-compute必须适应不同的虚拟化技术和完全不同的平台。它还需要能够动态分配和释放资源。主要使用 libvirt 进行 VM 管理，直接支持 KVM 创建和删除新实例。这就是本章存在的原因，因为 nova-compute 使用 libvirt 启动 KVM 机器是配置 OpenStack 的最常见方式，但对不同技术的支持范围更广。libvirt 接口还支持 Xen、QEMU、LXC 和用户模式 Linux（UML），通过不同的 API，nova-compute 可以支持 Citrix、XCP、VMware ESX/ESXi vSphere 和 Microsoft Hyper-V。这使得 Nova 能够从一个中央 API 控制所有当前使用的企业虚拟化解决方案。

作为一个旁注，nova-conductor 用于处理需要对对象、调整大小和数据库/代理访问进行任何转换的请求。

我们列表中的下一个服务是Glance - 这是对虚拟机部署非常重要的服务，因为我们希望从图像中进行部署。现在让我们讨论一下 Glance。

Glance

起初，为云磁盘图像管理单独设置一个服务似乎没有多大意义，但是在扩展任何基础架构时，图像管理将成为需要 API 解决的问题。Glance 基本上具有这种双重身份-它可以用于直接操作 VM 图像并将它们存储在数据块中，但同时也可以用于在处理大量图像时完全自动地编排许多任务。

Glance 在内部结构方面相对简单，因为它包括图像信息数据库，使用 Swift（或类似服务）的图像存储以及将所有内容粘合在一起的 API。数据库有时被称为注册表，它基本上提供了有关给定图像的信息。图像本身可以存储在不同类型的存储器上，可以是来自 Swift（作为 blob）的 HTTP 服务器上或文件系统（如 NFS）上。

Glance 对其使用的图像存储类型完全不加限制，因此 NFS 是完全可以的，并且使得实施 OpenStack 变得更加容易，但是在扩展 OpenStack 时，可以使用 Swift 和 Amazon S3。

当考虑 Glance 在大型 OpenStack 拼图中所属的位置时，我们可以将其描述为 Nova 用来查找和实例化图像的服务。Glance 本身使用 Swift（或任何其他存储）来存储图像。由于我们处理多种架构，因此需要支持图像的许多不同文件格式，而 Glance 并不令人失望。每种受不同虚拟化引擎支持的磁盘格式都受到 Glance 的支持。这包括无结构格式，如raw和结构化格式，如 VHD、VMDK、qcow2、VDI ISO 和 AMI。例如，作为图像容器的 OVF 也受到支持。

Glance 可能拥有所有 API 中最简单的 API，使其甚至可以使用 curl 从命令行查询服务器，并使用 JSON 作为消息的格式。

我们将以一条小提示直接从 Nova 文档中结束本节：它明确指出 OpenStack 中的一切都设计为水平可扩展，但是在任何时候，计算节点的数量应该明显多于任何其他类型。这实际上是有道理的-计算节点负责接受并处理请求。您将需要的存储节点数量将取决于您的使用场景，而 Glance 的数量将不可避免地取决于 Swift 可用的功能和资源。

排队中的下一个服务是Horizon - 一个 OpenStack 的人类可读GUI 仪表板，我们在那里消耗大量的 OpenStack 可视信息。

地平线

在相当详细地解释了使 OpenStack 能够以某种方式做到它所做的核心服务之后，我们需要解决用户交互的问题。在本章的几乎每一段中，我们都提到 API 和脚本接口作为与 OpenStack 通信和编排的方式。虽然这完全是真实的，并且是管理大规模部署的常规方式，但 OpenStack 还具有一个非常有用的界面，可以作为浏览器中的 Web 服务使用。这个项目的名称是 Horizon，它的唯一目的是为用户提供一种与所有服务进行交互的方式，称为仪表板。用户还可以重新配置 OpenStack 安装中的大多数（如果不是全部）内容，包括安全性、网络、访问权限、用户、容器、卷以及 OpenStack 安装中存在的其他所有内容。

Horizon 还支持插件和可插拔面板。Horizon 有一个活跃的插件市场，旨在扩展其功能，甚至比它已经具有的功能更进一步。如果这对您的特定情况仍然不够，您可以使用 Angular 创建自己的插件，并让它们在 Horizon 中运行。

可插拔面板也是一个不错的主意 - 在不改变任何默认设置的情况下，用户或一组用户可以改变仪表板的外观，并获得更多（或更少）呈现给他们的信息。所有这些都需要一点编码；更改是在配置文件中进行的，但主要的是 Horizon 系统本身支持这样的定制模型。在我们讨论安装 OpenStack 和创建 OpenStack 实例的配置 OpenStack 环境部分时，您可以了解更多关于界面本身和用户可用的功能。

正如您所知，没有名称解析，网络实际上无法正常工作，这就是为什么 OpenStack 有一个名为Designate的服务。我们接下来会简要讨论 Designate。

指定

任何使用任何类型网络的系统都必须至少有某种形式的名称解析服务，如本地或远程 DNS 或类似的机制。

Designate 是一项服务，试图在 OpenStack 中整合DNSaaS概念。当连接到 Nova 和 Neutron 时，它将尝试保持有关所有主机和基础设施详细信息的最新记录。

云的另一个非常重要的方面是我们如何管理身份。为此，OpenStack 有一个名为Keystone的服务。我们接下来会讨论它的作用。

Keystone

身份管理在云计算中非常重要，因为在部署大规模基础设施时，不仅需要一种方式来扩展资源，还需要一种方式来扩展用户管理。简单的用户访问资源的列表不再是一个选择，主要是因为我们不再谈论简单的用户。相反，我们谈论包含成千上万用户的域，由组和角色分隔 - 我们谈论多种登录和提供身份验证和授权的方式。当然，这也可能涉及多种身份验证标准，以及多个专门的系统。

出于这些原因，用户管理是 OpenStack 中名为 Keystone 的一个独立项目/服务。

Keystone 支持简单的用户管理和用户、组和角色的创建，但它也支持 LDAP、Oauth、OpenID Connect、SAML 和 SQL 数据库身份验证，并且有自己的 API，可以支持用户管理的各种场景。Keystone 是一个独立的世界，在本书中，我们将把它视为一个简单的用户提供者。然而，它可以是更多，可能需要根据情况进行大量配置。好消息是，一旦安装好，你很少需要考虑 OpenStack 的这一部分。

我们列表上的下一个服务是Neutron，这是 OpenStack 中（云）网络的 API/后端。

Neutron

OpenStack Neutron 是一个基于 API 的服务，旨在提供一个简单且可扩展的云网络概念，作为 OpenStack 旧版本中称为Quantum服务的发展。在这项服务之前，网络是由 nova-network 管理的，正如我们提到的，这是一个已经过时的解决方案，而 Neutron 正是这一变化的原因。Neutron 与我们已经讨论过的一些服务集成 - Nova、Horizon 和 Keystone。作为一个独立的概念，我们可以部署 Neutron 到一个单独的服务器，然后就可以使用 Neutron API。这让人想起了 VMware 在 NSX 中使用 NSX Controller 概念的做法。

当我们部署 neutron-server 时，一个托管 API 的基于 Web 的服务会与 Neutron 插件后台连接，以便我们可以对我们的 Neutron 管理的云网络进行网络更改。在架构方面，它有以下服务：

• 用于持久存储的数据库

• neutron-server

• 外部代理（插件）和驱动程序

在插件方面，它有很多，但这里是一个简短的列表：

• Open vSwitch

• Cisco UCS/Nexus

• Brocade Neutron 插件

• IBM SDN-VE

• VMware NSX

• Juniper OpenContrail

• Linux bridging

• ML2

• 还有很多其他的

大多数这些插件名称都是逻辑的，所以你不会有任何问题理解它们的作用。但我们想特别提到其中一个插件，即Modular Layer 2（ML2）插件。

通过使用 ML2 插件，OpenStack Neutron 可以连接到各种第 2 层后端 - VLAN、GRE、VXLAN 等。它还使 Neutron 摆脱了 Open vSwitch 和 Linux 桥插件作为其基本插件（现在已经过时）。这些插件被认为对于 Neutron 的模块化架构来说过于庞大，自 2013 年 Havana 发布以来，ML2 已完全取代了它们。今天，ML2 有许多基于供应商的插件用于集成。正如前面的列表所示，Arista、Cisco、Avaya、HP、IBM、Mellanox 和 VMware 都有基于 ML2 的 OpenStack 插件。

关于网络类别，Neutron 支持两种：

• 提供者网络：由 OpenStack 管理员创建，用于物理级别的外部连接，通常由平面（未标记）或 VLAN（802.1q 标记）概念支持。这些网络是共享的，因为租户使用它们来访问他们的私有基础设施在混合云模型中或访问互联网。此外，这些网络描述了底层和覆盖网络的交互方式，以及它们的映射关系。

• 租户网络，自助服务网络，项目网络：这些网络是由用户/租户及其管理员创建的，以便他们可以连接他们需要的任何形状或形式的虚拟资源和网络。这些网络是隔离的，通常由 GRE 或 VXLAN 等网络覆盖层支持，因为这就是租户网络的整个目的。

租户网络通常使用某种 SNAT 机制来访问外部网络，这项服务通常通过虚拟路由器实现。同样的概念也适用于其他云技术，如 VMware NSX-v 和 NSX-t，以及由网络控制器支持的 Microsoft Hyper-V SDN 技术。

在网络类型方面，Neutron 支持多种类型：

• Local：允许我们在同一主机内进行通信。

• Flat：未标记的虚拟网络。

• VLAN：一个 802.1Q VLAN 标记的虚拟网络。

• GRE，VXLAN，GENEVE：根据网络覆盖技术，我们选择这些网络后端。

现在我们已经介绍了 OpenStack 的使用模型、思想和服务，让我们讨论一下 OpenStack 可以被用于的其他方式。正如你所想象的，OpenStack - 作为它所是的东西 - 非常适合在许多非标准场景中使用。接下来我们将讨论这些非明显的场景。

其他 OpenStack 使用案例

OpenStack 在docs.openstack.org上有很多非常详细的文档。其中一个更有用的主题是架构和设计示例，它们都解释了使用场景和使用 OpenStack 基础设施解决特定场景的思想。当我们部署我们的测试 OpenStack 时，我们将讨论两种不同的边缘情况，但有些事情需要说一下关于配置和运行 OpenStack 安装。

OpenStack 是一个复杂的系统，不仅涵盖计算和存储，还涉及大量的网络和支持基础设施。当你意识到即使文档也被整齐地分成了管理、架构、运维、安全和虚拟机镜像指南时，你会首先注意到这一点。每个主题实际上都可以成为一本书的主题，指南涵盖的许多内容既是经验，又是最佳实践建议，也是基于最佳猜测的假设的一部分。

所有这些用例大致上有一些共同之处。首先，在设计云时，你必须尽早获取关于可能的负载和客户的所有信息，甚至在第一台服务器启动之前。这将使你能够计划不仅需要多少服务器，还有它们的位置、计算与存储节点的比例、网络拓扑、能源需求以及所有其他需要深思熟虑的事情，以创建一个可行的解决方案。

在部署 OpenStack 时，我们通常是出于以下三个原因之一部署大规模企业解决方案：

• 测试和学习：也许我们需要学习如何配置新的安装，或者在接近生产系统之前需要测试新的计算节点。因此，我们需要一个小型的 OpenStack 环境，也许是一个单独的服务器，如果有需要的话可以扩展。在实践中，这个系统应该能够支持一个用户和几个实例。这些实例通常不会成为你关注的焦点；它们只是为了让你能够探索系统的所有其他功能而存在。部署这样的系统通常是使用本章描述的方式完成的——使用一个现成的脚本来安装和配置一切，这样我们就可以专注于我们实际正在处理的部分。

• 我们需要一个暂存或预生产环境：通常，这意味着我们需要支持生产团队，让他们有一个安全的工作环境，或者我们正在尝试保留一个单独的测试环境，用于存储和运行实例，然后再推入生产环境。

拥有这样的环境是明确建议的，即使你还没有拥有它，因为它使你和你的团队能够在不担心破坏生产环境的情况下进行实验。缺点是，这种安装需要一个环境，必须为用户和他们的实例提供一些资源。这意味着我们不能只用一台服务器。相反，我们将不得不创建一个云，至少在某些部分，它要和生产环境一样强大。部署这样的安装基本上与生产部署相同，因为一旦它上线，从你的角度来看，这个环境将只是生产中的另一个系统。即使我们称其为预生产或测试，如果系统崩溃，你的用户必然会打电话抱怨。这与生产环境发生的情况相同；你必须计划停机时间，安排升级，并尽力使其尽可能地运行良好。

• 用于生产：这种方式要求另一种方式——维护。在创建实际的生产云环境时，您需要设计良好，然后仔细监视系统以便能够应对问题。从用户的角度来看，云是一种灵活的东西，因为它们提供了扩展和简单的配置，但作为云管理员意味着您需要通过准备好备用资源来启用这些配置更改。同时，您需要注意您的设备、服务器、存储、网络和其他一切，以便能够在用户看到问题之前发现问题。交换机是否故障转移？计算节点是否都正常运行？由于故障而导致磁盘性能下降了吗？在一个精心配置的系统中，这些事情中的每一件都对用户几乎没有或没有影响，但如果我们在处理问题时不主动，复合错误很快就会导致系统崩溃。

在两种不同的场景中区分了单个服务器和完整安装之后，我们将两者都进行一遍。单个服务器将使用脚本手动完成，而多服务器将使用 Ansible playbooks 完成。

现在我们已经相当详细地介绍了 OpenStack，是时候开始使用它了。让我们从一些小事情开始（测试一个小环境），以便为生产环境提供一个常规的 OpenStack 环境，然后讨论如何将 OpenStack 与 Ansible 集成。在下一章中，当我们开始讨论将 KVM 扩展到 Amazon AWS 时，我们将重新讨论 OpenStack。

为 OpenStack 创建一个 Packstack 演示环境

如果您只需要一个概念验证（POC），有一种非常简单的方法可以安装 OpenStack。我们将使用Packstack，因为这是最简单的方法。通过在 CentOS 7 上使用 Packstack 安装，您将能够在大约 15 分钟内配置 OpenStack。一切都始于一系列简单的命令：

yum update -y
yum install -y centos-release-openstack-train
yum update -y
yum install -y openstack-packstack
packstack --allinone

随着过程经历各种阶段，您将看到各种消息，例如以下消息，这些消息非常好，因为您可以实时查看发生的事情，具有相当不错的详细程度：

图 12.7 – 欣赏 Packstack 的安装详细程度

安装完成后，您将获得一个类似于此的报告屏幕：

图 12.8 – 成功的 Packstack 安装

安装程序已成功完成，并且它向我们发出了关于NetworkManager和内核更新的警告，这意味着我们需要重新启动系统。重新启动并检查/root/keystonerc_admin文件以获取我们的用户名和密码后，Packstack 已经准备就绪，我们可以通过使用上一个屏幕输出中提到的 URL（http://IP_or_hostname_where_PackStack_is_deployed/dashboard）进行登录：

图 12.9 – Packstack UI

还有一些额外的配置需要完成，如 Packstack 文档中所述wiki.openstack.org/wiki/Packstack。如果您要使用外部网络，您需要一个没有NetworkManager的静态 IP 地址，并且您可能要配置firewalld或完全停止它。除此之外，您可以开始将其用作演示环境。

为 OpenStack 环境进行配置

在创建第一个 OpenStack 配置时，最简单且最困难的任务之一将是配置。基本上有两种方法可以选择：一种是在精心准备的硬件配置中逐个安装服务，而另一种是只需使用 OpenStack 网站上的单服务器安装指南，创建一台作为测试平台的单台机器。在本章中，我们所做的一切都是在这样的实例中创建的，但在学习如何安装系统之前，我们需要了解其中的区别。

OpenStack 是一个云操作系统，其主要思想是使我们能够使用多台服务器和其他设备创建一个一致、易于配置的云，可以通过 API 或 Web 服务器从中心点进行管理。OpenStack 的部署规模和类型可以从运行所有内容的单个服务器到跨多个数据中心集成的数千台服务器和存储单元。OpenStack 在大规模部署方面没有问题；通常唯一的限制因素是我们尝试创建的环境的成本和其他要求。

我们多次提到了可扩展性，这正是 OpenStack 在两方面的闪光之处。令人惊奇的是，它不仅可以轻松扩展，而且还可以缩小规模。一个适用于单个用户的安装可以在单台机器上完成 - 甚至在单台机器内的单个虚拟机上完成 - 因此您将能够在笔记本电脑的虚拟环境中拥有自己的云。这对于测试很好，但其他用途不大。

在创建工作、可扩展的云时，遵循特定角色和服务的指南和推荐配置要求是前进的唯一途径，显然这也是在需要创建生产环境时的最佳选择。话虽如此，在单台机器和一千台服务器的安装之间，有很多方式可以塑造和重新设计您的基础架构，以支持您特定的用例场景。

让我们首先快速地在另一个虚拟机内进行安装，这是可以在更快的主机上在 10 分钟内完成的任务。对于我们的平台，我们决定安装 Ubuntu 18.04.3 LTS，以便将主机系统保持到最小。关于我们尝试做的事情，Ubuntu 的整个指南都可以在docs.openstack.org/devstack/latest/guides/single-machine.html上找到。

我们必须指出的一件事是，OpenStack 网站提供了一些不同安装方案的指南，无论是在虚拟还是裸机硬件上，它们都非常容易遵循，因为文档直截了当。一旦您手动完成了一些步骤，还有一个简单的安装脚本可以处理一切。

硬件要求要小心。有一些很好的资源可供参考。从这里开始：docs.openstack.org/newton/install-guide-rdo/overview.html#figure-hwreqs。

逐步安装 OpenStack

我们需要做的第一件事是创建一个将安装整个系统的用户。由于许多事情都需要系统范围的权限，这个用户需要具有sudo权限。

以 root 用户或通过sudo创建用户：

useradd -s /bin/bash -d /opt/stack -m stack
chmod 755 /opt/stack

接下来我们需要做的是允许这个用户使用sudo：

echo "stack ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

我们还需要安装git并切换到我们新创建的用户：

图 12.10 - 安装 git，部署 OpenStack 的第一步

现在是有趣的部分。我们将克隆（复制最新版本的）devstack，这是安装脚本，将为我们提供在此机器上运行和使用 OpenStack 所需的一切：

图 12.11 - 使用 git 克隆 devstack

现在需要一点配置。在我们刚刚克隆的目录中的samples目录中，有一个名为local.conf的文件。使用它来配置安装程序需要的所有内容。网络是必须手动配置的一件事 - 不仅是本地网络，它是将您连接到互联网的网络，还有内部网络地址空间，它将用于 OpenStack 实例之间需要执行的所有操作。还需要设置不同服务的不同密码。所有这些都可以在示例文件中阅读到。关于如何精确配置这些的说明既可以在我们之前给出的网址上找到，也可以在文件本身中找到：

图 12.12 - 安装程序配置

安装过程中可能会出现一些问题，因此由于以下原因，安装可能会出现两次中断：

• /opt/stack/.cache的所有权是root:root，而不是stack:stack。在运行安装程序之前，请更正此所有权；

• 安装程序问题（已知问题），因为它无法安装一个组件然后失败。解决方案相当简单 - 需要更改 inc 目录中名为 python 的文件中的一行。在撰写本文时，该文件的第 192 行需要从$cmd_pip $upgrade \更改为$cmd_pip $upgrade --ignore-installed \

最后，在收集了所有数据并修改了文件之后，我们确定了这个配置：

图 12.13 - 示例配置

这些参数中大多数是可以理解的，但让我们先讨论其中的两个：FLOATING_RANGE和FIXED_RANGE。FLOATING_RANGE参数告诉我们的 OpenStack 安装将使用哪个网络范围用于私有网络。另一方面，FIXED_RANGE是 OpenStack 配置的虚拟机将使用的网络范围。基本上，在 OpenStack 环境中配置的虚拟机将从FIXED_RANGE获得内部地址。如果虚拟机也需要从外部世界可用，我们将从FLOATING_RANGE分配一个网络地址。请注意FIXED_RANGE，因为它不应该与您的环境中现有的网络范围匹配。

我们从指南中所给出的内容中做出的一个改变是将 Swift 安装中的副本数减少到一个。这样做会使我们失去冗余，但会减少存储空间并加快速度。在生产环境中不要这样做。

根据您的配置，您可能还需要在文件中设置HOST_IP地址变量。在这里，将其设置为您当前的 IP 地址。

然后运行./stack.sh。

运行脚本后，一个非常冗长的安装过程将开始，并在屏幕上输出大量行。等待它完成 - 这将需要一段时间并从互联网下载大量文件。最后，它将给出一个安装摘要，看起来像这样：

图 12.14 - 安装摘要

完成后，如果一切正常，您应该在本地机器上拥有一个完整运行的 OpenStack 版本。为了验证这一点，使用 Web 浏览器连接到您的机器；应该出现一个欢迎界面：

图 12.15 - OpenStack 登录界面

使用安装后您机器上写的凭据登录（默认管理员名称是admin，密码是在安装服务时在local.conf中设置的密码），您将会看到一个显示云统计信息的屏幕。您看到的屏幕实际上是一个 Horizon 仪表板，是提供您一目了然的有关云的所有信息的主要屏幕。

OpenStack 管理

查看 Horizon 左上角，我们可以看到默认配置的三个不同部分。第一个 - 项目 - 包括有关默认实例及其性能的所有内容。在这里，您可以创建新实例、管理图像，并处理服务器组。我们的云只是一个核心安装，所以我们只有一个服务器和两个定义的区域，这意味着我们没有安装服务器组：

图 12.16 – 基本的 Horizon 仪表板

首先，让我们创建一个快速实例来展示如何完成这个过程：

图 12.17 – 创建实例

按照以下步骤创建一个实例：

1. 转到屏幕的最右侧的启动实例。将打开一个窗口，让您可以为 OpenStack 提供创建新 VM 实例所需的所有信息：

图 12.18 – 启动实例向导

1. 在下一个屏幕上，您需要提供图像来源。我们已经提到 glances - 这些图像来自 Glance 存储，并且可以是图像快照、现成的卷，或卷快照。如果需要的话，我们也可以创建一个持久图像。您会注意到，与几乎任何其他部署过程相比，有两个不同之处。首先，我们默认使用现成的图像，因为已经为我们提供了一个。另一个重要的事情是能够创建一个新的持久卷来存储我们的数据，或者在完成图像后将其删除，或者根本不创建它。

选择您在公共存储库中分配的一个图像；它应该与以下截图中显示的类似。CirrOS 是 OpenStack 提供的一个测试图像。它是一个被设计为尽可能小并且能够轻松测试整个云基础架构的最小 Linux 发行版，但尽可能不显眼。CirrOS 基本上是一个操作系统占位符。当然，我们需要点击启动实例按钮进入下一步：

图 12.19 – 选择实例来源

1. 创建新镜像的下一个重要部分是选择规格。这是 OpenStack 中另一个奇怪命名的东西。规格是某些资源的组合，基本上为新实例创建了一个计算、内存和存储模板。我们可以选择从具有最少 64MB RAM 和 1 vCPU 的实例开始，一直到我们的基础设施可以提供的程度：

图 12.20 – 选择实例规格

在这个特定的示例中，我们将选择cirros256，这是一种基本上设计为为我们的测试系统提供尽可能少的资源的规格。

1. 我们实际上需要选择的最后一件事是网络连接。我们需要设置实例在运行时可以使用的所有适配器。由于这是一个简单的测试，我们将使用我们拥有的两个适配器，即内部和外部适配器。它们被称为public和shared：

图 12.21 – 实例网络配置

现在，我们可以启动我们的实例，它将能够引导。一旦您点击启动实例按钮，创建新实例可能需要不到一分钟。在实例部署过程中，显示其当前进度和实例状态的屏幕将自动更新。

一旦完成，我们的实例将准备就绪：

图 12.22 - 实例已准备好

我们将快速创建另一个实例，然后创建一个快照，以便向您展示镜像管理的工作原理。如果您点击实例列表右侧的创建快照按钮，Horizon 将创建一个快照，并立即将您放入用于镜像管理的界面：

图 12.23 - 图像

现在，我们有两个不同的快照：一个是启动镜像，另一个是正在运行的镜像的实际快照。到目前为止，一切都很简单。那么从快照创建实例呢？只需点击一下！您需要做的就是点击右侧的启动实例按钮，然后按照创建新实例的向导进行操作。

我们短暂示例的实例创建的最终结果应该是这样的：

图 12.24 - 新实例创建完成

我们可以看到有关我们实例的所有信息，它们的 IP 地址是什么，它们的规格（这转化为为特定实例分配了多少资源），镜像正在运行的可用区域，以及当前实例状态的信息。我们接下来要检查的是左侧的卷选项卡。当我们创建实例时，我们告诉 OpenStack 为第一个实例创建一个永久卷。如果我们现在点击卷，我们应该会看到卷在一个数字名称下：

图 12.25 - 卷

从这个屏幕上，我们现在可以对卷进行快照，重新连接到不同的实例，甚至将其上传为镜像到存储库。

左侧的第三个选项卡名为网络，包含有关当前配置设置的更多信息。

如果我们点击网络拓扑选项卡，我们将得到当前运行网络的整个网络拓扑，显示在简单的图形显示中。我们可以选择拓扑和图形，两者基本上代表相同的东西：

图 12.26 - 网络拓扑

如果我们需要创建另一个网络或更改网络矩阵中的任何内容，我们可以在这里进行。我们认为这真的很适合管理员使用，而且也很适合文档使用。这两点使我们下一个主题 - 日常管理 - 变得更加容易。

日常管理

我们或多或少已经完成了与项目数据中心日常任务管理有关的最重要选项。如果我们点击名为管理的选项卡，我们会注意到我们打开的菜单结构看起来很像项目下的菜单结构。这是因为现在我们正在查看与云基础设施有关的管理任务，而不是与我们特定逻辑数据中心的基础设施有关，但这两者都存在相同的构建模块。然而，如果我们 - 例如 - 打开计算，会出现完全不同的选项集：

图 12.27 - 不同的可用配置选项

界面的这一部分用于完全管理构成我们基础设施的部分，以及定义我们在数据中心工作时可以使用的不同事物。当以用户身份登录时，我们可以添加和删除虚拟机，配置网络，并使用资源，但要上线资源，添加新的 hypervisors，定义规格，以及执行这些完全改变基础设施的任务，我们需要被分配管理角色。一些功能重叠，例如界面的管理部分和用户特定部分，它们都可以控制实例。然而，管理部分具有所有这些功能，用户可以调整其一组命令，例如无法删除或创建新实例。

管理视图使我们能够更直接地监视我们的节点，不仅通过它们提供的服务，还可以通过关于特定主机和其上使用的资源的原始数据：

图 12.28 - 数据中心中可用的 hypervisors

我们的数据中心只有一个 hypervisor，但我们可以看到其上物理可用资源的数量，以及当前设置在这一特定时刻使用的这些资源的份额。

规格也是 OpenStack 整体的重要组成部分。我们已经提到它们是预定义的资源预设集，形成实例将在其上运行的平台。我们的测试设置已经定义了一些规格，但我们可以删除此设置中提供的规格，并创建符合我们需求的新规格。

由于云的目的是优化资源管理，规格在这一概念中起着重要作用。在规划和设计方面，创建规格并不是一项容易的任务。首先，它需要深入了解在给定的硬件平台上可能发生的事情，甚至存在多少和什么样的计算资源，以及如何充分利用它。因此，我们需要妥善规划和设计。另一件事是，我们实际上需要了解我们正在为何种负载做准备。它是内存密集型的吗？我们是否有许多需要简单配置的节点的小服务？我们是否需要大量的计算能力和/或大量的存储？这些问题的答案不仅能让我们创建客户想要的东西，还能创建让用户充分利用我们基础设施的规格。

基本思想是创建规格，为个别用户提供足够的资源，以满足其工作需求。在拥有 10 个实例的部署中，这并不明显，但一旦我们遇到成千上万个实例，一个总是留下 10％存储空间未使用的规格将迅速消耗我们的资源，并限制我们为更多用户提供服务的能力。在规划和设计我们的环境中，找到我们拥有的资源和我们以特定方式提供给用户使用之间的平衡可能是最困难的任务：

图 12.29 - 创建规格向导

创建规格是一项简单的任务。我们需要做以下事情：

1. 给它一个名称；ID 将自动分配。

2. 为我们的规格设置 vCPU 和 RAM 的数量。

3. 选择基本磁盘的大小，以及一个临时磁盘，不包括在任何快照中，并在虚拟机终止时被删除。

4. 选择交换空间的大小。

5. 选择 RX/TX 因子，以便我们可以在网络级别创建一些 QoS。一些规格将需要比其他规格更高的网络流量优先级。

OpenStack 允许一个项目拥有多个规格，并且一个规格属于不同的项目。现在我们已经了解了这一点，让我们与用户身份一起工作，并为他们分配一些对象。

身份管理

左侧最后一个选项卡是身份，负责处理用户、角色和项目。在这里，我们不仅要配置我们的用户名，还要配置用户角色、组和用户可以使用的项目：

图 12.30 - 用户、组和角色管理

我们不会深入讨论用户是如何管理和安装的，只是涵盖用户管理的基础知识。与往常一样，OpenStack 网站上的原始文档是学习更多知识的好地方。确保您查看此链接：docs.openstack.org/keystone/pike/admin/cli-manage-projects-users-and-roles.html。

简而言之，一旦您创建了一个项目，您需要定义哪些用户能够查看和处理特定项目。为了简化管理，用户也可以成为组的一部分，然后您可以将整个组分配给一个项目。

这种结构的重点是使管理员不仅限制用户可以管理的内容，还限制特定项目可用的资源数量。让我们举个例子。如果我们转到项目并编辑一个现有项目（或创建一个新项目），我们将在配置菜单中看到一个名为配额的选项卡，它看起来像这样：

图 12.31 - 默认项目的配额

一旦您创建了一个项目，您可以将所有资源分配为配额的形式。这种分配限制了特定实例组的最大可用资源。用户无法查看整个系统；他们只能看到和利用通过项目可用的资源。如果用户是多个项目的一部分，他们可以根据其在项目中的角色创建、删除和管理实例，并且他们可用的资源是特定于项目的。

接下来，我们将讨论 OpenStack/Ansible 集成，以及这两个概念共同工作的一些潜在用例。请记住，OpenStack 环境越大，我们将为它们找到的用例就越多。

将 OpenStack 与 Ansible 集成

处理任何大规模应用程序都不容易，如果没有正确的工具，可能会变得不可能。OpenStack 为我们提供了许多直接编排和管理大规模水平部署的方式，但有时这还不够。幸运的是，在我们的工具库中，我们还有另一个工具 - Ansible。在第十一章，用于编排和自动化的 Ansible中，我们介绍了一些其他使用 Ansible 部署和配置单个机器的较小方式，因此我们不会回到那里。相反，我们将专注于 Ansible 在 OpenStack 环境中的优势。

有一件事我们必须搞清楚，那就是在 OpenStack 环境中使用 Ansible 可以基于两种非常不同的场景。一种是使用 Ansible 来处理部署的实例，这在所有其他云或裸金属部署中看起来几乎是一样的。作为大量实例的管理员，您创建一个管理节点，它只是一个启用 Python 的服务器，添加了 Ansible 软件包和 playbooks。之后，您整理部署清单，准备好管理您的实例。这种情况不是本章的重点。

我们在这里讨论的是使用 Ansible 来管理云本身。这意味着我们不是在 OpenStack 云内部部署实例；我们是为 OpenStack 本身部署计算和存储节点。

我们所说的环境有时被称为OpenStack-Ansible（OSA），并且足够常见，以至于有自己的部署指南，位于以下 URL：docs.openstack.org/project-deploy-guide/openstack-ansible/latest/。

在 OpenStack-Ansible 中，最小安装的要求要比单个 VM 或单台机器上的要求大得多。这不仅是因为系统需要所有资源；还有需要使用的工具和背后的哲学。

让我们快速了解 Ansible 在 OpenStack 方面的含义：

• 一旦配置完成，它就能快速部署任何类型的资源，无论是存储还是计算。

• 它确保您在过程中没有忘记配置某些内容。在部署单个服务器时，您必须确保一切正常，并且配置错误易于发现，但在部署多个节点时，错误可能会潜入并降低系统的性能，而没有人注意到。避免这种情况的正常部署实践是安装清单，但 Ansible 比那更好。

• 更简化的配置更改。有时，我们需要对整个系统或其中的一部分应用配置更改。如果没有脚本化，这可能会很令人沮丧。

因此，说了这么多，让我们快速浏览一下docs.openstack.org/openstack-ansible/latest/，看看官方文档对如何部署和使用 Ansible 和 OpenStack 的建议。

OpenStack 在 Ansible 方面为管理员提供了什么？最简单的答案是 playbooks 和 roles。

要使用 Ansible 部署 OpenStack，基本上需要创建一个部署主机，然后使用 Ansible 部署整个 OpenStack 系统。整个工作流程大致如下：

1. 准备部署主机

2. 准备目标主机

3. 为部署配置 Ansible

4. 运行 playbooks 并让它们安装所有内容

5. 检查 OpenStack 是否正确安装

当我们谈论部署和目标主机时，我们需要明确区分：部署主机是一个单一实体，包含 Ansible、脚本、playbooks、角色和所有支持的部分。目标主机是实际将成为 OpenStack 云一部分的服务器。

安装的要求很简单：

• 操作系统应该是 Debian、Ubuntu CentOS 或 openSUSE（实验性）的最小安装，具有最新的内核和完整的更新。

• 系统还应该运行 Python 2.7，启用 SSH 访问并进行公钥身份验证，并启用 NTP 时间同步。这涵盖了部署主机。

• 不同类型的节点也有通常的建议。计算节点必须支持硬件辅助虚拟化，但这是一个明显的要求。

• 还有一个应该不言而喻的要求，那就是使用多核处理器，尽可能多的核心，以加快某些服务的运行速度。

磁盘要求真的取决于你。OpenStack 建议尽可能使用快速磁盘，建议在 RAID 中使用 SSD 驱动器，并为块存储提供大型磁盘池。

• 基础设施节点有不同于其他类型节点的要求，因为它们运行一些随时间增长并且需要至少 100 GB 空间的数据库。基础设施还以容器形式运行其服务，因此它将以与其他计算节点不同的方式消耗资源。

部署指南还建议运行日志主机，因为所有服务都会创建日志。推荐的磁盘空间至少为 50 GB，但在生产环境中，这将迅速增长数量级。

OpenStack 需要一个快速、稳定的网络才能正常工作。由于 OpenStack 中的所有内容都依赖于网络，建议使用任何可能加快网络访问速度的解决方案，包括使用 10G 和绑定接口。安装部署服务器是整个过程的第一步，因此我们将在下一步进行。

安装 Ansible 部署服务器

我们的部署服务器需要及时更新所有升级，并安装 Python、git、ntp、sudo和ssh支持。安装所需的软件包后，您需要配置ssh密钥以便能够登录到目标主机。这是 Ansible 的要求，也是一种利用安全性和便利性的最佳实践。

网络很简单-我们的部署主机必须与所有其他主机保持连接。部署主机还应安装在网络的 L2 上，该网络专为容器管理而设计。

然后，应该克隆存储库：

# git clone -b 20.0.0 https://opendev.org/openstack/openstack-ansible /opt/openstack-ansible

接下来，需要运行一个 Ansible 引导脚本：

# scripts/bootstrap-ansible.sh

这就完成了准备 Ansible 部署服务器的工作。现在，我们需要准备要用于 OpenStack 的目标计算机。目标计算机目前支持 Ubuntu Server（18.04）LTS、CentOS 7 和 openSUSE 42.x（在撰写本文时，仍然没有 CentOS 8 支持）。您可以使用这些系统中的任何一个。对于每个系统，都有一个有用的指南，可以帮助您快速上手：docs.openstack.org/project-deploy-guide/openstack-ansible/latest/deploymenthost.html。我们将解释一般步骤以便您轻松安装，但实际上，只需从www.openstack.org/复制并粘贴已发布的命令即可。

无论您决定在哪个系统上运行，都必须完全更新系统更新。之后，安装linux-image-extra软件包（如果适用于您的内核），并安装bridge-utils、debootstrap、ifenslave、lsof、lvm2、chrony、openssh-server、sudo、tcpdump、vlan和 Python 软件包。还要启用绑定和 VLAN 接口。所有这些东西可能适用于您的系统，也可能不适用，因此如果某些内容已安装或配置，只需跳过即可。

在chrony.conf中配置 NTP 时间同步，以在整个部署中同步时间。您可以使用任何时间源，但为了系统正常工作，时间必须同步。

现在，配置ssh密钥。Ansible 将使用ssh和基于密钥的身份验证进行部署。只需将部署机器上适当用户的公钥复制到/root/.ssh/authorized_keys。通过从部署主机登录到目标机器来测试此设置。如果一切正常，您应该能够无需任何密码或其他提示登录。还要注意，部署主机上的 root 用户是管理所有内容的默认用户，并且他们必须提前生成他们的ssh密钥，因为它们不仅用于目标主机，还用于系统中运行的所有不同服务的所有容器。在开始配置系统时，这些密钥必须存在。

对于存储节点，请注意 LVM 卷将在本地磁盘上创建，从而覆盖任何现有配置。网络配置将自动完成；您只需确保 Ansible 能够连接到目标机器即可。

下一步是配置我们的 Ansible 清单，以便我们可以使用它。让我们现在就做。

配置 Ansible 清单

在我们运行 Ansible playbooks 之前，我们需要完成配置 Ansible 清单，以便将系统指向应该安装的主机。我们将引用docs.openstack.org/project-deploy-guide/openstack-ansible/queens/configure.html上提供的原文：

1. 将/opt/openstack-ansible/etc/openstack_deploy 目录的内容复制到

/etc/openstack_deploy 目录。

2. 切换到/etc/openstack_deploy 目录。

3. 将 openstack_user_config.yml.example 文件复制到

/etc/openstack_deploy/openstack_user_config.yml。

4. 回顾 openstack_user_config.yml 文件并对部署进行更改

你的 OpenStack 环境。

进入配置文件后，审查所有选项。Openstack_user_config.yml定义了哪些主机运行哪些服务和节点。在承诺安装之前，请查看前一段提到的文档。

网上突出的一件事是install_method。你可以选择源或发行版。每种方法都有其优缺点：

• 源是最简单的安装方式，因为它直接从 OpenStack 官方网站的源代码中完成，并包含与所有系统兼容的环境。

• 发行版方法是根据你正在安装的特定发行版定制的，使用已知可行且稳定的特定软件包。这样做的主要缺点是更新速度会慢得多，因为不仅需要部署 OpenStack，还需要关于发行版上所有软件包的信息，并且需要验证该设置。因此，预计在升级到源并到达发行版安装之间会有很长的等待时间。安装后，您必须选择您的首选项；没有从一个选择切换到另一个的机制。

你需要做的最后一件事是打开user_secrets.yml文件，并为所有服务分配密码。您可以创建自己的密码，也可以使用专门为此目的提供的脚本。

运行 Ansible playbooks

在我们进行部署过程时，我们需要启动一些 Ansible playbooks。我们需要按照以下顺序使用这三个提供的 playbooks：

• setup-hosts.yml：我们用来在 OpenStack 主机上提供必要服务的初始 Ansible playbook。

• setup-infrastructure.yml：部署一些其他服务的 Ansible playbook，如 RabbitMQ、仓库服务器、Memcached 等等。

• setup-openstack.yml：部署剩余服务的 Ansible playbook——Glance、Cinder、Nova、Keystone、Heat、Neutron、Horizon 等等。

所有这些 Ansible playbooks 都需要成功完成，以便我们可以将 Ansible 与 Openstack 集成。所以，唯一剩下的就是运行 Ansible playbooks。我们需要从以下命令开始：

# openstack-ansible setup-hosts.yml

您可以在/opt/openstack-ansible/playbooks中找到适当的文件。现在，运行剩下的设置：

# openstack-ansible setup-infrastructure.yml
# openstack-ansible setup-openstack.yml

所有 playbooks 都应该在没有不可达或失败的情况下完成。有了这个——恭喜！你刚刚安装了 OpenStack。

总结

在本章中，我们花了很多时间描述了 OpenStack 的架构和内部工作原理。我们讨论了软件定义的网络及其挑战，以及不同的 OpenStack 服务，如 Nova、Swift、Glance 等等。然后，我们转向实际问题，比如部署 Packstack（让我们称之为 OpenStack 的概念验证），以及完整的 OpenStack。在本章的最后部分，我们讨论了 OpenStack-Ansible 集成以及在更大的环境中可能对我们意味着什么。

现在我们已经涵盖了私有云方面，是时候扩展我们的环境，将其扩展到更公共或混合的方式。在基于 KVM 的基础设施中，这通常意味着连接到 AWS，将您的工作负载转移到那里（公共云）。如果我们讨论混合类型的云功能，则必须介绍一个名为 Eucalyptus 的应用程序。关于如何和为什么，请查看下一章。

问题

1. VLAN 作为云覆盖技术的主要问题是什么？

2. 目前云市场上使用的云覆盖网络类型有哪些？

3. VXLAN 是如何工作的？

4. 跨多个站点延伸 Layer 2 网络的一些常见问题是什么？

5. 什么是 OpenStack？

6. OpenStack 的架构组件是什么？

7. 什么是 OpenStack Nova？

8. 什么是 OpenStack Swift？

9. 什么是 OpenStack Glance？

10. 什么是 OpenStack Horizon？

11. OpenStack 的 flavors 是什么？

12. 什么是 OpenStack Neutron？

进一步阅读

请参考以下链接，了解本章涵盖的更多信息：

• OpenStack 文档：docs.openstack.org

• Arista VXLAN 概述：www.arista.com/assets/data/pdf/Whitepapers/Arista_Networks_VXLAN_White_Paper.pdf

• 红帽 - 什么是 GENEVE？：www.redhat.com/en/blog/what-geneve

• 思科 - 使用 OpenStack 配置虚拟网络：www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/kvm/config_guide/network/5x/b_Cisco_N1KV_KVM_Virtual_Network_Config_5x/configuring_virtual_networks_using_openstack.pdf

• Packstack：rdoproject.org

第十三章：使用 AWS 扩展 KVM

如果你仔细观察，虚拟化是一个棘手的问题 - 模拟完整的计算机以便能够在其上运行操作系统是复杂的。出于明显的原因，将这些虚拟机放入云中甚至更加困难。之后，事情真的开始变得混乱。从概念上讲，创建能够按需运行的机器集群更加复杂，基于必须同时运行的机器数量之多。此外，不仅需要创建模拟计算机，还需要创建支持更大规模部署的所有网络和基础设施。创建一个全球云 - 不仅运行数百万台机器，而且几乎无处不在，甚至在地球上最偏远的地方 - 是少有公司尝试过的任务，只有少数公司成功。本章将总体介绍这些大型云提供商，然后介绍亚马逊作为其中最大的云提供商。我们的主要想法是介绍亚马逊的运作方式，它与本书中涵盖的其他主题的关系，以及如何在现实世界的真实机器上使用亚马逊提供的服务。

亚马逊网络服务（AWS）是一组独特的工具、服务和基础设施，可以在非常大规模上实现云服务，规模之大几乎难以理解。当我们谈论成千上万的站点使用数百万台服务器运行数十亿的应用程序时，甚至列举这些事物都成为一个大问题，管理是一件不仅可以跨越单一章节，而且可能需要多本书的事情。我们将尝试向您介绍 AWS 云的最重要的服务和部分，并尝试解释它们可以用于什么以及何时使用。

在本章中，我们将涵盖以下主题：

• AWS 简介

• 为 AWS 准备和转换虚拟机

• 使用 Eucalyptus 构建混合 KVM 云

AWS 简介

在谈论云服务时，AWS 几乎不需要介绍，尽管很少有人真正了解整个亚马逊云系统有多么庞大和复杂。完全可以肯定的是，目前它无疑是地球上最大和最常用的服务。

在我们做任何其他事情之前，我们需要谈谈 AWS 为什么如此重要，不仅是因为它对互联网的影响，还因为它对任何试图提供某种规模的任务的影响。

正如我们在本书中已经做了几次，我们将从 AWS 云的基本前提开始 - 提供一个广泛可扩展和分布式的解决方案，涵盖互联网上执行任何类型的工作负载的所有可能场景。

在本书的几乎每个其他地方，我们提到云时，我们都谈到了扩展，但当我们试图描述 AWS 能够扩展时，我们谈论的可能是地球上最大的和最常用的容量和可扩展性提供商之一。

目前，互联网上有四个真正大的云提供商：AWS、微软 Azure、谷歌云平台和阿里巴巴。由于所有数字出于商业原因是保密的，它们可以提供的服务器数量和纯粹的容量是分析师试图估计，或更频繁地是猜测的，但必须是以百万计。

接近云

尽管在表面上它们现在在争夺同一个云市场，但所有参与者都来自不同的背景，即使现在他们使用基础设施的方式也大不相同。在这个市场上，亚马逊是第一家，它在 IT 领域似乎几乎不可思议地领先了大约 6 年。亚马逊于 2006 年推出了其亚马逊网络服务，但它在几年前就开始了该服务的开发。甚至有一篇博客文章提到了 2004 年发布的该服务。 AWS 的想法基本上是在亚马逊意识到它拥有一个在市场上无与伦比的庞大基础设施后构想出来的，通过扩大基础设施并将其作为服务提供，它可以获利。当时，他们拥有的基础设施被用来提供 Amazon.com 服务。

这个想法与市场上的任何东西都不同。人们习惯于在数据中心中拥有共同的计算机，并能够租用云中的服务器，但租用他们需要的堆栈的一部分而不是整个硬件基础设施的概念是新的。 AWS 提供的第一个重要服务非常简单，甚至被命名为简单存储服务（S3），以及弹性计算云（EC2）。 S3 基本上是云支持的存储，为那些能够支付的人提供了几乎无限的存储资源，几乎与今天的方式相同。 EC2 提供了计算资源。

在接下来的 6 年里，提供的服务扩展到了内容传送网络（CDN）等等，而竞争对手仍在努力理解云的实际含义。

我们稍后会回到 AWS 提供的服务，但只在提到它们最终在这个每年价值数百亿美元的市场中得到的竞争之后。

微软意识到，它需要建立基础设施来支持自己和客户，这是在 2000 年代后期的某个时候。微软已经有自己的业务支持基础设施来运行公司，但当时并没有向普通公众提供公共服务。这一切在 2010 年微软 Azure推出后发生了变化。最初它被称为Windows Azure，主要用于为微软及其合作伙伴提供服务，主要是在 Windows 上。 微软很快意识到，仅在云中提供微软操作系统将会让他们失去很多客户，因此还提供了 Linux 作为可安装和使用的操作系统。

Azure 现在作为一个公开可用的云运行，但它的很大一部分仍然被微软及其服务所使用，尤其是Office 365和大量的微软培训和营销解决方案。

另一方面，谷歌以不同的方式进入市场。他们也意识到云服务的需求，但将他们与云的第一次接触限制在提供一个名为App Engine的单一服务上，这是在 2008 年。这是一个面向 Web 开发者社区的服务，谷歌甚至为该服务的有限使用提供了 10,000 个免费许可证。在本质上，这项服务以及之后推出的几乎所有服务都是基于这样的前提，即网络需要能够让开发人员快速部署可能会扩展或可能不会工作的东西。因此，免费提供意味着很多开发人员倾向于仅用于简单测试。

谷歌现在也提供了大量的服务，但当你从外部看实际的服务和定价时，似乎谷歌创建了它的云来租用其数据中心中可用的额外容量。

多云

回顾几年前，Azure 和 Google Cloud Platform 都有一个可行的云服务，但与 AWS 提供的服务相比，它们的服务根本不匹配。AWS 是最大的参与者，无论是市场份额还是人们的心目中。Azure 被认为更多是面向微软的，尽管其上运行的服务器有一半以上是基于 Linux 的，而 Google 则不被视为竞争对手；他们的云看起来更像是一个副业而不是一个可行的云运行提案。

然后出现了多云。这个想法很简单 - 不要使用单一的云来部署您的服务；使用多个云提供商来提供数据冗余、可用性和故障转移，最重要的是成本降低和灵活性。这可能听起来很奇怪，但在使用云服务时最大的成本之一是将数据从中取出。通常情况下，将数据上传到云中，或者在服务器上部署数据，要么是免费的，要么成本极低，这是有道理的，因为如果您在线上有大量数据，您更有可能在这个特定的云上使用更多的服务。一旦您需要提取数据，成本就会变得很高。这是有意为之的，它使用户被锁定在云提供商那里。一旦您上传了数据，将其保留在服务器上而不尝试离线处理它要便宜得多。但在谈论多云时，不仅要考虑数据，服务也是方程式的一部分。

为什么要使用多云策略？

许多公司（我们必须强调，多云用户大多是大公司，因为涉及到成本）害怕被锁定在特定的平台或技术上。其中最大的问题之一是，如果平台发生了如此大的变化，以至于公司必须重新设计其基础设施，会发生什么？想象一下，您是一家价值数十亿美元的公司，为数十万自己的用户运行企业应用程序。您选择云的原因通常是为了降低资本支出并能够扩展您的服务。您决定选择其中一个大型提供商。突然间，您的提供商决定要改变技术，并将逐步淘汰基础设施的某些部分。在这种情况下，通常意味着您当前的设置将变得更加昂贵，或者您将失去一些可用功能的一部分。幸运的是，这些事情通常会延伸数年，因为没有一个理智的云提供商会在一夜之间进行战略性的改变。

但是变化就是变化，作为一家公司，您有选择 - 留在提供商那里并面对系统价格大幅上涨的后果 - 或者重新设计系统，这也将花费金钱，并可能需要数年才能完成 - 有时甚至数十年。

因此，许多公司选择了一种非常保守的策略 - 设计一个可以在任何云上运行的系统，这意味着使用所有可用技术的最低公共分母。这也意味着该系统可以在几天内从一个云迁移到另一个云。其中一些公司甚至决定同时在不同的云上运行系统。这是一种极端保守的方法，但它是有效的。

使用多云策略的另一个重要原因与我们刚才提到的完全相反。有时，想法是使用特定的云服务或服务来完成非常专业的任务。这意味着选择来自不同提供商的不同服务来执行不同的任务，但要尽可能高效地完成。从长远来看，这也意味着不时地必须更换提供商和系统，但如果公司使用的核心系统是以此为考虑而设计的，这种方法也是有好处的。

Shadow IT

还有另一种方式，公司可以成为一个多云环境，甚至不知道它，这通常被称为“影子 IT”。如果公司没有严格的安全政策和规定，一些员工可能会开始使用公司未提供的服务。这可能是云存储容器、视频会议系统或邮件列表提供商。在大公司中，甚至可能是整个部门开始使用来自不同云提供商的东西，甚至没有意识到。突然之间，公司数据存储在公司 IT 范围之外或无法覆盖的服务器上。

这种现象的一个更好的例子是 COVID-19 病毒全球大流行期间视频会议服务的使用方式发生了变化。几乎所有公司都有一个成熟的通信系统，通常是覆盖整个公司的消息系统。然后，一夜之间，大流行将所有工人都留在家中。由于沟通是公司运营的关键，每个人决定在一周内全球切换到视频和音频会议。接下来发生的事情可能会成为畅销书的主题。大多数公司试图坚持他们的解决方案，但几乎普遍地，这一尝试在第一天就失败了，要么是因为服务太基本或太过时，无法用作音频和视频会议解决方案，要么是因为服务没有设计用于如此大量的呼叫和请求而崩溃。

人们想要协调，所以突然之间一切都成了可能。每一个视频会议解决方案突然都成了候选。公司、部门和团队开始尝试不同的会议系统，云提供商很快意识到了这个机会——几乎所有服务立即对于规模可观的部门来说都是免费的，有些情况下，甚至允许多达 150 人参加会议。

由于需求激增，很多服务崩溃了，但大型提供商大多能够扩展到所需的规模以保持一切运转。

由于大流行是全球性的，很多人决定他们也需要一种与家人交流的方式。因此，个人用户开始在家使用不同的服务，当他们决定某种服务有效时，他们也在工作中使用它。在几天内，公司变成了一个多云环境，人们使用一个提供商进行通信，另一个提供商进行电子邮件，第三个提供商进行存储，第四个提供商进行备份。变化如此之快，以至于有时 IT 在系统上线后几天才被告知变化，而人们已经在使用它们。

这种变化如此巨大，以至于在我们写这本书的时候，我们甚至无法预测有多少这些服务将成为公司工具组合的常规部分，一旦用户意识到某些东西比公司提供的软件更好用。这些服务通过能够在这样的重大灾难中持续工作进一步证明了这一点，因此公司范围的软件使用政策对于阻止这种混乱的多云方法能做的事情是有限的。

市场份额

每当提到云计算公司和服务时，每个人都会提到它们的市场份额。我们也需要解决这一点，因为我们说过我们在谈论“最大的”或“第二大”的。在多云成为一种趋势之前，市场份额基本上分为亚马逊 AWS 占据最大市场份额；微软 Azure 居于遥远的第二位；其次是谷歌和一大群“小”提供商，如阿里巴巴、甲骨文、IBM 等。

一旦多云成为一种趋势，最大的问题就是如何确定谁拥有最大的实际市场份额。所有大公司开始使用不同的云服务提供商，而简单地尝试累加提供商的市场份额变得困难。从不同的调查中可以清楚地看出，亚马逊仍然是领先的提供商，但公司们慢慢开始与亚马逊服务一起使用其他提供商。

这意味着，目前，AWS 仍然是首选的云服务提供商，但选择本身不再仅限于单一提供商。人们也在使用其他提供商。

大型基础设施但没有服务

有时，试图划分市场份额还有另一个必须考虑的观点。如果我们谈论云服务提供商，通常认为我们在谈论拥有最大基础设施来支持云服务的公司。有时，实际上，我们实际上在比较那些在市场上拥有最大服务组合的公司。我们指的是什么？

有一个明显的公司拥有庞大的云存在，但几乎完全使用自己的基础设施来提供自己的内容 - Facebook。尽管很难通过服务器数量、数据中心或任何其他指标来比较基础设施的规模，因为这些数字是严格保密的，但 Facebook 的基础设施规模与 AWS 相当。真正的区别在于，这种基础设施不会为第三方提供服务，实际上，它从来就不是为此而设计的；Facebook 创建的一切都是为了支持自身，包括选择数据中心的位置、配置和部署硬件以及创建软件。Facebook 不会突然变成另一个 AWS；它太大了。可用的基础设施并不总是与云市场份额相关。

定价

另一个我们必须涵盖的话题，即使只是提及，就是定价。本书中几乎每次提到云都是技术性的。我们比较了可能有意义的每一个指标，从IOPS，通过GHz，到网络端的PPS，但云不仅仅是一个技术问题 - 当你必须将其投入使用时，有人必须为此付费。

定价是云世界中的热门话题，因为竞争激烈。所有云服务提供商都有他们的定价策略，折扣和特别交易几乎成为常态，所有这些使得理解定价变成一场噩梦，特别是对于那些对所有不同模式都是新手的人。有一点是确定的，所有提供商都会说他们只会按照你的使用量收费，但是定义他们实际指的是什么可能会成为一个大问题。

在开始规划部署成本时，你应该首先停下来，尝试定义你需要什么，你需要多少，以及你是否正在以云的方式使用它。迄今为止最常见的错误是认为云在任何形式上都类似于使用普通服务器。人们首先注意到的是特定实例在特定数据中心运行特定配置的价格。价格通常要么是实例的月费用，并且通常是按比例计算的，因此你只支付你使用的部分，要么价格是以不同的时间单位给出 - 每天、每小时，甚至每秒。这应该是你的第一个线索：你支付使用实例的费用，因此为了降低成本，不要让你的实例一直运行。这也意味着你的实例必须被设计成可以根据需求快速启动和关闭，因此使用安装单个或多个服务器并一直运行它们的标准方法在这里不一定是一个好选择。

在选择实例时，选项实在太多，这里无法一一列举。所有的云提供商都有自己关于人们需求的想法，所以你不仅可以选择简单的东西，比如处理器数量或内存量，还可以获得预安装的操作系统，以及各种各样的存储和网络选项。存储是一个特别复杂的话题，我们在这里只是简单地触及一下，并且稍后再提及。所有的云提供商都提供两种东西 - 一些用于连接到实例的存储，以及一些用作服务的存储。一个给定的提供商提供的东西可能取决于你尝试请求的实例，你尝试在其中请求的数据中心，以及其他一些因素。预期你将不得不平衡三件事：容量、定价和速度。当然，在这里，我们谈论的是实例存储。作为服务的存储更加复杂，你不仅需要考虑定价和容量，还需要考虑其他因素，比如延迟、带宽等等。

例如，AWS 让你可以选择各种服务，从数据库存储、文件存储和长期备份存储，到不同类型的块和对象存储。为了最佳地使用这些服务，你需要首先了解提供了什么，以什么方式提供，涉及了哪些不同的成本，以及如何利用它们。

你会很快注意到的另一件事是，当云提供商说一切都是服务时，他们是认真的。完全有可能运行一个应用程序而没有一个单独的服务器实例。通过将不同的服务拼接在一起可以完成任务，这是有意设计的。这创造了一个极其灵活的基础设施，一个可以快速、轻松扩展的基础设施，但不仅需要一种不同的编写代码的方式，还需要一种完全不同的思维方式来设计你需要的解决方案。如果你没有经验，找一个专家，因为这是你解决方案的根本问题。它必须在云上运行，而不是在云中的虚拟机上运行。

我们给你的建议很简单 - 多读文档。所有的提供商都有出色的资源，可以让你了解他们的服务提供了什么，以及如何提供，但这些数千页的文档不会告诉你它与竞争对手相比如何，更重要的是，连接服务的最佳方式是什么。在支付云服务时，预期你会偶尔犯错并为此付费。这就是为什么在部署服务时使用按需付费选项是有用的 - 如果你犯了一个错误，你不会产生巨额账单；你的基础设施将会停止。

谈到定价时要提及的另一件事是，一切都有一点成本，但给定配置的综合价格可能会很高。任何额外的资源都会花钱。服务器之间的内部链接，外部 IP 地址，防火墙，负载均衡器，虚拟交换机，这些通常在设计基础设施时我们甚至都不会考虑的东西，但一旦我们在云中需要它们，它们就会变得昂贵。另一个要预料的事情是，一些服务有不同的上下文 - 例如，如果你在实例之间传输数据或者传输到外部世界，网络带宽的价格可能会不同。存储也是一样 - 正如我们在本章前面提到的，大多数提供商在存储和从云中获取数据时会向你收取不同的价格。

数据中心

在本章中，我们已经几次提到了数据中心，重要的是我们谈一下它们。数据中心是云基础设施的核心，而且方式远不止你所想的那样。当我们谈论大量服务器时，我们提到我们通常将它们分组放入机架，并将机架放入数据中心。你可能知道，数据中心本质上是一组带有所有服务器需要的基础设施的机架，无论是在电源和数据方面，还是在冷却、保护和保持服务器运行所需的其他方面。它们还需要被逻辑地划分为我们通常称之为“故障域”的“风险区域”，以便我们可以避免与“我们把所有东西都部署在一个机架上”或“我们把所有东西都部署在一个物理服务器上”的各种风险相关的问题。

在任何情况下，数据中心都是复杂的基础设施元素，因为它需要一系列因素的组合才能高效、安全和冗余。将一组服务器放入机架中是相当容易的，但提供冷却和电源却不是一件简单的任务。此外，如果你想让你的服务器工作，冷却、电源和数据都必须是冗余的，而且所有这些都需要保护，不仅免受火灾、洪水、地震和人为破坏，而且真正运行数据中心的成本可能很高。当然，运行几百台服务器的数据中心并不像运行数千台甚至数万台的数据中心那样复杂，而且随着设施规模的增加，价格也会上涨。此外，拥有多个数据中心会在连接它们时产生额外的基础设施挑战，因此成本会不断增加。

现在将这个成本乘以一百，因为这是每个云提供商在世界各地保留的数据中心数量。一些中心很小，一些很大，但游戏的名字很简单——网络。为了成为一个真正的全球提供商，所有这些中心都必须有一个数据中心，或者至少有几台服务器，尽可能靠近你。如果你正在世界上几乎任何一个大国家的大城市中阅读这篇文章，很可能在你的 100 英里半径范围内有一个亚马逊、微软或谷歌拥有的服务器。所有提供商都努力在每个大城市的每个国家至少有一个数据中心，因为这可以让他们极快地提供一系列服务。这个概念被称为接触点（POC），意味着当连接到提供商的云时，你只需要到达最近的服务器，之后云将确保你的服务尽可能快速。

但是当我们谈论实际属于亚马逊或其他公司的数据中心时，我们仍然在处理大规模的运营。在这里，数字通常是以百计计算的，它们的位置也是秘密的，主要是出于安全原因。它们都有一些共同点。它们是高度自动化的运营，位于主要电源、主要冷却源或主要数据中心附近。理想情况下，它们应该被放置在一个同时具备这三种条件的地方，但通常这是不可能的。

位置是关键。

不同的公司有不同的策略，因为选择一个建立数据中心的好地方可以节省大量成本。有些公司甚至走向了极端。例如，微软有一个完全被浸入海洋中以便进行冷却的数据中心。

为特定用户提供服务时，你通常关心的是速度和延迟，这意味着你希望你的服务器或服务在离用户最近的数据中心运行。为此，所有云提供商都会根据地理位置划分他们的数据中心，这样管理员就可以在互联网的最佳部分部署他们的服务。但与此同时，这也会带来资源的典型问题 - 地球上有一些地方可用的数据中心很少，但人口密集，也有一些地方则相反。这反过来直接影响资源的价格。当我们谈到定价时，我们提到了不同的标准；现在我们可以再添加一个 - 地点。数据中心的位置通常被称为“区域”。这意味着 AWS，或者其他任何提供商，都不会告诉你他们的数据中心的位置，而是会说“在这个区域的用户最适合使用这组服务器”。作为用户，你不知道特定服务器在哪里，而是只关心提供商给你的区域。你可以在这里找到服务区域的名称和代码：

图 13.1 - AWS 上使用的配置名称的服务区域

选择一个需求量大的地区提供的服务可能会很昂贵，而选择其他地方的服务器可能会便宜得多。这就是云的美妙之处 - 你可以使用适合你和你的预算的服务。

有时价格和速度并不是最重要的事情。例如，法律框架，比如 GDPR，欧洲关于个人数据收集、处理和移动的法规，基本上规定欧洲公司必须使用欧洲的数据中心，因为它们受到这项法规的保护。在这种情况下使用美国地区可能意味着公司可能会承担法律责任（除非运行这个云服务的公司是其他允许这样做的框架的一部分，比如隐私盾）。

AWS 服务

我们需要谈一下 AWS 在服务方面提供了什么，因为理解服务是能够适当使用云的一件事。在 AWS 上，所有可用的服务都按照它们的目的分成了不同的组。由于 AWS 有数百种服务，AWS 管理控制台，也就是你登录后会看到的第一个页面，一开始可能会让人望而生畏。

你可能会使用 AWS 免费套餐进行学习，所以第一步是实际开设一个 AWS 免费账户。就我个人而言，我使用了自己的个人账户。对于免费账户，我们需要使用以下网址：aws.amazon.com/free/，并按照流程进行。它只需要一些信息，比如电子邮件地址、密码和 AWS 账户名称。它还会要求你提供信用卡信息，以确保你不会滥用 AWS 账户。

注册后，我们可以登录并进入 AWS 仪表板。看一下这个屏幕截图：

图 13.2 - 亚马逊服务

这里的每一样东西都是一个链接，它们都指向不同的服务或带有子服务的页面。此外，这个屏幕截图只显示了所有可用服务的大约三分之一。在这本书中覆盖它们所有是没有意义的；我们只会使用其中三个来展示 AWS 如何连接到我们的 KVM 基础设施，但一旦你掌握了它，你就会慢慢开始理解一切是如何连接的，以及在特定时刻应该使用什么。真正有帮助的是 AWS 有很好的文档，所有不同的服务都有提供向导，帮助你找到你要找的东西。

在本章中，我们将使用这三项服务：IAM、EC2和S3。

当然，所有这些都是缩写，但其他服务只是使用项目名称，比如CloudFront或Global Accelerator。无论如何，您的首要任务应该是开始使用它们，而不仅仅是阅读它们；一旦您开始使用，理解结构就会变得更容易。

在本章中，我们使用了一个免费账户，几乎所有的操作都是免费的，因此您没有理由不尝试使用 AWS 基础设施。AWS 尽其所能在那里提供帮助，因此如果您在控制台页面上向下滚动，您会发现这些有用的图标：

图 13.3 - 一些 AWS 向导、文档和视频 - 都非常有用

](https://github.com/OpenDocCN/freelearn-linux-zh/raw/master/docs/ms-kvm-vrt/img/B14834_13_03.jpg)

图 13.3 - 一些 AWS 向导、文档和视频 - 都非常有用

所有这些都是简单的场景，可以让您在几分钟内免费运行起来。亚马逊意识到，云的首次用户对所有选择感到不知所措，因此他们试图在几分钟内让您的第一台机器运行起来，以向您展示它有多么容易。

让我们先了解一下我们将要使用的服务，我们将通过一个场景来做到这一点。我们想要将在本地 KVM 安装中运行的机器迁移到亚马逊 AWS 中。我们将逐步完成整个过程，但首先需要了解我们需要什么。显然，第一件事是能够在云中运行虚拟机。在 AWS 宇宙中，这就是 EC2 或亚马逊弹性计算云。

EC2

EC2 是少数几个真正的核心服务之一，基本上在 AWS 云中运行所有的东西。它是整个基础设施的可扩展计算能力提供者。它使得可以运行不同的实例或虚拟计算环境，使用各种存储、内存、CPU 和网络配置，并且还提供这些实例所需的一切，包括安全性、存储卷、区域、IP 地址和虚拟网络。其中一些服务也可以单独使用，以应对更复杂的场景，例如，存在许多不同的存储选项，但实例的核心功能由 EC2 提供。

S3

这项服务的全名实际上是亚马逊简单存储服务，因此有了亚马逊 S3这个名字。其想法是为您提供存储和检索任意数量的数据的能力，随时使用提供的一种或多种方法。我们将使用的最重要的概念是S3 存储桶。存储桶是一个逻辑存储单元，使您能够对您存储的对象进行分组。可以将其视为一个存储容器的名称，稍后您将使用它来存储任何东西。您可以随意命名存储桶，但有一点我们必须指出 - 存储桶的名称必须是全局唯一的。这意味着当您命名一个存储桶时，它必须具有一个在任何地区中都没有重复的名称。这确保了您的存储桶将具有唯一的名称，但也意味着尝试创建一个听起来很普通的名称，比如bucket1或storage可能不会起作用。

创建存储桶后，您可以使用 Web、CLI 或 API 从中上传和下载数据。由于我们谈论的是一个全球系统，我们还必须指出，数据存储在您创建存储桶时指定的区域，并且会一直保留在那里，除非您指定要进行某种形式的多区域冗余。在部署存储桶时要记住这一点，因为一旦您开始使用存储桶中的数据，您的用户或实例需要获取数据，延迟可能会成为一个问题。由于法律和隐私问题，除非您明确指定，数据永远不会离开您指定的区域。

一个存储桶可以存储任意数量的对象，但每个账户的存储桶数量限制为 100 个。如果这不够用，您可以请求（并支付）将该限制提高到 1,000 个存储桶。

此外，仔细研究存储和移动数据的其他不同选项 - 有不同类型的存储，可能符合或不符合您的需求和预算，例如，S3 Glacier，它提供了更便宜的存储大量数据的选项，但如果需要取出数据则会很昂贵。

IAM

AWS 身份 和访问管理 (IAM) 是我们需要使用的服务，因为它可以为所有对象和服务提供访问管理和权限。在我们的示例中，我们将使用它来创建策略、用户和角色，以完成我们的任务。

其他服务

简单地提及 AWS 提供的所有服务是不可能的。我们只提到了必要的服务，并试图指引您朝正确的方向。您需要尝试并了解您的使用场景是什么，以及如何配置满足您特定需求的内容。

到目前为止，我们已经解释了 AWS 是什么以及它有多复杂。我们还提到了平台上最常用的部分，并开始解释它们的功能是什么。随着我们实际将一台机器从本地环境迁移到 AWS，我们将对此进行扩展。这将是我们的下一个任务。

为 AWS 准备和转换虚拟机

如果您在 Google 上搜索，从 KVM 迁移机器到 AWS 是很容易的，所需的只是按照此链接上的说明进行操作：docs.amazonaws.cn/en_us/vm-import/latest/userguide/vm-import-ug.pdf

如果您真的尝试去做，您会很快明白，只有对 AWS 工作方式有基本的了解，您就无法按照说明进行操作。这就是为什么我们选择以迁移一台机器作为使用 AWS 的示例，快速在云中创建一个可工作的虚拟机。

我们想要做什么？

让我们定义一下我们正在做的事情 - 我们决定将我们的一台机器迁移到 AWS 云中。现在，我们的机器正在本地的 KVM 服务器上运行，我们希望尽快将其运行在 AWS 上。

我们必须强调的第一件事是，这里没有实时迁移选项。没有简单的工具可以直接将 KVM 机器迁移到 AWS。我们需要一步一步地进行，并且机器需要处于关闭状态。在快速查阅文档后，我们制定了一个计划。基本上，我们需要做的是以下内容：

1. 停止我们的虚拟机。

2. 将机器转换为与 AWS 中使用的导入工具兼容的格式。

3. 安装所需的 AWS 工具。

4. 创建一个能够进行迁移的账户。

5. 检查我们的工具是否正常工作。

6. 创建一个 S3 存储桶。

7. 将包含我们机器的文件上传到存储桶中。

8. 将机器导入 EC2。

9. 等待转换完成。

10. 准备机器启动。

11. 在云中启动机器。

因此，让我们开始着手做这件事：

1. 一个很好的开始是查看我们工作站上的机器。我们将迁移名为deploy-1的机器来测试我们的 AWS 迁移。它是一个基本的 CentOS 7 安装，运行在使用相同 Linux 发行版的主机上。因此，我们显然需要有权限：

图 13.4 - 选择迁移过程中的虚拟机

接下来要做的是停止机器 - 我们无法迁移正在运行的机器，因为我们需要转换机器正在使用的卷，以使其与 EC2 上的导入工具兼容。

1. 在docs.aws.amazon.com/vm-import/latest/userguide/vmimport-image-import.html提供的文档中指出：

“当将 VM 作为镜像导入时，可以导入以下格式的磁盘：Open Virtualization Archive (OVA)、Virtual Machine Disk (VMDK)、Virtual Hard Disk (VHD/VHDX)和原始格式。在某些虚拟化环境中，你可以导出为 Open Virtualization Format (OVF)，它通常包括一个或多个 VMDK、VHD 或 VHDX 文件，然后将文件打包成一个 OVA 文件。”

在我们的特定情况下，我们将使用.raw格式，因为它与导入工具兼容，并且相对简单地从 KVM 使用的.qcow2格式转换为这种格式。

一旦我们的机器停止了，我们需要进行转换。找到磁盘上的镜像，并使用qemu-img进行转换。唯一的参数是文件；转换器通过检测扩展名来理解它需要做什么：

图 13.5 – 将 qcow2 镜像转换为原始镜像格式

我们只需要转换包含系统磁盘镜像的镜像文件；其他数据被留在了 VM 的安装之外。我们需要记住，我们正在转换为一个没有压缩的格式，所以你的文件大小可能会显著增加：

图 13.6 – 转换过程和相应的容量变化

我们可以看到我们的文件从 42MB 增加到 8GB，只是因为我们不得不删除qcow2为数据存储提供的高级功能。免费层只提供 5GB 的存储空间，所以请确保相应地配置原始镜像的大小。

我们接下来明显的步骤是将这个镜像上传到云端，因为转换是在那里完成的。在这里，你可以使用不同的方法，无论是 GUI 还是 CLI（API 也是可能的，但对于这个简单的任务来说太复杂了）。

1. AWS 有一个 CLI 工具，可以方便地与服务一起工作。这是一个简单的命令行工具，兼容大多数，如果不是所有，你能想到的操作系统：

图 13.7 – 下载和解压 AWS CLI

我们正在使用curl下载文件，并使用-o选项来指定输出文件的名称。显然，我们需要解压 ZIP 文件以便使用它。工具的安装过程也在文档中有提及。我们正在谈论一个简单的下载，之后我们需要提取工具。由于没有安装程序，工具不会出现在我们的路径中，所以从现在开始，我们需要通过绝对路径引用它。

在我们使用 AWS CLI 之前，我们需要对其进行配置。这个工具必须知道它将如何连接到云端，它将使用哪个用户，并且必须拥有所有的权限，以便工具能够将数据上传到 AWS，然后导入并转换为 EC2 镜像。由于我们还没有配置好，让我们切换到 AWS 的 GUI 并配置我们需要的东西。

重要提示

从现在开始，如果截图中的某些东西看起来被编辑了，那可能确实是。为了使事情能够无缝地运行，AWS 在屏幕上有很多个人和账户数据。

1. 我们将进入Administrator，一个名为administrators的组，并为它们应用适当的权限。然后我们将把用户加入到这个组中。在第一个屏幕上，你可以选择AdministratorAccess策略作为示例。这个策略非常重要，因为它允许我们给我们正在创建的Administrators组赋予所有可用的权限。现在选择可以稍后用于身份管理的tags。

2. 标记可以通过几乎任何东西来完成 – 名字、邮箱、职位，或者你需要的任何东西。我们将把这个留空：

图 13.15 – 添加标签

让我们回顾一下我们到目前为止配置的内容。我们的用户是我们刚刚创建的组的成员，他们在登录后必须立即重置密码：

图 13.16 - 通过组、策略和标记选项审查用户配置

接受这些并添加用户。您应该会看到一个令人放心的绿色消息框，其中包含有关刚刚发生的所有相关细节。还有一个直接链接到控制台的管理访问，所以您可以与新用户共享：

图 13.17 - 用户创建成功

用户创建后，我们需要启用他们的访问密钥。这是使用不同命令行实用程序的正常概念。它使我们能够为应用程序提供一种作为特定用户执行某些操作的方式，而不提供应用程序的用户名或密码。同时，我们可以为每个应用程序提供自己的密钥，因此当我们想要撤销访问权限时，我们只需禁用密钥。

点击屏幕中间的创建访问密钥：

图 13.18 - 创建访问密钥

关于这个密钥需要说几件事。有两个字段 - 一个是密钥本身，即访问密钥 ID，另一个是密钥的秘密部分，即秘密访问密钥。就安全性而言，这与为特定用户设置用户名和密码完全相同。您只有一次机会查看和下载密钥，之后就会消失。这是因为我们在这里处理的是散列信息，AWS 不存储您的密钥，而是它们的散列。这意味着如果您没有保存密钥，就无法检索密钥。这也意味着如果有人获取了密钥，比如从截图中读取，他们可以将自己标识为拥有该密钥的用户。好处是您可以创建任意多的密钥，并且撤销它们只是删除它们的问题。因此，请将密钥保存在安全的地方：

图 13.19 - 访问密钥已成功创建

我们现在暂时完成了 GUI。让我们回去安装 AWS CLI：

1. 我们只需要启动安装脚本并让它完成其工作。这可以通过在aws目录中启动名为install的文件来完成：

图 13.20 - 安装 AWS CLI

记住我们说过的绝对路径吗？aws命令不在用户路径中；我们需要直接调用它。使用configure作为参数。然后，使用我们在上一步中保存的密钥的两部分。从现在开始，我们使用 AWS CLI 给出的每个命令都被解释为在云上刚刚创建的用户Administrator下运行。

下一步是在 S3 上创建一个存储桶。有两种方法可以做到这一点。我们可以通过我们新配置的 CLI 来做，或者我们可以使用 GUI。我们将采取“漂亮”的方式，使用 GUI 来展示它的外观和行为。

1. 在控制台中选择 S3 作为服务。右上角有一个标有importkvm的按钮，但选择一个不同的名称。确保记下region下拉菜单 - 这是 AWS 资源将被创建的位置。记住名称必须是唯一的；如果购买了这本书的每个人都尝试使用这个名称，只有第一个人会成功。有趣的事实是：如果到你读到这里的时候，我们还没有删除这个存储桶，没有人将能够创建另一个同名的存储桶，只有读到这句话的人会明白为什么。这个向导在屏幕空间方面非常大，可能无法适应单个书页，所以让我们将其分成两部分：

图 13.21 – 创建 S3 存储桶的向导-选择存储桶名称和区域

这个向导的第二部分与设置相关：

图 13.22 – 存储桶设置

不要更改对公共的访问-实际上没有必要；除了您之外，没有人会需要访问这个特定的存储桶和其中的文件。默认情况下，此选项已预先选择，我们应该保持不变。这应该是最终结果：

图 13.23 – S3 存储桶创建成功

好了，做完这些，现在是等待下一个命令完成的时候了。在下一步中，我们将使用 AWS CLI 将.raw文件复制到 S3。

重要提示

根据账户类型的不同，从这一点开始，我们可能需要为创建的一些服务付费，因为它们可能会超出您账户上启用的免费套餐。如果您没有启用任何昂贵的东西，那么应该没问题，但是始终要查看您的成本管理仪表板，并确保您仍然处于盈利状态。

将图像上传到 EC2

接下来的步骤是将图像上传到 EC2，以便我们实际上可以将该图像作为虚拟机运行。让我们开始上传过程-这就是我们首先安装 AWS CLI 实用程序的原因：

1. 使用以下参数使用 AWS CLI：

图 13.24 – 使用 AWS CLI 将虚拟机原始图像复制到 S3 存储桶

这就是最终结果。由于我们谈论的是 8GB 的数据，您将不得不等待一段时间，具体取决于您的上传速度。AWS CLI 的语法非常简单。您可以使用大多数您知道的 Unix 命令，ls和cp都能正常工作。唯一要记住的是以以下格式给出您的存储桶名称作为目的地：s3://<bucketname>。

1. 之后，我们执行ls命令-它将返回存储桶名称，但我们可以通过使用存储桶名称来列出它们的内容。在这个例子中，您还可以看到我们从创建存储桶到传输文件大约花了 15 分钟的时间：

图 13.25 – 传输文件

现在开始有趣的部分。我们需要将机器导入 EC2。为此，我们需要在进行转换之前完成一些事情。问题与权限有关-AWS 服务默认情况下无法相互通信。因此，您必须为它们中的每一个明确授予权限以进行导入。实质上，您必须让 EC2 与 S3 通信并从存储桶中获取文件。

1. 为了上传目的，我们将介绍另一个 AWS 概念-.json文件。AWS 中的许多东西都以.json格式存储，包括所有的设置。由于 GUI 很少被使用，这是传输数据和设置的最快方式，因此我们也必须使用它。我们需要的第一个文件是trust-policy.json，我们将使用它来创建一个角色，该角色将使数据能够从 S3 存储桶中读取：

trust-policy.json, and get the preceding code typed in. Do not change anything. The next one up is the file named role-policy.json. This one has some changes that you have to make. Take a closer look inside the file and find the lines where we mention our bucket name (importkvm). Delete our name and put the name of your bucket instead: 

{

“Version”:“2012-10-17”,

“Statement”:[

{

“Effect”:“Allow”,

“Action”:[

“s3:GetBucketLocation”,

“s3:ListBucket”,

“s3:GetObject”

],

“Resource”:[

“arn:aws:s3:::importkvm”

“arn:aws:s3:::importkvm/*”

],

},

{

“Effect”:“Allow”,

“Action”:[

“s3:GetObject”,

“s3:GetBucketLocation”,

“s3:ListBucket”,

“s3:GetBucketAcl”,

“s3:PutObject”

],

“Resource”:[

“arn:aws:s3:::importkvm”

“arn:aws:s3:::importkvm/*”

],

},

{

“Effect”:“Allow”,

“Action”:[

“ec2:ModifySnapshotAttribute”,

“ec2:CopySnapshot”,

“ec2:RegisterImage”,

“ec2:Describe*”

],

“Resource”:“*”

}

]

}

Now it's time to put it all together and finally upload our virtual machine to AWS.

1. 执行这两个命令，忽略格式中发生的任何事情-它们都是一行命令，文件名是命令的最后部分：

.json file that will describe to EC2 what we are actually importing and what to do with it. 

1. 我们正在创建的文件需要如下所示：

[
 {
 "Description": "Test deployment", 
 "Format": "raw", 
 "Userbucket": {
 "S3Bucket": "importkvm",
 "S3Key": "deploy1.raw"
 }
]

如您所见，文件中没有什么特别之处，但是当您创建自己的版本时，请注意使用您的名称作为存储桶和存储在存储桶中的磁盘映像的名称。随意命名文件，并使用该名称调用导入过程：

图 13.27 - 最后一步 - 将虚拟机部署到 AWS

现在等待过程完成。在这一步中发生的是导入和转换图像以及您上传的操作系统。AWS 不会按原样运行您的图像；系统会进行一些更改，以确保您的图像可以在基础设施上运行。一些用户也会收到一些更改，但稍后再说。

任务将在后台运行，并在完成时不会通知您；您需要自行检查。幸运的是，AWS CLI 中有一个可以使用的命令叫做describe-import-image-tasks，这是输出：

图 13.28 - 检查我们的上传过程的状态

这意味着我们成功导入了我们的机器。太棒了！但是机器还没有运行。现在它已经变成了一个叫做Amazon Machine Image（AMI）的东西。让我们看看如何使用它：

1. 转到您的 EC2 控制台。您应该能够在左侧的AMI下找到图像：

图 13.29 - 我们的 AMI 已成功上传，并且可以在 EC2 控制台中看到

现在点击大蓝色的启动按钮。在实例运行之前，您需要完成几个步骤，但我们几乎已经完成了。首先，您需要选择您的实例类型。这意味着根据您的需求选择适合您的配置，根据您需要的一切（CPU、内存和存储）。

1. 如果您使用的是不拥挤的地区，您应该能够启动一个通常称为t2.micro的免费层实例类型，并且标记清晰。在您的免费账户中，您有足够的处理信用来使您能够完全免费运行这台机器：

图 13.30 - 选择实例类型

现在是一些安全性问题。亚马逊更改了您的机器，并已实施了无密码登录到管理员帐户，使用密钥对。由于我们还没有密钥，我们还需要创建密钥对。

1. EC2 将把这个密钥放入您刚刚创建的机器上的适当帐户中（所有帐户），因此您可以无需使用密码登录。如果您选择这样做，将生成密钥对，但亚马逊不会存储它 - 您需要自行存储：

图 13.31 - 选择现有密钥或创建新密钥

就是这样，您的虚拟机现在应该需要几分钟来启动。只需等待确认窗口。一旦准备就绪，通过上下文菜单连接到它。点击右下角的查看实例，您将进入实例列表。

要连接，您需要使用提供给您的密钥对，并且需要一个ssh客户端。或者，您可以使用 AWS 提供的嵌入式ssh。无论哪种情况，您都需要机器的外部地址，AWS 也提供了这个，以及简单的说明：

图 13.32 - 连接到您的实例说明

因此，回到我们的工作站，我们可以使用前一个截图中提到的ssh命令来连接到我们新启动的实例：

图 13.33 - 通过 SSH 连接到我们的实例

就是这样。你已经成功连接到你的机器。你甚至可以让它继续运行。但要注意，如果你的账户或服务是默认开启的或没有密码 - 毕竟，你已经从你安全的家庭沙盒中取出一个虚拟机，并将其放在了庞大而危险的互联网上。最后一件事：在你的虚拟机运行后，删除存储桶中的文件以节省资源（和金钱）。转换后，这个文件就不再需要了。

我们接下来要讨论的话题是如何通过使用名为尤加利林的应用程序将我们的本地云环境扩展到混合云环境。这是一个非常流行的过程，许多企业公司在扩展基础设施超出本地基础设施时都会经历。此外，当需要时，这也提供了可伸缩性方面的好处 - 例如，当公司需要扩展其测试环境以便对员工正在开发的应用进行负载测试时。让我们看看通过尤加利林和 AWS 如何实现。

使用尤加利林构建混合 KVM 云

尤加利林是一个奇怪的东西，我们并不是指植物。作为一个项目，它旨在弥合私有云服务和 AWS 之间的差距，尤加利林试图在本地环境中重新创建几乎所有 AWS 功能。运行它几乎就像拥有一个与 AWS 兼容的小型本地云，而且它使用的几乎是与 AWS 相同的命令。它甚至使用与 AWS 相同的名称，因此它可以与存储桶等进行交互。这是有意为之，并得到了亚马逊的同意。拥有这样的环境对每个人来说都是一件好事，因为它为开发人员和公司部署和测试他们的实例创造了一个安全的空间。

尤加利林由几个部分组成：

图 13.34 - 尤加利林架构（http://eucalyptus.cloud，官方文档）

从图表中可以看出，尤加利林具有高度可伸缩性。

可用区是可以容纳由集群控制器控制的多个节点的一个部分。区域然后组合成云本身，由云控制器控制。与所有这些相关联的是用户服务部分，它实现了用户与整个尤加利林堆栈之间的交互。

总的来说，尤加利林使用了五个组件，有时会根据图表中的名称来指代它们，有时会根据它们的项目名称来指代，就像 OpenStack 一样：

• 云控制器（CLC）是系统的中心点。它提供 EC2 和 Web 界面，并将每个任务路由到自己。它负责调度、资源分配和计费。每个云都有一个这样的控制器。

• 集群控制器（CC）负责管理每个单独的节点，控制虚拟机及其执行。每个可用区都运行一个。

• 存储控制器（SC）负责提供块级存储，并在集群内为实例和快照提供支持。它类似于 AWS 的 EBS 存储。

• 节点控制器（NC）托管实例及其端点。每个节点都运行一个。

• eucanetd是尤加利林用来管理云网络的服务，因为我们正在谈论将本地网络扩展到 AWS 云的问题。

当你了解尤加利林时，你会注意到它具有广泛的功能。它可以做到以下几点：

• 与卷、实例、密钥对、快照、存储桶、镜像、网络对象、标签和 IAM 一起工作。

• 与负载均衡器一起工作。

• 作为 AWS 集成工具与 AWS 合作。

这些只是您开始 Eucalyptus 之旅时值得一提的一些功能。Eucalyptus 还有一个名为Euca2ools的额外命令行界面，作为所有主要 Linux 发行版的软件包提供。Euca2ools 是一个额外的工具，提供了 AWS 和 Eucalyptus 之间的完整 API 和 CLI 兼容性。这意味着您可以使用一个工具来管理两者，并执行混合云迁移。该工具是用 Python 编写的，因此它基本上是与平台无关的。如果您想了解更多关于这个接口的信息，请确保您访问wiki.debian.org/euca2ools。

如何安装？

如果您正在安装测试机器并且遵循说明，那么安装 Eucalyptus 很容易，我们将在本书的最后一章第十六章中描述，KVM 平台的故障排除指南，这是处理 KVM 故障排除的章节。我们将要做的就是安装一个单机，它将容纳所有节点和整个云的一部分。当然，这远远不足以满足生产环境的需求，因此在 Eucalyptus 网站上，有单机一切都做的指南，以及安装生产级云的指南。请确保您查看以下链接：docs.eucalyptus.cloud/eucalyptus/4.4.5/install-guide-4.4.5.pdf。

安装很简单——只需提供一个至少有 120GB 磁盘空间和 16GB 内存的最小安装的 CentOS 7 系统。这是最低要求。如果低于这些要求，您将遇到两种问题：

• 如果您尝试在内存小于 16GB 的计算机上安装，安装可能会失败。

• 然而，安装将在磁盘大小小于最低建议的机器上成功，但一旦开始安装部署图像，您几乎立即就会耗尽磁盘空间。

对于生产环境，一切都会改变——存储的最低要求是 160GB，或者对于将运行 Walrus 和 SC 服务的节点，需要 500GB 的存储。节点必须在裸金属上运行；不支持嵌套虚拟化。或者更准确地说，它可以工作，但会抵消云所能提供的任何积极效果。

说了这么多，我们在开始安装之前还有一点要提醒一下——检查新版本的可用性，并且要记住，很可能有比我们在本书中使用的版本更新的版本。

重要提示

在撰写本文时，当前版本是 4.4.5，版本 5 正在积极开发中，即将发布。

安装了基本操作系统后——它必须是一个没有图形界面的核心系统，现在是时候进行实际的 Eucalyptus 安装了。整个系统都是使用FastStart安装的，所以我们唯一需要做的就是从互联网上运行安装程序。链接很贴心地放在了项目的以下 URL 的首页上——eucalyptus.cloud。

Eucalyptus 安装成功的一些先决条件：

• 您必须连接到互联网。这种方式无法进行本地安装，因为一切都是动态下载的。

• 您还必须有一些 IP 地址可供系统在安装时使用。最低要求是 10 个，它们将随着云一起安装。安装程序将要求范围，并尝试在没有干预的情况下完成一切。

• 唯一的其他先决条件是一个可用的 DNS 和一些时间。

让我们通过以下命令开始安装：

# bash <(curl -Ls https://eucalyptus.cloud/install) 

如果您是第一次看到安装，它看起来很奇怪。它有点让我们想起了上世纪 90 年代我们使用的一些基于文本的游戏和服务（MUD，IRC）：

图 13.35 - Eucalyptus 文本模式安装

屏幕上的信息将告诉您要遵循哪个日志，如果您想查看实际发生的事情；否则，您可以查看安装程序并等待屏幕上的茶变冷。老实说，在一台体面的机器上，安装可能需要大约 15 分钟，如果您安装所有软件包，则可能需要多 10 分钟。

安装后，Eucalyptus 将为您提供一组默认凭据：

• 桉树

• 管理员

• 密码

重要提示

如果当前的安装程序出现问题，后续问题的解决方案在此 CiA 视频中： <video_URL>。已知存在一些问题，可能在本书上市之前解决，也可能不会解决。确保在安装之前检查eucalyptus.cloud和文档。

信息区分大小写。安装完成后，您可以使用 Web 浏览器连接到该机器并登录。您将使用的 IP 地址是刚刚安装的机器的 IP 地址：

图 13.36 - 桉树登录屏幕

系统安装完成后，在新安装的系统的控制台上，您将看到一条指示，要求运行系统上包含的主教程。教程本身是了解系统外观、关键概念以及如何使用命令行的好方法。您可能遇到的唯一问题是，教程是一组具有一些信息硬编码的脚本。您会立即注意到的一件事是，除非您修复它们，否则指向图像模板的云版本的链接将无法工作 - 链接指向已过期的地址。这很容易解决，但会让您措手不及。

另一方面，也许在您阅读此文时，问题已经解决。关于如何执行此操作以及其所有部分的教程以纯文本模式提供在 Eucalyptus 运行的机器上。它在 GUI 中不可用：

图 13.37 - 启动文本模式 Eucalyptus 主教程

教程在外观上非常基本，但我们喜欢它，因为它为我们提供了对 Eucalyptus 提供的一切的简短但重要的概述：

图 13.38 - 使用主教程学习如何配置 Eucalyptus

正如您所看到的，一切都有详细说明，因此您可以在短时间内真正学习关键概念。浏览教程-它非常值得。一旦启动系统，您可以从命令行下载一些新的模板图像。此脚本也是从 Web 启动的，并且以大字体写在官方网站上，文字位于以下 URL 的首页上（确保您向下滚动一点）- www.eucalyptus.cloud/:

图 13.39 - 下载图像到我们的 Eucalyptus 云

将此复制粘贴到根提示符中，不久将出现一个菜单，可让您下载可能使用的图像。这是我们见过的模板安装中最简单和最可靠的之一，除了它们包含在初始下载中：

图 13.40 - 简单菜单要求我们选择要安装的图像

一次选择一个，它们将包含在图像列表中。

现在让我们切换到 Web 界面，看看它是如何工作的。使用上面写的凭据登录。您将看到一个设计精良的仪表板。右侧是最常用的功能组。左侧是保留给包含所有服务链接的菜单。一旦您将鼠标移开，菜单将自动隐藏，只留下最基本的图标：

图 13.41 - Eucalyptus 管理控制台

我们已经讨论了这个页面上的大部分内容 - 只需查看与 AWS 相关的本章内容，您就会非常熟悉。让我们尝试使用这个控制台。我们将启动一个新实例，只是为了感受一下 Eucalyptus 的工作方式：

1. 在服务堆栈的左侧有一个诱人的绿色按钮标有启动实例 - 点击它。将出现系统上可用的镜像列表。我们已经使用脚本抓取了一些云镜像，所以有可供选择的内容：

图 13.42 - 选择要在 Eucalyptus 云中运行的镜像

我们选择从云镜像中运行 Ubuntu。在选择完您想要的镜像后，从下拉菜单中选择启动。一个新窗口将打开，允许您创建虚拟机。在下拉菜单或实例类型中，我们选择了一个看起来足够强大以运行我们的 Ubuntu 的机器，但基本上，任何具有 1GB 以上 RAM 的实例都可以很好地运行。由于我们只准备了一个实例，所以没有太多要改变：

图 13.43 - 启动新实例向导

下一个配置屏幕与安全有关。

1. 我们可以选择使用在 Eucalyptus 云上创建的默认密钥对，也可以创建一个新的。密钥的公共部分仅存储在 Eucalyptus 中，因此只有在安装时下载了密钥，我们才能使用这个密钥对进行身份验证。创建密钥的过程与用于 AWS 的过程完全相同：

图 13.44 - 安全配置 - 选择密钥和 IAM 角色

点击启动实例按钮后，您的机器应该启动。出于测试目的，我们之前已经启动了另一台机器，所以现在我们有两台正在运行：

图 13.45 - Eucalyptus 云中启动的一对实例

下一步是尝试创建一个存储桶。

1. 创建存储桶很容易，并且看起来与 AWS 让您可以做的非常相似，因为 Eucalyptus 试图尽可能与 AWS 相似：

图 13.46 - 创建存储桶

由于 Eucalyptus 不像 AWS 那样复杂，特别是在策略和安全方面，存储桶的安全选项卡较小，但具有一些非常强大的工具，如下面的屏幕截图所示：

图 13.47 - 存储桶安全配置

现在我们已经安装、配置并使用了 Eucalyptus，是时候转向本章的下一个主题，即将我们基于 Eucalyptus 的云扩展到 AWS。

使用 Eucalyptus 控制 AWS

您还记得最初显示登录凭据的初始屏幕吗？我们提到您也可以登录到 AWS。从 Eucalyptus 控制台注销并转到登录屏幕。这次点击登录到 AWS：

图 13.48 - 通过 Eucalyptus 登录 AWS

尝试使用我们在上传图像到 EC2部分创建的身份验证密钥，或者为 AWS IAM 中的管理员用户创建一个新的密钥。将其复制并粘贴到 AWS 凭据中，您将拥有一个完全可用的界面，连接到您的 AWS 帐户。您的仪表板看起来几乎一样，但会显示您的 AWS 帐户的状态：

图 13.49 - Eucalyptus 管理控制台用于 AWS

让我们检查一下我们是否能看到我们的存储桶：

图 13.50 - 检查我们的 AWS 存储桶

请注意，我们不仅看到了我们用来测试 AWS KVM 导入的存储桶，还看到了我们运行的区域，在右上角。您的帐户由其密钥名称给出，而不是实际用户；这仅仅是因为我们实际上是以编程方式登录的。我们点击的每个东西都被转换为 API 调用，然后返回的数据被解析并显示给用户。

我们当前停止的实例也在这里，但请记住，只有在您选择最初导入实例的区域时才会看到它。在我们的情况下，它是美国西部，所以我们的实例就在那里：

图 13.51 - 检查我们的 AWS 实例

正如您可能已经注意到的那样，Eucalyptus 是一个多方面的工具，能够为我们提供混合云服务。基本上，Eucalyptus 的关键点之一是它使您达到了与 AWS 兼容的水平。因此，如果您开始将其用作私有解决方案，并且在将来的某个时候开始考虑转移到 AWS，Eucalyptus 已经为您考虑到了。对于基于 KVM 的虚拟机来说，它是一个事实上的标准解决方案。

我们将在这里结束 AWS 集成。毕竟，本章的重点是让您看到 Eucalyptus 如何连接到 AWS。您可能会发现，这个界面缺少 AWS 具有的功能，但同时可能已经足够控制基本的中型基础设施-从一个地方控制存储桶、镜像和实例。经过测试 5.0 beta 1 版本后，我们可以明确告诉您，完整的 5.0 版本一推出应该是相当大的升级。beta 版本已经有许多额外的选项，我们对完整版本的发布感到非常兴奋。

总结

在本章中，我们涵盖了许多主题。我们将 AWS 作为云解决方案进行了介绍，并对其进行了一些很酷的操作-我们转换了我们的虚拟机，以便我们可以在其中运行，并确保一切正常。然后我们转向 Eucalyptus，以查看我们如何将其用作本地云环境的管理应用程序，以及如何将其用于扩展我们的现有环境到 AWS。

下一章将带我们进入使用 ELK 堆栈监视 KVM 虚拟化的世界。这是一个非常重要的话题，特别是随着公司和基础设施的规模增长-您无法通过手动监视所有可能的服务来跟上 IT 服务的有机增长。ELK 堆栈将帮助您解决这个问题-您将在下一章中了解到它有多大帮助。

问题

1. AWS 是什么？

2. EC2、S3 和 IAM 是什么？

3. S3 存储桶是什么？

4. 我们如何将虚拟机迁移到 AWS？

5. 我们使用哪个工具将原始图像上传到 AWS？

6. 我们如何作为用户向 AWS 进行身份验证？

7. Eucalyptus 是什么？

8. Eucalyptus 中的关键服务是什么？

9. 可用区是什么？故障域是什么？

10. 为虚拟化、云和 HPC 环境提供 Tier-0 存储服务的基本问题是什么？

进一步阅读

有关本章涵盖内容的更多信息，请参考以下链接：

• Amazon AWS 文档：docs.aws.amazon.com/

• Amazon EC2 文档：docs.aws.amazon.com/ec2/?id=docs_gateway

• 亚马逊 S3 文档：docs.aws.amazon.com/s3/?id=docs_gateway

• 亚马逊 IAM 文档：docs.aws.amazon.com/iam/?id=docs_gateway

• 尤卡利普特斯安装指南：docs.eucalyptus.cloud/eucalyptus/4.4.5/install-guide/index.html

• 尤卡利普特斯管理指南：docs.eucalyptus.cloud/eucalyptus/4.4.5/admin-guide/index.html

• 尤卡利普特斯控制台指南：docs.eucalyptus.cloud/eucalyptus/4.4.5/console-guide/index.html

• Euca2ools 指南：docs.eucalyptus.cloud/eucalyptus/4.4.5/euca2ools-guide/index.html