NocalhostとKubeVelaを使用してエンドクラウドを調整し、ワンクリックでマルチクラスターハイブリッドクラウド環境の展開を完了します。

著者 | Wuwu、Yu Yicai (KubeVela、Nocalhost チーム)

クラウドネイティブが急速に発展する中、クラウドテクノロジーはビジネス開発をどのように強化できるのでしょうか?アプリケーションを起動するときに、クラウド開発者はどのようにして最新のマルチクラスターのハイブリッドクラウド環境でアプリケーションを簡単に開発およびデバッグできるでしょうか?展開プロセス中に、アプリケーションの展開を完全に検証し、信頼性を確保するにはどうすればよいでしょうか?

これらは緊急に解決しなければならない重要な問題です。

この記事では、KubeVela と Nocalhost のオープンソースプロジェクトを組み合わせて、エンドクラウドの共同デバッグとマルチクラスターハイブリッド環境のワンクリック展開を実現する Kubernetes とコンテナーエコロジーに基づくソリューションを提供し、上記の質問に答えます。

新しいアプリケーションを開発して起動する必要がある場合、ローカル IDE でのデバッグ結果がクラウドでの最終的な展開ステータスと一致することを期待します。この一貫した姿勢により、デプロイメントに最大限の自信が得られ、GitOps のようにより効率的かつ俊敏な方法でアプリケーションの更新を繰り返すことができます。つまり、新しいコードがコードリポジトリにプッシュされると、環境内のアプリケーションがリアルタイムで自動的に更新されます。同時に、エンドクラウド共同デバッグモデルにより、プロセス全体が俊敏かつ効率的になるだけでなく、安定性と信頼性も向上します。

KubeVela と Nocalhost に基づいて、次のデプロイメントプロセスを完了できます。

図に示すように、KubeVela を通じてアプリケーションを作成し、アプリケーションをテスト環境にデプロイしてから、デプロイを一時停止します。 Nocalhost を使用して、テスト環境でアプリケーションのクラウドベースの共同デバッグを実行します。デバッグが完了すると、デバッグされたコードはコードリポジトリにプッシュされ、KubeVela を介して GitOps でデプロイされ、テスト環境で検証された後、本番環境に更新されます。

この記事では、KubeVela と Nocalhost を使用して、上記のクラウドアプリケーションの開発と起動のプロセス全体を完了する方法を紹介します。

1. KubeVelaとは

KubeVela は、Kubernetes と OAM テクノロジーに基づいて構築された、使いやすく、拡張性に優れたアプリケーション配信および管理プラットフォームです。その主な機能は、開発者が Kubernetes 自体の詳細を理解しなくても、Kubernetes 上で最新のマイクロサービスアプリケーションを簡単かつ迅速に定義して提供できるようにすることです。

KubeVela は、アプリケーション配布プロセス全体を視覚化し、アプリケーションの組み立て、配布、配信プロセスを簡素化できる VelaUX 機能を提供します。 UX の観点では、ページを通じて配信チェーン全体のステータスをすばやく簡単に把握できるだけでなく、製品リポジトリが更新されるとアプリケーションを更新するトリガーを構成することもできます。

この記事のシナリオでは、KubeVela は次の機能を提供します。

1. GitOpsリリースを完了する:

KubeVela は、プルモードとプッシュモードの両方の GitOps リリースをサポートしています。更新されたコードをコードリポジトリにプッシュするだけで、KubeVela は最新のコードに基づいて自動的にデプロイメントを完了できます。この記事では、GitOps を Push モードで使用します。 PullモードでのGitOpsサポートの詳細については、この記事の最後にある記事[1]を参照してください。

2. 環境間（クラスター）の展開、承認、通知を実現する強力なワークフロー機能：

KubeVela はワークフロー機能を備えているため、環境間でアプリケーションを簡単にデプロイでき、ワークフローをオーケストレーションするプロセスで手動承認やメッセージ通知などの機能を追加して、デプロイプロセス全体を本番レベルで利用できるようにします。

3. アプリケーション抽象化機能により、開発者はインフラストラクチャの機能を理解してカスタマイズできる

KubeVela は OAM のオープンアプリケーションモデルに準拠し、シンプルで使いやすい一連のアプリケーション抽象化機能を提供します。これにより、開発者はアプリケーションの機能をより明確に理解し、インフラストラクチャ機能をカスタマイズできます。たとえば、単純なアプリケーションの場合は、コンポーネント、運用と保守の機能、ワークフローの 3 つの部分に分けることができます。この記事の例では、コンポーネントは単純なビジネスアプリケーションです。運用保守機能部分では、このコンポーネントが Nocalhost エンドクラウド共同デバッグ機能を使用できるように、Nocalhost 運用保守機能をこのコンポーネントにバインドします。ワークフロー部分では、マルチ環境管理を通じて、まずこのコンポーネントをテスト環境にデプロイし、デプロイが完了したら手動で検証および承認されるまでワークフローのリリースを自動的に一時停止し、その後実稼働環境にデプロイすることができます。

2. Nocalhostとは

Nocalhost は、開発者が Kubernetes クラスター内で直接アプリケーションを開発できるようにするツールです。

Nocalhost のコア機能は、Nocalhost IDE プラグイン (VSCode および Jetbrains プラグインを含む) を提供し、リモートワークロードを開発モードに変更することです。開発モードでは、コンテナのイメージが開発ツール (JDK、Go、Python 環境など) を含む開発イメージに置き換えられます。開発者がローカルでコードを記述すると、変更はリモート開発コンテナにリアルタイムで同期され、アプリケーションは即座に更新され (アプリケーションのホットリロードメカニズムまたはアプリケーションの再実行に応じて)、開発コンテナは元のワークロードのすべての宣言型構成 (ConfigMap、Secret、Volume、Env など) を継承します。

Nocalhost は、VSCode および Jetbrains IDE のワンクリックデバッグとホットリロードも提供します。 IDE 内で直接開発コンテナ用のターミナルを提供し、ローカル開発と一貫したエクスペリエンスを実現します。名前空間の分離に基づいて開発スペースとメッシュ開発スペースを提供します。さらに、Nocalhost は、企業が Kubernetes アプリケーション、開発者、開発スペースを管理できるようにサーバー側も提供しており、企業がさまざまな開発環境やテスト環境を統一的に管理しやすくなります。

Nocalhost を使用して Kubernetes アプリケーションを開発すると、イメージの構築、イメージバージョンの更新、クラスターが Pod をスケジュールするのを待つというプロセスがなくなり、コード/テスト/デバッグのフィードバックサイクルが数分から数秒に短縮され、開発効率が大幅に向上します。

3. クラウドアプリケーションのデバッグ

簡単なフロントエンドアプリケーションを例に挙げてみましょう。まず、VelaUX を使用して複数の環境に展開します。

KubeVelaでVelaUXプラグインを有効にする方法については、この記事の最後にある公式ドキュメント[2]を参照してください。

1. VelaUXを使用してクラウドアプリケーションを展開する

VelaUX で環境を作成します。各環境には複数のデプロイメントターゲットを設定できます。例として、テスト展開ターゲットと本番展開ターゲットを含む環境を見てみましょう。

まず、テスト展開用と本番展開用の 2 つの展開ターゲットを作成します。ここでのデプロイメントターゲットは、ローカルクラスターの test 名前空間と prod 名前空間にそれぞれリソースを送信します。 VelaUX のクラスター管理機能を使用して、展開用の新しいクラスターを追加することもできます。

デプロイメントターゲットを作成したら、2 つのデプロイメントターゲットを含む新しい環境を作成します。

環境を作成したら、クラウドデバッグ用の新しいアプリケーションを作成します。このフロントエンドアプリケーションはポート 80 でサービスを公開するため、このアプリケーションのポート 80 を開きます。

アプリケーションを作成すると、アプリケーションを 2 つのデプロイメントターゲットに自動的にデプロイするワークフローがデフォルトで付属します。しかし、デバッグされていないアプリケーションを本番環境に直接デプロイすることは望ましくありません。そこで、このデフォルトのワークフローを編集して、テストターゲットへのデプロイと本番ターゲットへのデプロイの間に一時停止ステップを追加します。この方法では、テスト環境にデプロイした後でデプロイを一時停止し、ユーザーがデバッグと検証を行うのを待ってから、本番環境へのデプロイを続行することができます。

これらの構成が完了したら、クラウドデバッグ用にこのアプリケーションに Nocalhost 特性を追加しましょう。

ここでは、Nocalhost Trait のいくつかのパラメータを詳しく紹介します。

コマンドには、デバッグと実行の 2 種類があります。開発時に、プラグインで「リモートデバッグ」または「リモート実行」を右クリックすると、リモート Pod で対応するコマンドが実行され、クラウドデバッグの効果が得られます。ここではフロントエンドアプリケーションを使用しているため、コマンドを yarn serve に設定します。

ここでのイメージはデバッグイメージを指します。 Nocalhost はデフォルトで 5 つの言語のイメージを提供します (go/java/python/ruby/node)。言語名を入力することで組み込みイメージを使用できます。もちろん、完全な画像名を入力してカスタム画像を使用することもできます。

HotReload をオンにすると、ホットリロード機能が有効になり、コードを変更した後でその効果を直接確認できるようになります。 PortForward は、クラウドアプリケーションのポート 80 をローカルポート 8080 に転送します。

同期セクションで、タイプを sendReceive (双方向同期) または send (一方向送信) に設定します。設定が完了したら、アプリケーションをデプロイします。ご覧のとおり、アプリケーションはテストターゲットにデプロイされた後、自動的に一時停止されます。

この時点で、VSCode または Jetbrains IDE で Nocalhost プラグインページを開くと、テスト名前空間の下にデプロイされたアプリケーションが表示されます。アプリケーションの横にあるハンマーボタンをクリックしてデバッグモードに入ります。

Nocalhost デバッグモードに入ると、IDE 内のターミナルがコンテナのターミナルに置き換えられていることがわかります。 ls コマンドを使用すると、コンテナ内のすべてのファイルを確認できます。

この時点で、Nocalhost でアプリケーションを右クリックし、リモートデバッグモードまたはリモート実行モードに入ることを選択します。これら 2 つのボタンは、以前に構成したデバッグコマンドと実行コマンドを自動的に実行します。

デバッグモードに入ると、クラウドアプリケーションがローカルポート 8080 に転送されていることがわかります。

ローカルブラウザーを開くと、現在デプロイされているフロントエンドアプリケーションのバージョンが v1.0.0 であることがわかります。

この時点で、ローカル IDE でコードを変更し、バージョンを v2.0.0 に変更できます。

以前の Nocalhost 構成では、ホットリロード機能を有効にしました。したがって、ローカル 8080 ポートページを再度更新すると、アプリケーションバージョンが v2.0.0 になっていることがわかります。

この時点で、Nocalhost のデバッグモードを終了できます。デバッグされたコードをコードリポジトリにプッシュします。

4. 複数環境リリースにはGitOpsを使用する

デバッグが完了した後も、環境内のアプリケーションは以前のバージョン v1.0.0 のままです。では、環境内のアプリケーションを更新するにはどのような方法を使用すればよいでしょうか?

クラウドのデバッグプロセス全体を通じて、ソースコードを変更します。したがって、GitOps モデルを使用して、コードを更新ソースとして使用し、環境内のアプリケーションを更新できます。

VelaUX にデプロイされたアプリケーションを見ると、各アプリケーションにデフォルトのトリガーがあることがわかります。

詳細を表示するには、「手動トリガー」をクリックします。 VelaUX が各アプリケーションに Webhook URL を提供していることがわかります。 URL をリクエストし、更新が必要なフィールド (画像など) を含めることで、アプリケーションをすばやく簡単に更新できます。 (注: アドレスを外部に公開する必要があるため、VelaUX をデプロイするときには、LoadBalancer またはその他の方法を使用して VelaUX サービスを公開する必要があります)。

Curl コマンドでは、トリガーを手動で curl するためのリクエスト例も提供されています。リクエスト本文を詳しく解析してみましょう。

 {
 //必須、今回トリガーされた更新情報
「アップグレード」 : {
 //キーはアプリケーションの名前です
"<アプリケーション名>" : {
 //更新する必要がある値。ここのコンテンツはパッチによってアプリケーションに更新されます
"画像" : "<画像名>"
 }
 } 、
 //オプション、このトリガーによって運ばれるコード情報
"コード情報" : {
 "コミット" : "<コミットID>" ,
 "ブランチ" : "<ブランチ>" ,
 "ユーザー" : "<ユーザー>" ,
 }
 }

「アップグレード」の下には、このトリガーによって実行される更新情報があり、「アプリケーション名」の下には、パッチによって更新する必要がある値があります。デフォルトでは、イメージを更新することが推奨されます。ここでフィールドを展開して、アプリケーションの他のプロパティを更新することもできます。

codeInfo には、コミット ID、ブランチ、コミッターなどのオプションで伝送できるコード情報が含まれます。通常、これらの値は、CI システムで変数置換を使用して指定できます。

更新されたコードがコードリポジトリにマージされると、コードリポジトリの CI 構成を通じて VelaUX Trigger との接続を完了できます。 GitLab CI を例にとると、次の手順を追加できます。

 Webhook -リクエスト:
 ステージ:リクエスト
 前スクリプト:
 - apk を追加--update curl && rm -rf /var/cache/apk/*
 スクリプト:
 - |
 curl - " $CI_COMMIT_BRANCH" '"}}' $WEBHOOK_URL

設定が完了したら、コードが更新されると、CI が自動的にトリガーされ、VelaUX 内の対応するアプリケーションが更新されます。

イメージが更新された後、アプリケーションページを再度確認すると、テスト環境のアプリケーションがバージョン v2.0.0 になっていることがわかります。

テスト展開ターゲットで検証した後、アプリケーションワークフローで [続行] をクリックして、最新バージョンのアプリケーションを本番展開ターゲットに展開できます。

デプロイが完了したら、本番環境でアプリケーションを確認すると、本番環境がすでに最新の v2.0.0 バージョンになっていることがわかります。

この時点で、まず Nocalhost を使用して、KubeVela を介してテスト環境でエンドクラウド共同デバッグを実行します。検証後、コードを更新し、GitOps を使用してデプロイメントの更新を完了し、本番環境でアプリケーションの更新を継続することで、アプリケーションの開発から起動までの完全なデプロイメントプロセスが完了します。