OpenShift入门指南 - 第一部分

IT基础设施随时间推移发生了哪些变化

DevOps最佳实践

使用单体架构开发应用程序与使用微服务开发应用程序

迁移到云端

为现有企业创造价值的最佳途径是开发新的应用程序，无论是云原生应用、人工智能和机器学习、分析、物联网，还是其他任何创新应用。OpenShift 由 Red Hat 开发，是大型企业用于交付容器化应用的平台。如果您读过我之前关于Docker和Kubernetes 的文章，您就会了解容器化在云中的重要性。OpenShift 声称是“业界最安全、最全面的、基于行业标准的企业级容器平台”。简而言之，OpenShift 就像是功能更强大的Kubernetes。

本文将简要回顾IT基础设施的发展历程，概述DevOps工程师的角色及其使用OpenShift的原因，并介绍OpenShift的工作原理。在第二部分，我将展示如何使用OpenShift。深入了解IT基础设施的演变对于充分理解DevOps工程师使用OpenShift的原因以及OpenShift对云计算行业的影响至关重要。

如果您已经阅读了第一部分，请继续关注第二部分！

IT基础设施随时间推移发生了哪些变化

摩尔定律指出，芯片上的晶体管数量每两年翻一番。这意味着我们可以预期计算机的速度和性能每隔几年就会提升，而且价格也会下降。自互联网诞生以来，功能日益强大的微芯片不断给商业和生活带来翻天覆地的变化。有些人当初对互联网将如何影响我们的生活的预测是多么错误，现在看来真是令人啼笑皆非。

1995年，科学家克利福德·斯托尔正在宣传他的著作《硅谷的蛇油》。与此同时，他在《新闻周刊》上发表了一篇题为《互联网？呸！》的文章，文中他声称电子商务等服务不可行，并且“任何在线数据库都无法取代你的日报”。

或许只是事后诸葛亮罢了。毕竟，克利福德·斯托尔曾在加州劳伦斯伯克利国家实验室管理计算机，所以他的观点并非出于无知。如今，大多数人都或多或少地了解互联网技术的普及程度，但这个过程是从哪里开始的，我们又走到了哪里？让我们从发展过程说起。以下三个相关的发展过程你可能比较熟悉：

开发过程

瀑布式流程：瀑布式流程因其单向性而得名。项目进展通常只沿着既定的方向进行，就像瀑布一样。项目被分解成线性顺序的阶段，每个阶段都依赖于前一阶段的交付成果。这种方式的主要问题在于，如果客户改变需求，就很难进行修改。 

敏捷开发：敏捷开发方法源于瀑布式开发方法。它并非在每个阶段都向客户交付 100% 的功能，而是可能只交付大约 20% 的功能。此时，客户会提供反馈，而开发人员在继续完善已交付成果的同时，开始开发其他功能。经过 5 次迭代，开发人员就能得到一个令他们满意并愿意继续使用的产品。但是，IT 运维人员呢？那些负责运行现有服务器、网站和数据库的人员呢？

DevOps：由于开发团队和运维团队的目标和技能可能不同，这两个团队的分离往往会导致彼此缺乏信任。DevOps 方法将这两个团队整合在一起，使他们拥有共同的热情和目标。稍后我会详细讨论这一点。

IT 演进的下一个方面是应用架构，它指的是软件模块和组件、内部和外部系统以及它们之间的交互。

应用架构

单体架构：单体架构是传统的软件程序设计统一模型。单体架构拥有一个承载所有应用堆栈的主机，因此如果主机硬件崩溃，整个系统都会瘫痪。多年来，单体架构逐渐被拆分为多个独立的层级。

三层架构：三层系统将大型机模型分解为 Web 层、应用层和数据库层。这被称为面向服务的架构 (SOA)。然而，现实情况是，如果其中任何一层出现故障，都会造成系统停机。而且，所有应用程序逻辑仍然保留在应用层中。人们已经从这种架构转向微服务架构。 

微服务：在这种架构中，服务的构建不是按层级进行的，而是按业务功能进行的。稍后我会详细介绍微服务。

下一个方面是应用基础设施，即用于交付业务应用程序的软件平台。

应用基础架构

数据中心：这些巨大的房间里摆满了大型、功能强大的计算机，噪音也很大。举例来说，许多数据中心的面积超过10万平方英尺，需要专门设计的空调系统来防止过热。 

托管式计算：多个组织机构聚集在同一平台下，共同托管其计算和存储能力，供其他企业使用。这是云计算的前身。

云计算：云计算利用远程服务器网络来存储、管理和处理数据。目前有很多云服务提供商，例如亚马逊网络服务 (AWS)、Azure 和谷歌云平台 (GCP)，它们主导着全球市场。云计算的托管、可用性、冗余等问题都由云服务提供商负责。许多企业都希望迁移到云计算，但迁移过程中会面临一些实际的挑战，需要加以考虑和克服。

应用程序的开发方式固然重要，但其交付方式同样重要。部署和打包的演变历程如下：

部署和打包

物理服务器：曾经，一台物理服务器只托管一个应用程序。以今天的标准来看，这效率非常低下。 

虚拟服务器：在一台物理服务器上可以运行多个虚拟机，这些虚拟机可以托管应用程序。

容器：容器化是企业在应用程序开发中采用的下一步技术。借助容器，多个应用程序及其所有依赖项可以托管在单个服务器上，而无需操作系统层作为中间层。 

你应该熟悉容器！如果你还不熟悉，请阅读《Docker for Dummies》和《Kubernetes for Dummies》。本文的其余部分假设你已经了解容器化和容器编排的基础知识。

DevOps最佳实践

我们已经看到，新技术催生了新的应用程序开发方式。如前所述，开发团队和运维团队之间经常存在问题，因此企业纷纷采用 DevOps 实践来简化开发流程。DevOps 工程师使用 OpenShift，因为它简化了云部署，并使他们能够遵循以下 DevOps 最佳实践：

一切皆代码：将系统的所有部分都视为代码的做法。

• 基础设施即代码：使用简单的工作流程，在几分钟内自动配置基础设施。（例如 Terraform、AWS CloudFormation）

• 环境即代码：只需一个工作流程即可在几分钟内构建和部署虚拟机环境。（例如 Vagrant、Docker）

• 配置即代码：基于模型的简单工作流程，可扩展应用程序部署和配置管理。（Ansible、Puppet、Chef）

• 数据管道即代码：以编程方式编写、调度和监控数据管道工作流（例如 Apache Airflow、Jenkins）。

• 安全配置即代码：大规模检测和修复构建及生产环境中的安全配置错误。（例如 Checkov）

• 加密管理即代码：以编程方式安全地存储和严格控制跨云和数据中心（例如 Vault、AWS KMS）的访问。

应用程序始终是“可发布的”：因为一切都是代码，所以它在任何时间点都是可发布的。

重建还是修复：这正是开发人员和运维人员之间产生摩擦（也就是所谓的集成地狱）的关键所在。例如，开发团队的某位成员修改了应用程序的开发环境，或者运维人员修改了生产环境的预发布版本。无论哪种情况，最终产品都无法反映双方的修改。正确的做法是，与其不断修改最终产品，不如创建一个黄金镜像，供所有人进行调整，并可随时发布。 

持续监控：您应该确保应用程序堆栈中没有恶意软件或安全漏洞，并且任何敏感信息（例如密码或密钥）都不会暴露给公众。

一切自动化：不要手动完成可以自动完成的事情，例如配置管理和测试。 

快速反馈：快速反馈循环是优秀开发团队的关键。快速反馈的目标是持续消除瓶颈。CI/CD 流水线就是一个简单的例子。

交付流水线：交付流水线可自动执行项目的持续部署。在项目的流水线中，一系列阶段会检索输入并运行作业，例如构建、测试和部署。

持续集成/持续交付或部署（CI/CD）： CI/CD 是一种频繁地向客户交付应用程序的方法。

持续集成：应用程序的新代码变更会定期构建、测试并合并到共享代码库中。这解决了同时开发多个应用程序分支可能导致冲突的问题。

持续交付：应用程序会自动进行错误测试并上传到存储库（例如 GitHub、DockerHub），然后可以将其部署到生产环境中。

持续部署：自动测试开发人员从代码库到生产环境的更改，以便客户可以使用。 

使用单体架构开发应用程序与使用微服务开发应用程序

考虑以下应用场景：一家航空公司想要开发一个航班预订应用。该应用需要包含三个主要部分：注册、支付和服务查询。 

单体架构：
单体架构存在一些严重的缺陷。所有三个主要领域必须紧密耦合才能运行。

在单体架构模型中，所有模块和程序都只能在一种类型的系统上运行，并且彼此依赖。这使得变更变得困难，并推高了扩展成本。此外，该系统的弹性也很低，因为一旦任何一个环节出现故障，整个系统都会崩溃，而故障可能由多种原因造成。例如，可能是硬件问题，也可能是应用程序接收到的流量超过了其设计处理能力。在这两种情况下，应用程序都会崩溃，整个系统都会瘫痪。

微服务：
在微服务架构中，您可以将业务功能拆分，使每个功能都拥有自己的一套独立资源。每个功能可能拥有自己的应用程序和数据库。这意味着您可以独立扩展这些服务，并且不会受限于应用程序堆栈所使用的技术。自治服务（微服务）使系统更具弹性、更灵活地应对变化、更易于扩展且更可用。借助 AWS 等云平台，您可以实现这些流程的自动化。

迁移到云端

在基础设施中使用虚拟机的一个显著问题是，它们无法跨虚拟机管理程序移植，因此无法为应用程序提供可移植的打包方式。所以在实践中，无法保证应用程序能够从员工的笔记本电脑顺利迁移到虚拟机或公有云。不同的操作系统层、不同的技术栈适用于不同的环境，因此移植性几乎不存在。正如之前在《Docker for Dummies》中解释的那样，像Docker这样的容器化软件可以解决这个问题。OpenShift 使用 Red Hat Enterprise Linux，其内核内置了容器守护程序，因此无需像Docker这样的容器化应用程序。

一个概念性的思考方式是将其视为微服务。如果您有数百个微服务，您肯定不希望为每个服务都配备数百台虚拟机，因为那样开销太大。这就是为什么企业如果想要采用微服务架构，容器化是必不可少的。以下是使用容器相对于虚拟机的优势概览：

我们已经讨论了IT基础设施、DevOps实践以及如何使用OpenShift管理容器。我们也探讨了使用OpenShift的一些优势，但OpenShift与Kubernetes有何不同？又该如何入门呢？

敬请期待第二部分，了解更多信息！

如果您喜欢这个系列文章，请点赞并留言。撰写这些文章需要花费大量精力，我非常期待您的反馈！此外，欢迎在Dev.to上关注我，获取更多类似文章，也可以在LinkedIn上与我联系！