对不起,OpenShift,我们没有足够感激你,把你视为理所当然

写这篇文章是因为我们的员工与客户就 Kubernetes 上的应用程序开发以及 OpenShift 上的此类开发的具体细节进行了大量对话。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

我们通常从这样的论点开始:Kubernetes 只是 Kubernetes,而 OpenShift 已经是一个 Kubernetes 平台,就像 Microsoft AKS 或 Amazon EKS 一样。 这些平台都有自己的优势,针对特定的目标受众。 之后,谈话转向比较特定平台的优缺点。

总的来说,我们在写这篇文章时想得出这样的结论:“听着,在哪里运行代码并不重要,是在 OpenShift 上还是在 AKS 上、在 EKS 上、在某些自定义 Kubernetes 上或在任何 Kubernetes 上” (为简洁起见,我们将其称为 KUK) “这真的很简单,无论是那里还是那里。”

然后我们打算以最简单的“Hello World”为例,展示KUC和红帽OpenShift容器平台(以下简称OCP或简称OpenShift)之间的共同点和区别。

然而,当我们写这篇文章时,我们意识到我们已经习惯使用 OpenShift 太久了,以至于我们根本没有意识到它是如何成长并变成一个令人惊叹的平台,而不仅仅是一个 Kubernetes 发行版。 我们往往认为 OpenShift 的成熟和简单是理所当然的,而忽视了它的辉煌。

总的来说,主动悔改的时候到了,现在我们将一步一步地比较我们的“Hello World”在KUK和OpenShift上的调试,我们将尽可能客观地做到这一点(好吧,除了有时会表现出个人对主题的态度)。 如果您对这个问题的纯粹主观意见感兴趣,那么您可以阅读它 这里 (EN)。 在这篇文章中,我们将坚持事实,而且只讲事实。

集群

所以,我们的“Hello World”需要集群。 我们将立即对任何公共云说“不”,以免为服务器、注册表、网络、数据传输等付费。 因此,我们选择一个简单的单节点集群 迷你酷 (对于 KUK)和 代码就绪容器 (对于 OpenShift 集群)。 这两个选项都非常易于安装,但需要笔记本电脑上的大量资源。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

在 KUK-e 上组装

所以,我们走吧。

第 1 步 – 构建容器镜像

让我们首先将“Hello World”部署到 minikube。 为此,您将需要:

  1. 1.安装了Docker。
  2. 2.安装Git。
  3. 3.安装Maven(实际上,这个项目使用mvnw二进制文件,所以你可以不用它)。
  4. 4. 实际上,来源本身,即存储库克隆 github.com/gcolman/quarkus-hello-world.git

第一步是创建 Quarkus 项目。 如果您从未使用过 Quarkus.io,请不要惊慌 - 这很简单。 您只需选择要在项目中使用的组件(RestEasy、Hibernate、Amazon SQS、Camel 等),然后 Quarkus 本身在没有您任何参与的情况下配置 Maven 原型并将所有内容放在 github 上。 也就是说,只需单击一下鼠标即可完成。 这就是我们喜爱 Quarkus 的原因。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

将“Hello World”构建到容器映像中的最简单方法是使用 Docker 的 quarkus-maven 扩展,它将完成所有必要的工作。 随着 Quarkus 的出现,这变得非常简单:添加 container-image-docker 扩展,您就可以使用 maven 命令创建图像。

./mvnw quarkus:add-extension -Dextensions=”container-image-docker”

最后,我们使用 Maven 构建镜像。 这样,我们的源代码就变成了一个现成的容器镜像,可以在容器运行时环境中运行。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

./mvnw -X clean package -Dquarkus.container-image.build=true

就这样,现在你可以使用 docker run 命令启动容器,将我们的服务映射到 8080 端口,以便可以访问。

docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

容器实例启动后,剩下的就是使用curl命令检查我们的服务是否正在运行:

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

所以一切都很顺利,而且非常简单。

步骤 2 – 将我们的容器发送到容器镜像存储库

目前,我们创建的图像存储在本地容器存储中。 如果我们想在 COOK 环境中使用此映像,则必须将其放置在其他存储库中。 Kubernetes没有这样的功能,所以我们将使用dockerhub。 因为,首先,它是免费的,其次,(几乎)每个人都这样做。

这个也很简单,只需要一个dockerhub账号就可以了。

因此,我们安装 dockerhub 并将图像发送到那里。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

第 3 步 – 启动 Kubernetes

有很多方法可以组装 kubernetes 配置来运行我们的“Hello World”,但我们将使用其中最简单的一种,这就是我们的方式......

首先,让我们启动 minikube 集群:

minikube start

第 4 步 – 部署我们的容器镜像

现在我们需要将代码和容器镜像转换为 kubernetes 配置。 换句话说,我们需要一个指向 dockerhub 上容器镜像的 Pod 和部署定义。 最简单的方法之一是运行指向我们的映像的创建部署命令:

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT

通过此命令,我们告诉 COO 创建部署配置,其中应包含容器映像的 pod 规范。 此命令还将将此配置应用于我们的 minikube 集群,并创建一个部署来下载我们的容器映像并在集群中启动 pod。

第 5 步 – 开放对我们服务的访问

现在我们已经部署了容器镜像,是时候考虑如何配置对这个 Restful 服务的外部访问了,事实上,它是在我们的代码中编写的。

这里有很多方法。 例如,您可以使用公开命令自动创建适当的 Kubernetes 组件,例如服务和端点。 实际上,这就是我们将通过为部署对象执行公开命令来执行的操作:

kubectl expose deployment hello-quarkus — type=NodePort — port=8080

让我们花点时间看一下公开命令的“-type”选项。

当我们公开并创建运行服务所需的组件时,我们需要能够从外部连接到位于我们软件定义网络内部的 hello-quarkus 服务。 及参数 类型 允许我们创建和连接负载均衡器之类的东西,以将流量路由到该网络。

例如,通过写 类型=负载均衡器,我们自动在公共云中配置一个负载均衡器来连接到我们的 Kubernetes 集群。 这当然很棒,但您需要了解,这样的配置将严格绑定到特定的公共云,并且在不同环境中的 Kubernetes 实例之间传输会更加困难。

在我们的例子中 类型=节点端口,即通过节点的IP地址和端口号来访问我们的服务。 此选项允许您不使用任何公共云,但需要一些额外的步骤。 首先,您需要自己的负载均衡器,因此我们将在集群中部署 NGINX 负载均衡器。

第 6 步 – 安装负载均衡器

minikube 具有许多平台功能,可以更轻松地创建外部可访问的组件,例如入口控制器。 Minikube 与 Nginx 入口控制器捆绑在一起,我们所要做的就是启用它并配置它。

minikube addons enable ingress

现在我们将只用一个命令创建一个 Nginx 入口控制器,它将在我们的 minikube 集群中工作:

ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m

第 7 步 – 设置入口

现在我们需要配置 Nginx 入口控制器,以便它接受 hello-quarkus 请求。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

最后,我们需要应用此配置。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

kubectl apply -f ingress.yml

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

由于我们是在自己的计算机上完成所有这些操作,因此我们只需将节点的 IP 地址添加到 /etc/hosts 文件中,即可将 http 请求路由到我们的 minikube 到 NGINX 负载均衡器。

192.168.99.100 hello-quarkus.info

就是这样,现在我们的 minikube 服务可以通过 Nginx 入口控制器从外部访问。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

嗯,这很容易,对吧? 或者不是真的?

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

在 OpenShift 上运行(代码就绪容器)

现在让我们看看这一切是如何在红帽 OpenShift 容器平台 (OCP) 上完成的。

与 minikube 一样,我们选择 Code Ready Containers (CRC) 形式的单节点 OpenShift 集群设计。 以前,它被称为 minishift,基于 OpenShift Origin 项目,但现在它是 CRC,基于红帽的 OpenShift 容器平台构建。

在此,抱歉,我们不得不说:“OpenShift 太棒了!”

最初,我们认为 OpenShift 上的开发与 Kubernetes 上的开发没有什么不同。 本质上就是这样。 但在撰写这篇文章的过程中,我们记得当您没有 OpenShift 时,您必须进行多少额外的操作,这就是为什么它再次很棒。 我们喜欢一切都可以轻松完成,与 minikube 相比,我们的示例在 OpenShift 上部署和运行是多么容易,这也是促使我们写这篇文章的原因。

让我们回顾一下整个过程,看看我们需要做什么。

因此,在 minikube 示例中,我们从 Docker 开始……等等,我们不再需要在机器上安装 Docker。

而且我们不需要本地 git。
并且不需要 Maven。
而且您不必亲手创建容器镜像。
而且您不必寻找任何容器镜像存储库。
并且无需安装入口控制器。
而且你也不需要配置 ingress。

你明白吧? 要在 OpenShift 上部署和运行我们的应用程序,您不需要上述任何内容。 这个过程本身看起来像这样。

步骤 1 – 启动您的 OpenShift 集群

我们使用 Red Hat 的 Code Ready Containers,它本质上与 Minikube 相同,但仅具有成熟的单节点 Openshift 集群。

crc start

步骤 2 – 构建应用程序并将其部署到 OpenShift 集群

正是在这一步,OpenShift 的简单性和便利性才得以彰显。 与所有 Kubernetes 发行版一样,我们有多种方法在集群中运行应用程序。 而且,就像 KUK 的情况一样,我们专门选择了最简单的一个。

OpenShift 始终被构建为用于创建和运行容器化应用程序的平台。 容器构建一直是该平台不可或缺的一部分,因此有大量额外的 Kubernetes 资源用于相关任务。

我们将使用 OpenShift 的 Source 2 Image (S2I) 流程,该流程有多种不同的方式来获取源代码(代码或二进制文件)并将其转换为在 OpenShift 集群上运行的容器化镜像。

为此,我们需要做两件事:

  • 我们的源代码在git存储库中
  • 将在其基础上执行构建的构建器映像。

Red Hat 和社区层面都维护着许多这样的镜像,我们将使用 OpenJDK 镜像,因为我正在构建一个 Java 应用程序。

您可以从 OpenShift Developer 图形控制台和命令行运行 S2I 构建。 我们将使用 new-app 命令,告诉它从哪里获取构建器映像和源代码。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git

就这样,我们的应用程序就创建好了。 为此,S2I 进程执行了以下操作:

  • 为与构建应用程序相关的各种事情创建了一个服务构建容器。
  • 创建了 OpenShift 构建配置。
  • 我将构建器映像下载到内部 OpenShift docker 注册表。
  • 将“Hello World”克隆到本地存储库。
  • 我看到那里有一个maven pom,所以我使用maven编译了应用程序。
  • 创建一个包含已编译的 Java 应用程序的新容器映像,并将该映像放入内部容器注册表中。
  • 创建 Kubernetes 部署,其中包含 Pod、服务等规范。
  • 我开始部署容器镜像。
  • 删除了服务 build-pod。

这个列表中有很多内容,但最主要的是整个构建仅在 OpenShift 内部进行,内部 Docker 注册表位于 OpenShift 内部,构建过程创建所有 Kubernetes 组件并在集群中运行它们。

如果您在控制台中直观地监控 S2I 的启动,您可以看到构建完成后构建 Pod 是如何启动的。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

现在让我们看一下构建器 Pod 日志:首先,它显示了 Maven 如何完成其​​工作并下载依赖项来构建我们的 Java 应用程序。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

maven构建完成后,就开始容器镜像的构建,然后将这个构建好的镜像发送到内部仓库。

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

就这样,构建过程就完成了。 现在让我们确保应用程序的 Pod 和服务在集群中运行。

oc get service

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

就这样。 而且只有一支球队。 我们所要做的就是公开此服务以供外部访问。

步骤 3 – 公开服务以供外部访问

与 KUC 的情况一样,在 OpenShift 平台上,我们的“Hello World”也需要一个路由器来将外部流量引导至集群内的服务。 OpenShift 让这一切变得非常简单。 首先集群中默认安装了HAProxy路由组件(可以改为同一个NGINX)。 其次,有一些特殊且高度可配置的资源,称为路由,让人想起旧式 Kubernetes 中的 Ingress 对象(事实上,OpenShift 的路由极大地影响了 Ingress 对象的设计,现在可以在 OpenShift 中使用),但是对于我们的“Hello World” ,而在几乎所有其他情况下,标准 Route 对我们来说就足够了,无需额外配置。

要为“Hello World”创建可路由的 FQDN(是的,OpenShiift 有自己的 DNS,用于按服务名称进行路由),我们只需公开我们的服务:

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

oc expose service quarkus-hello-world

如果查看新创建的路由,您可以在其中找到 FQDN 和其他路由信息:

oc get route

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

最后,我们从浏览器访问我们的服务:

对不起,OpenShift,我们没有足够感激你,把你视为理所当然

但现在真的很容易!

我们喜欢 Kubernetes 以及这项技术允许我们做的一切,我们也喜欢它的简单性和易用性。 Kubernetes 的创建是为了极大地简化分布式、可扩展容器的操作,但其简单性如今已不足以将应用程序投入生产。 这就是 OpenShift 发挥作用的地方,它与时俱进并提供 Kubernetes,主要针对开发人员。 我们投入了大量精力专门为开发人员定制 OpenShift 平台,包括创建 S2I、ODI、开发人员门户、OpenShift Operator Framework、IDE 集成、开发人员目录、Helm 集成、监控等工具。

我们希望这篇文章对您来说有趣且有用。 您可以在门户上找到对 OpenShift 平台上的开发有用的其他资源、材料和其他内容 红帽开发人员.

来源: habr.com

添加评论