このページでは、既存のコンテナ ワークロードを移行するか、Java ワークロードを Google Kubernetes Engine（GKE）または Cloud Run で実行されるコンテナにモダナイズするためのアーキテクチャ ガイダンスと運用戦略について説明します。
クラウド アーキテクト、アプリケーション デベロッパー、DevOps エンジニアの方は、このページの情報を使用して、コンテナ化パスの評価、Artifact Registry へのイメージの push、Google Cloud Modernization Hub を使用した Java ワークロードの評価とコンテナ化を行います。
このページを読む前に、コンテナ化されたワークロードと仮想化されたワークロードのインベントリを作成し、ターゲット オーケストレーションとスケーリングの要件を理解しておく必要があります。
移行パターン
次の図は、コンテナのモダナイゼーションのパスを示しています。
各パスは、特定のワークロード アーキテクチャに対応しています。
- 既存のコンテナ ワークロード: アプリケーションがすでに Docker イメージまたは Open Container Initiative（OCI）イメージとしてパッケージ化されている場合は、Artifact Registry に push して、GKE または Cloud Run に直接デプロイします。
- Java ワークロード: Java ワークロードが仮想マシンで実行されている場合は、Modernization Hub と Antigravity を使用して、変換パスを評価し、環境固有の依存関係をリファクタリングして、Java ワークロードをコンテナにパッケージ化します。
- サーバーレス関数: アプリケーションが AWS Lambda 関数として実行されている場合は、Antigravity CLI を使用してイベント ハンドラを標準の HTTP マイクロサービスにコンテナ化し、Cloud Run にデプロイします。
Java ワークロードのコンテナ化
Modernization Hub と AI を活用したリファクタリング ツールを使用すると、Java ワークロードを OCI 準拠のコンテナ イメージにモダナイズできます。
- マニフェストのリファクタリングと生成: Antigravity と Antigravity CLI を使用して、環境固有のブロッカーを解決し、標準化された Dockerfile と Kubernetes デプロイ YAML 構成を生成します。
- マネージド ランタイムにデプロイする: コンテナ イメージをビルドして Artifact Registry に push し、コンテナ化された Java ワークロードを GKE または Cloud Run で実行します。
次のステップ
- メインフレームのモダナイゼーションの概要
- コンテナを GKE に移行する
- Amazon EKS を GKE に移行する
- Modernization Hub のドキュメント
- GKE のドキュメント
- Cloud Run のドキュメント