申し訳ありません、OpenShift、私たちはあなたに十分に感謝せず、あなたを当然のことだと思っていました

この投稿は、Kubernetes でのアプリケーション開発や OpenShift でのそのような開発の詳細について、当社のスタッフがクライアントとかなりの数の会話を行ったために書かれました。

私たちは通常、Kubernetes は単なる Kubernetes であり、OpenShift はすでに Microsoft AKS や Amazon EKS のような Kubernetes プラットフォームであるという仮説から始めます。 これらのプラットフォームにはそれぞれ、特定の対象ユーザーに焦点を当てた独自の利点があります。 その後、会話はすでに特定のプラットフォームの長所と短所の比較に流れています。

一般的に、私たちはこの記事を次のような結論で書こうと考えていました。「OpenShift 上でも、AKS 上でも、EKS 上でも、カスタム Kubernetes 上でも、どの Kubernetes 上でも、コードをどこで実行するかは関係ありません」 (略してKUKと呼びます) 「あそこもあそこも本当にシンプルなんです。」

次に、最も単純な「Hello World」を使用して、CMC と Red Hat OpenShift Container Platform (以下、OCP または単に OpenShift) の共通点と相違点を示すことを計画しました。

しかし、この記事を書いているうちに、私たちは長い間 OpenShift を使用することに慣れていたため、OpenShift がどのように成長し、単なる Kubernetes ディストリビューションをはるかに超えた素晴らしいプラットフォームに変わったのかを全く理解していなかったことがわかりました。 私たちは OpenShift の成熟度とシンプルさを当然のことと考え、その素晴らしさを見失いがちです。

一般に、積極的に悔い改めるべき時が来ました。ここで、KUK と OpenShift での「Hello World」のコミッショニングを段階的に比較し、可能な限り客観的に比較してみます (まあ、個人的なものを時々示すことを除いて)主題に対する態度）。 この問題に関する純粋に主観的な意見に興味がある場合は、読んでください。 こちら (英語)。 そしてこの投稿では、事実のみにこだわります。

クラスター

したがって、「Hello World」にはクラスターが必要です。 サーバー、レジストリ、ネットワーク、データ転送などの費用を支払わないように、パブリック クラウドには「ノー」と言いましょう。 したがって、単純な XNUMX ノード クラスターを選択します。 Minikube (KUK用)と コード対応コンテナ (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 に配置します。 つまり、文字通りマウスを XNUMX 回クリックするだけで完了します。 これが私たちがQuarkusを愛する理由です。

「Hello World」をコンテナー イメージに構築する最も簡単な方法は、必要な作業をすべて実行する Docker 用の quarkus-maven 拡張機能を使用することです。 Quarkus の登場により、これは非常に簡単かつシンプルになりました。container-image-docker 拡張機能を追加すると、Maven コマンドを使用してイメージを作成できるようになります。

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

最後に、Maven を使用してイメージを構築します。 その結果、ソース コードは既製のコンテナー イメージになり、コンテナー ランタイムですでに実行できるようになります。

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

これで、docker run コマンドを使用してコンテナーを起動し、サービスをポート 8080 にマッピングしてアクセスできるようになります。

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

コンテナー インスタンスが起動したら、あとはサービスが実行されていることをcurl コマンドで確認するだけです。

したがって、すべてがうまくいき、非常に簡単でシンプルでした。

ステップ 2 - コンテナをコンテナ イメージ リポジトリに送信する

今のところ、作成したイメージはローカルのコンテナ ストレージに保存されています。 このイメージを COOK 環境で使用したい場合は、他のリポジトリに配置する必要があります。 Kubernetes にはそのような機能がないため、dockerhub を使用します。 なぜなら、第一に、それは無料であり、第二に、（ほぼ）誰もがそれを行うからです。

これも非常に簡単で、ここで必要なのは dockerhub アカウントのみです。

そこで、dockerhub をインストールし、イメージをそこに送信します。

ステップ 3 - Kubernetes を開始する

「Hello World」を実行するために Kubernetes 構成をまとめる方法はたくさんありますが、私たちはそのような人間なので、そのうちの最も単純な方法を使用します。

まず、minikube クラスターを起動しましょう。

minikube start

ステップ 4 - コンテナ イメージのデプロイ

次に、コードとコンテナー イメージを kubernetes 構成に変換する必要があります。 つまり、dockerhub 上のコンテナー イメージを指すポッドとデプロイメント定義が必要です。 これを行う最も簡単な方法の XNUMX つは、イメージを指定して createdeployment コマンドを実行することです。

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

このコマンドを使用して、COO に、コンテナー イメージのポッド仕様を含むデプロイメント構成を作成するように指示しました。 このコマンドは、この構成を minikube クラスターにも適用し、コンテナー イメージをダウンロードしてクラスター上でポッドを実行するデプロイメントを作成します。

ステップ 5 - 当社のサービスへのオープンアクセス

コンテナー イメージをデプロイしたので、この Restful サービスへの外部アクセスを構成する方法を考えます。実際、このサービスはコードでプログラムされています。

ここにはたくさんの方法があります。 たとえば、expose コマンドを使用して、サービスやエンドポイントなどの適切な Kubernetes コンポーネントを自動的に作成できます。 実際には、これは、デプロイメント オブジェクトに対して Expose コマンドを実行することで行うことになります。

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

ここでは、expose コマンドの「-type」オプションに注目してみましょう。

サービスの実行に必要なコンポーネントを公開して作成する場合、特に、ソフトウェア定義ネットワーク内にある hello-quarkus サービスに外部から接続できる必要があります。 そしてパラメータ type これにより、ロード バランサーなどを作成して接続し、そのネットワークにトラフィックをルーティングできるようになります。

たとえば、書くこと type=ロードバランサー、Kubernetes クラスターに接続するためにパブリック クラウド ロード バランサーを自動的に初期化します。 これはもちろん素晴らしいことですが、そのような構成は特定のパブリック クラウドに密接に結び付けられ、異なる環境にある Kubernetes インスタンス間で転送するのがより困難になることを理解する必要があります。

私たちの例では type=ノードポートつまり、サービスはノードの IP アドレスとポート番号によってアクセスされます。 このオプションを使用すると、パブリック クラウドを使用しなくても済みますが、いくつかの追加手順が必要になります。 まず、独自のロード バランサーが必要なので、NGINX ロード バランサーをクラスターにデプロイします。

ステップ 6 – ロードバランサーをインストールする

minikube には、イングレス コントローラーなど、外部アクセスに必要なコンポーネントを簡単に作成できるプラットフォーム機能が多数あります。 Minikube は Nginx Ingress コントローラーにバンドルされており、必要なのはそれを有効にして設定することだけです。

minikube addons enable ingress

ここで、たった XNUMX つのコマンドで、minikube クラスター内で動作する Nginx Ingress コントローラーを作成します。

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

ステップ 7 - イングレスをセットアップする

次に、Hello-quarkus リクエストを受け入れるように Nginx Ingress コントローラーを構成する必要があります。

最後に、この構成を適用する必要があります。

kubectl apply -f ingress.yml

これらすべてを独自のマシンで実行しているため、ノードの IP アドレスを /etc/hosts ファイルに追加して、minikube への http リクエストを NGINX ロード バランサーに送信するだけです。

192.168.99.100 hello-quarkus.info

これで、minikube サービスが Nginx Ingress コントローラーを介して外部から利用できるようになりました。

まあ、それは簡単でしたね? それともそれほどではないでしょうか？

OpenShift で実行 (Code Ready Containers)

それでは、Red Hat OpenShift Container Platform (OCP) ですべてがどのように行われるかを見てみましょう。

minikube と同様に、Code Ready Containers (CRC) の形式でシングルノード OpenShift クラスター設計を選択します。 以前は minishift と呼ばれ、OpenShift Origin プロジェクトに基づいていましたが、現在は CRC となり、Red Hat の OpenShift Container Platform 上に構築されています。

ここでは、申し訳ありませんが、「OpenShift は素晴らしいです!」と言わざるを得ません。

当初、OpenShift での開発は Kubernetes での開発と変わらないと書こうと考えていました。 そして実際、その通りです。 しかし、この記事を書いている過程で、OpenShift がない場合はどれだけ多くの余分な動作をしなければならないかを思い出しました。だからこそ、OpenShift は素晴らしいのです。 私たちは、すべてが簡単に完了することをとても気に入っています。minikube と比較して、OpenShift 上でのサンプルのデプロイと実行がいかに簡単であるかが、この記事を書くきっかけになりました。

プロセスを確認して、何をする必要があるかを見てみましょう。

したがって、minikube の例では、Docker から始めました…待て、もうマシンに Docker をインストールする必要はありません。

ローカル git も必要ありません。
そしてMavenは必要ありません。
また、コンテナー イメージを手動で作成する必要もありません。
また、コンテナー イメージのリポジトリを探す必要もありません。
また、イングレス コントローラーをインストールする必要もありません。
また、イングレスを設定する必要もありません。

わかりますか？ 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 クラスター上で実行されるコンテナ化されたイメージに変換するいくつかの異なる方法があります。

これを行うには、次の XNUMX つのことが必要です。

• git リポジトリ内のソース コード
• アセンブリの実行に基づいてビルダー イメージ。

このようなイメージは Red Hat とコミュニティの両方によって保守されており、数多くあります。私は Java アプリケーションを構築しているので、OpenJDK イメージを使用します。

S2I ビルドは、OpenShift Developer グラフィカル コンソールとコマンドラインの両方から実行できます。 new-app コマンドを使用して、ビルダー イメージとソース コードを取得する場所を指示します。

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

以上で、アプリケーションが作成されました。 その際、S2I プロセスは次のことを実行しました。

• アプリケーションの構築に関連するあらゆる種類のサービス build-pod を作成しました。
• OpenShift ビルド構成を作成しました。
• ビルダー イメージを OpenShift 内部 Docker レジストリにダウンロードしました。
• 「Hello World」をローカル リポジトリにクローンしました。
• そこに maven pom があることに気づき、maven でアプリをコンパイルしました。
• コンパイルされた Java アプリケーションを含む新しいコンテナー イメージを作成し、このイメージを内部コンテナー レジストリに配置します。
• ポッド、サービスなどの仕様を含む Kubernetes デプロイメントを作成しました。
• コンテナイメージのデプロイを開始しました。
• サービス build-pod を削除しました。

このリストにはたくさんの項目がありますが、重要なのは、ビルド全体が OpenShift 内で排他的に行われ、内部 Docker レジストリーが OpenShift 内にあり、ビルド プロセスですべての Kubernetes コンポーネントが作成され、クラスター内で実行されるということです。

コンソールで S2I の起動を視覚的に監視すると、ビルド中にビルド ポッドがどのように起動されるかを確認できます。

次に、ビルダー ポッドのログを見てみましょう。まず、Maven がどのようにジョブを実行し、依存関係をダウンロードして Java アプリケーションを構築するかを示します。

Maven のビルドが完了すると、コンテナー イメージのビルドが開始され、このビルドされたイメージが内部リポジトリに送信されます。

以上で組み立て工程は完了です。 次に、アプリケーションのポッドとサービスがクラスター内で開始されていることを確認しましょう。

oc get service

それだけです。 しかもXNUMXチームだけ。 私たちがしなければならないのは、このサービスを外部からアクセスできるように公開することだけです。

ステップ 3 – 外部からのアクセスのためにサービスを公開する

KUC の場合と同様、OpenShift プラットフォーム上の「Hello World」にも、外部トラフィックをクラスター内のサービスに送信するルーターが必要です。 OpenShift を使用すると、これが非常に簡単になります。 まず、HAProxy ルーティング コンポーネントはデフォルトでクラスターにインストールされます (同じ NGINX に変更できます)。 第 XNUMX に、Routes と呼ばれる特別で高度にカスタマイズ可能なリソースがあり、古き良き Kubernetes の Ingress オブジェクトに似ています (実際、OpenShift の Routes は Ingress オブジェクトの設計に大きな影響を与えており、現在 OpenShift で使用できます)。 、その他のほとんどすべてのケースでは、追加の設定を行わなくても、標準の Route で十分です。

「Hello World」のルーティング可能な FQDN を作成するには (はい、OpenShiift にはサービス名によるルーティング用の独自の DNS があります)、単純にサービスを公開します。

oc expose service quarkus-hello-world

新しく作成されたルートを見ると、FQDN とその他のルーティング情報が見つかります。

oc get route

最後に、ブラウザからサービスにアクセスします。

でも今では本当に簡単になりました！

私たちは Kubernetes とこのテクノロジで実行できるすべての機能を愛しており、シンプルさと軽さも大好きです。 Kubernetes は、分散型のスケーラブルなコンテナを信じられないほど簡単に操作できるように設計されていますが、そのシンプルさは、今日アプリケーションを運用環境に導入するには十分ではありません。 ここで OpenShift が登場します。OpenShift は時代に対応し、主に開発者に焦点を当てた Kubernetes を提供します。 S2I、ODI、開発者ポータル、OpenShift Operator Framework、IDE 統合、開発者カタログ、Helm 統合、モニタリングなどのツールの作成を含め、OpenShift プラットフォームを開発者専用に調整するために多くの努力が費やされてきました。

この記事が興味深く、お役に立てば幸いです。 ポータルでは、OpenShift プラットフォームでの開発に役立つ追加のリソース、資料、その他のものを見つけることができます。 レッドハット開発者.

出所： habr.com