【OpenStack】OpenStack实战之开篇
@TOC
推荐超级课程：
我的整个职业生涯到目前为止一直围绕着为离线或隔离网络设计和开发应用程序以及使用严重过时的操作系统而展开，不允许有外部依赖。因此，当我转移到一个新的角色开始处理云部署时，我把它看作是学习云开发和部署的机会。我很快就遇到了在这些平台上工作时会遇到的困难。
其中最大的困难包括：
- 供应商锁定：如果您编写一个应用程序并将其部署到一个平台上，那么代码必须针对您正在开发的平台进行定制。如果你被告知需要将代码迁移到另一个平台（这比你意识到的要频繁），你就得重新设计所有的代码。
- XaaS（一切即服务）：我可能会用这个观点挑起一些争议，但请听我说。作为一个应用程序开发人员，我希望部署多个相互交互的节点。如果我在一个具有DBaaS或STaaS（用于存储/数据的服务）、PaaS（用于计算节点/服务器的服务）、FaaS（用于处理物联网/事件驱动流程的服务）的平台上，这些服务都是从它们自己的集群部署的，这意味着它们可以通过公共网络访问……这意味着您有责任妥善保护它（老实说，很多人不这么做）。
在寻找解决方案和对我遇到的各种问题的文档时，我经常看到有关OpenStack的参考。我对OpenStack产生了好奇。OpenStack是什么？它提供哪些服务？谁拥有它？我该如何学会使用它？它的成本和局限性是什么？
那么，OpenStack是什么？
不赘述太多历史或细节，OpenStack是一套开源工具和组件，当一起部署时，可以创建您自己的专用云环境。
云又是什么？
为了澄清一下，想象一下云是一个微组件的虚拟仓库。
当我想到托管应用程序的服务器时，我会考虑到3个级别的托管资源：
裸机：（上面显示了服务器刀片）它们可以是价值数十万美元的庞然大物。我们在计算机上安装软件或部署应用程序是相当熟悉的，这和在这些服务器上运行是没有什么不同的。问题出现在当您想要完全利用这些服务器上的资源时。您开始部署多个软件包和应用程序，但然后您意识到一个应用程序可以访问另一个应用程序的资源，或者一个应用程序的依赖与另一个应用程序的依赖冲突。这会带来巨大的安全和设计困扰。
虚拟机：这些"虚拟"是指它们完全基于软件，但仍具备与完整桌面或服务器相同的资源和复杂性。在一个服务器上安装多个虚拟机是可能的，并且安装在每个虚拟机上的应用程序完全独立，不会发生冲突或与其他应用程序互动。您还可以实现连接它们的虚拟网络，并提供一个隔离屏障，防止主机系统或互联网访问。
它们在部署应用程序方面提供了很大的改进，因为您可以创建虚拟机以满足应用程序的需求。但由于它们复制了一个全尺寸的机器，它们也包含一些（对这些更小环境进行了一些优化更改）的操作系统开销和裸机机器的依赖。想象一下你想把一台旧笔记本电脑用作家庭服务器，它几乎无法运行Windows 10，同时你还想设置第二台电脑在其中同时运行？无论你的服务器有多大，终究会达到一台机器上能够设置多少个的极限。
像Docker和LXC这样的容器系统是为了解决尺寸问题而创建的。这些容器允许使用最少量的，“预先打包"的操作系统（OS）映像（或预先安装了所有应用程序依赖项和要求的可安装OS映像），而不需要虚拟机所需的额外资源，足够执行它所需的操作。
然而，它们在安全性和稳定性方面常常存在问题，因为容器本质上是在计算机上运行的程序。它们非常简单，一个恶意的映像创建者可以轻易加入一个扫描您系统中其他容器并获取其环境访问权的进程。另一个问题是容器节点中的某些部分出现严重故障，可能会导致整个主机系统崩溃。这可能会带来风险，您不希望在创建高质量、安全性应用程序时发生这种情况。
注意：不要误解，我喜欢容器。它们让部署应用程序变得如此容易，但我也需要了解它们可能会遇到哪些困难。
许多操作系统开发人员正在寻找折衷之道，通过创建经过安全保护但又非常简约的映像，可以托管在微小的、“微小"或甚至"微型”/“纳米"大小的虚拟机实例上。这实质上是稍大于容器大小的微型虚拟机，但具有虚拟机的分割性和复杂性。这开始出现了数百个独立运行的容器化机器，它们可以为单个应用程序提供资源。
回顾裸机的规模，这些系统（无论是容器还是虚拟机）只是利用了可用资源的一部分，让您可以快速创建新实例，任何时间。因为它们都是基于软件的，您可以通过点击按钮启动和停止任意数量的实例，它们可以快速复制以弥补处理瓶颈，它们可以都包含在一个服务器中，或者跨越整个一堆服务器……因此云诞生。
关于容器应用程序
记住容器本质上是系统中的程序，而Kubernetes为跨多个系统运行这些容器提供了基础设施自动化。由于这些要求，Kubernetes需要一个至少包含3个或更多基本系统（或节点）的集群才能创建一个单独的集群。
大集群也存在尺寸/范围问题。在某个时刻，您可能拥有一个优秀的集群，然后引入一个问题容器，它可能（非常罕见，但仍有可能）导致一个系统崩溃（请记住，容器本质上是在主机系统上运行的进程）。如果您不小心的话，这可能导致整个集群崩溃。一个良好的设计替代方案是为不同的应用程序创建多个集群，但这意味着为每个集群/应用程序设置另外的3个或更多节点。我从learnk8s.io / Daniel Weibel的文章 中了解到这些在Kubernetes中部署大型应用程序时所面临的设计考虑和问题。
这就是云环境（如OpenStack）对这个"问题"的理想解决方案之一。因为Kubernetes需要最少数量的节点才能启动一个集群，并且每个集群可能有不同的资源需求，云环境可以创建包含Kubernetes集群及其基础设施的虚拟机节点。我说您必须至少有几个节点，但我没有说这些节点有多大。 这意味着我们可以创建3个以上的微型虚拟机来设置Kubernetes。我们可以水平扩展/连接到其他虚拟机，或者垂直扩展/增加虚拟机的大小。此外，您还可以完全孤立该集群在单个虚拟网络中，这意味着您只需要担心访问该网络的接口。正如本系列文章将向您展示的一样，OpenStack可以配置在单台计算机或跨数千台计算机上，因此您的想象力是唯一的限制。
OpenStack如何适配其中？
谷歌、亚马逊、微软、IBM、SAP等公司向我们介绍了云的概念。如果您查看它们的目录，您会看到数百种不同类型的技术，以帮助托管应用程序。它们很有帮助，但是由于一切都采取“即服务”工作方式或拥有与他们平台独特的设置详情，它们可能会很繁琐、文档不全（！）或需要高学习曲线来实现。这些提供商试图简化许多处理这些组件的细节，并创建新服务（因为他们提倡“无代码”方法），这样您就可以创建应用程序而不用编写一行代码。如果您仔细观察，您会发现这些供应商提供的底层技术通常是使用已有技术所创建的解决方案，以便这些供应商可以为许多用户提供功能的模板化，但代价是平台的锁定。当然，它们提供免费/开发者账户，但总会有限制。而且，一个在一个平台上构建的应用程序未必会在另一个平台上运行而无需进行一些重大的重构。
OpenStack为所有这些问题提供了解决方案：
- 开源的，这意味着任何具备相关知识和资源的人都可以安装自己的云平台或审核源代码，以发现代码质量和安全性方面的漏洞。
- 基于一个标准、开放的框架设计。如果您在一个提供商那里运行着一个OpenStack应用程序，而您需要迁移到另一个提供商，没问题！只需使用新的凭据重新部署，之后就完成了（只要版本允许）。OpenStack组件中的许多基础技术是广泛使用和公认的技术。
- 由于云本身是完全可扩展的，OpenStack团队创建了许多不同的工具来帮助您开发和测试自己的组件（稍后将讨论这一点）。这些工具可以快速在您安装它的任何机器上设置一个小型云。没有免费试用，没有限制，没有时间限制（除非受限于您自己的硬件限制）。
- 可拓展到任意数量的提供商。您可以在Vexxhost 上托管您应用程序的一部分。它们都可以是同一个应用程序的一部分，并且可以互动得就像它们在同一个环境中一样。
最后一个观点至关重要。随着您应用程序需求的增长，您可以在全球范围内扩展而无需担心您的提供商是否在最需要的地区拥有数据中心。只需找到一个托管OpenStack的提供商并进行扩展（或将您自己的OpenStack实例部署在大型供应商（云中的云……潜能）上）。
考虑到所有这些观点，私有云、公共提供商与环境和区域之间的标准互操作性，我们可以部署比任何单一云供应商可以提供的更大型的内容。
如何设置它？
这是各种方法的简要介绍，让您可以在自己的电脑中体验OpenStack：
我们将使用DevStack来解决我们的问题，因为它是最广泛使用且稳定的解决方案（因为它是OpenStack测试套件的一部分），并且不会将我们锁定在特定的操作系统/平台。
如何学会使用它？
这才是棘手的部分。我浏览了他们自己的练习资料库、在线培训平台、已发布的书籍，发现一切对我这个初学者水平来说都太技术性了，而且通常是针对试图获得红帽认证系统管理员（RHCSA）来学习OpenStack的系统管理员，或者这些内容已过时且不再相关。
这就是我决定开启这个系列的原因：一个让我学习、实践和失败的方式，同时记录我发现的对于那些寻找相同答案而挣扎的人能够起作用的内容。