Kubernetes は事実上の標準の Docker コンテナオーケストレーターとなっています。広く普及しており、優れたアプリケーション デプロイ ソリューションであるため、すべての主要クラウドプロバイダーに、Kubernetes クラスターのデプロイソリューションが用意されています。
Kubernetes の詳細については「
Kubernetesとは何か？」を参照してください。
Kubernetes は、アプリケーションの望ましい状態を記述したメタデータファイルに基づきます。状態は
YAML ファイルで宣言します。
GeneXus では、アプリケーションのニーズに基づいて YAML ファイルが作成されます。理解しておくべきことを以下に示します。
下図は実現したい内容を示しています。
ロードバランサーが、トラフィックの負荷をアプリケーションのノードにリダイレクトしていることが分かります。これらのノードは完全に同じであり、アプリケーションの同じ Docker イメージを n 回、初期化したものです。GeneXus では既定で 2 つのインスタンスが生成されますが、この数値はデプロイのプロパティで変更できます。
また、必要な場合は、
Redis サーバーを使用して別のコンテナをデプロイすることもできます。この場合、アプリケーションがこの Redis サーバーにセッションを保存できるため、サーバーアフィニティがない場合や、いずれかのノード (またはポッド) が停止した場合に、クライアントがセッションを失うことなく新しいノードに接続できます。
ここではデータベースのコンテナはデプロイされていません。データベースは各自で管理する必要があります。すべてのクラウドプロバイダーに、拡張可能な優れたリレーショナル データベース ソリューションが用意されています。
GeneXus のほかのデプロイと同様に、出発点は
Deployment Unit オブジェクトです。Kubernetes は Docker コンテナに基づくため、最初にアプリケーションの Docker イメージを作成する必要があります。
アプリケーション デプロイ ツールではデプロイターゲットとして Docker イメージを選択します。
デプロイターゲットの Docker イメージには、Kubernetes に固有のプロパティがいくつかあります。
- [ Generate Kubernetes metadata ] : Kubernetes クラスターに必要なメタデータが含まれる YAML ファイルを生成するようにデプロイエンジンに指示します。
- [ Kubernetes Namespace ] : 既定の名前空間を使用せずに、アプリケーションのクラスター内に独自の名前空間を作成することをお勧めします。
- [ Pod labels ] : ポッドにはラベルを追加するのが一般的です。たとえばカナリアデプロイの場合が該当します。
- [ Initial replicas ] : Kubernetes では、アプリケーションの多数のインスタンスを簡単にスピンアップできます。このプロパティは、常時実行するアプリケーションのインスタンス数をクラスターに指定します。高可用性を実現するには、2 つ以上のインスタンスが必要です。
- [ Exposed service type ] : クラスターをクラウドプロバイダーにホストする場合と、Docker クライアントまたは Minikube を使用してローカルの開発用マシンにホストする場合とでは、いくつかの相違点があります。クラウドプロバイダーにはロードバランサーが用意されているため、本番環境へのデプロイを検討する際にはこの値を設定する必要があります。これに対して、ローカルクラスターでソリューションをテストする場合は「NodePort」が必要です (詳細については後述)。
- [ Enable Redis session management ] : クラウド ネイティブ アプリケーションでは OutProc モードでセッション管理を使用する必要があります。このプロパティを指定すると、クラスターに Redis コンテナもデプロイされ、アプリケーションに分散型セッション管理システムを使用できます。
Blob ファイル、
画像、
オーディオを使用する場合は、
ストレージ プロバイダー ソリューションに格納する必要があります。クラスター内のノードはいつ停止するか分からないため、コンテナのローカル ファイル システムへの依存は避ける必要があります。詳細については、「
ロードバランシングに関する検討事項」を参照してください。
アプリケーションを Kubernetes クラスターにデプロイするには、次の手順に従います:
1.アプリケーションをビルドして実行し、ローカル環境でテストします。
2.デプロイユニット、つまりアプリケーションのメインのプログラムやサービスを作成します。
3.デプロイのプロパティで [ Generate Kubernetes metadata ] と [ Enable Redis session management ] が True に設定されていることを確認します。
4.このデプロイは最初にローカルでテストするため、 [ Exposed service type ] プロパティには「NodePort」を選択します。
5. [ Docker image name ] プロパティ
(1) は、
Docker Hub などの Docker レジストリにプッシュできるものにします。
6. [ デプロイ ] をクリックして少し待ちます。
ここで [ デプロイ ] ボタンをクリック後に行われる処理について説明します。最初の 2 つのステップは通常のデプロイアプリケーションで、特別なことはありません。デプロイエンジンにより、デプロイするオブジェクトを指定する
gxdproj ファイルが生成されてから、オブジェクトに関連するファイルから
war ファイルか
zip ファイルが作成されます。
その後、Dockerfile が作成され、これを使用して Docker イメージがビルドされます。また、アプリケーション、Redis サービス、名前空間作成のための Kubernetes メタデータファイルもそれぞれ 1 つずつ生成されます。これらのファイルを 1 つにまとめず 3 つに分けるのはなぜしょうか。それは、アプリケーションのメタデータファイルは将来的に拡張され、ファイルの複数のバージョンを適用することになるからです。Redis ファイルと名前空間ファイルの適用は 1 回だけです。
Generating Kubernetes metadata file
Kubernetes metadata file succesfully generated at 'C:\Models\TestDeploy\TestDeploy\NetCoreSQLServer003\Deploy\DOCKER\context\K8s-DeploymentUnit1-App.yaml'
Make sure you push the sjuarez2020/test:2.0 Docker image to a reachable Docker registry (eg. 'docker push sjuarez2020/test:2.0')
7.イメージをタグ付けし、Docker レジストリにプッシュ (
2) します。 [ Docker image name ] プロパティの設定が適切であれば (
1)、表示されたコマンドを実行するだけです。この例では次のとおりです:
docker push sjuarez2020/test:2.0
8. これでクラスターをスピンアップできます。コマンドウィンドウを開き、メタデータファイルが生成された場所 ( [ 出力 ] ウィンドウに表示) まで移動し、次のコマンドを実行します:
>kubectl apply -f K8s-test1app-Namespace.yaml
namespace/test1app created
>kubectl apply -f K8s-test1app-Redis.yaml
service/gx-redis-svc created
deployment.apps/gx-redis-app created
>kubectl apply -f K8s-DeploymentUnit1-App.yaml
service/deploymentunit1-svc created
deployment.apps/deploymentunit1-app created
DeploymentUnit1 は、選択するデプロイユニットの名前なので、実際は異なります。「test1app」は、デプロイユニットのオプションで設定した Kubernetes の名前空間です (上の図を参照)。
Kubernetes ダッシュボード (
3) をインストールしておけば、デプロイが成功したかどうか、注意が必要なエラーが発生したかどうかを確認できて便利です。
9.アプリケーションをテストします。アプリケーションのオブジェクトにアクセスするには、公開先を確認する必要があります (カスタム名前空間を追加した場合は
-n フラグの追加が必要):
>kubectl get svc -n test1app
これでクラスター内の全サービスが表示されます。指定したデプロイユニット名に「app-service」が付加されたものに注目します。
この例では、サービスがローカルホストのポート 31754 に公開されています。このため、ブラウザーで「htttp://localhost:31754」と入力すると、サービスにアクセスできます。
アクセスする特定のオブジェクトも追加する必要があることに注意してください。
.NET の場合は、オブジェクト名に
.aspx 拡張子を付加します。
Java の場合は「servlet/<パッケージ名>」を付加します。
http://localhost:31754/sessiontester.aspx
http://localhost:30118/servlet/com.k8stest.sessiontester
この機能は
GeneXus 16 Upgrade 11 以降で利用できます。