このドキュメントは、IBM WebSphere Application Server（WAS）上で稼働する Java アプリケーションを、Google Kubernetes Engine（GKE）または GKE Enterprise で実行中のコンテナに移行しようとしているアプリケーション オーナーとクラウド アーキテクトを対象としています。オンプレミス、非公開のホスティング環境、または別のクラウド プロバイダにあるソース環境から WAS の従来型アプリケーションをコンテナに移行するプロセスについて順を追って説明します。また、Migrate to Containers を使用して移行を自動化するメリットも紹介します。
Migrate to Containers を使用して WebSphere VM をコンテナに移行する前に、WebSphere について理解しておく必要があります。
このドキュメントでは、WAS アプリケーションのコンテナへの移行を計画する際に考慮すべき重要なポイントについても説明します。これは、Google Cloud への移行に関する複数のパートからなるシリーズの一部です。シリーズの概要については、Google Cloud への移行: 移行パスを選択するをご覧ください。
互換性のあるオペレーティング システム（Linux など）上の互換性のある WAS で実行している WAS の従来型アプリケーションを、Migrate to Containers を使用してサポートされている移行元の環境から GKE または GKE Enterprise 環境に移行する計画がある場合は、このドキュメントをお読みください。移行元の環境としては、次のようなものがあります。
- Compute Engine 環境
- VMware vSphere 環境
- Microsoft Azure VM 環境
- Amazon Elastic Compute Cloud（Amazon EC2）環境
Migrate to Containers は、アプリケーション バイナリ用 IBM Migration Toolkit の使用を自動化し、WAS の従来の仮想マシンにあるすべての WAS の従来型アプリケーションを検出、検査、移行します。その後、WAS の従来型アプリケーションが個々の WebSphere の従来のコンテナに分割されます。
Migrate to Containers を使用して WAS の従来型アプリケーションを移行すると、フットプリントが小さくなり（最小で 1 GB の RAM と 2 GB のイメージサイズ）、ライセンス コストが削減されます（WAS Network Deployment サブスクリプションの場合は最大 70% の割引）。
Migrate to Containers を使用して WAS の従来型アプリケーションを移行することで、コンテナ化された環境のいくつかの要素によるメリットが得られます。前述のとおり、ライセンス費用が削減されます。また、アプリケーション用に WAS Liberty または Open Liberty コンテナを作成することで、陳腐化しない、先進の組み込みクラウド フレームワークへのモダナイゼーションをさらに進めることができます。
WAS Liberty は、ウェブベースとクラウドベースのアプリケーション開発とデプロイを迅速に行うための軽量な本番環境ランタイムです。これはオープンソースの Open Liberty プロジェクト上に構築されます。企業は WAS Liberty と Open Liberty の両方を使用して、クラウドベースの Java マイクロサービスを構築しています。
GKE Enterprise または GKE に移行すると、WAS Network Deployment のマネージャー機能が次のプロダクトにオフロードされます。
次の図は、GKE または GKE Enterprise が従来は WAS Network Deployment が管理していた一元化された機能（高可用性、ワークロード配置、一元化された構成など）を管理する方法を示しています。アプリケーション固有の構成は、Docker イメージのビルド時に管理されます。Docker イメージベースの構成を使用すると、CI / CD プロセスによる再現性と自動化を実現できます。
Migrate to Containers を使用して、WAS の従来型アプリケーションをコンテナに移行することは、ワークロードのモダナイゼーションの過程で利用できる手順の一つです。移行により、アプリケーションをクラウド環境で実行するように変換でき、WAS の従来型アプリケーションのモダナイズに必要な書き換えが不要になります。
理想的な移行の候補は、サポートされている WebSphere Network Deployment や WebSphere Base で実行されているアプリケーションや、完全な書き換えによるモダナイゼーションのコストが（リソースの観点で）かかりすぎるかそもそも不可能である、サポートされている Java のバージョンで実行されているアプリケーションです。最適な移行候補の詳細については、Migrate to Containers を使用した VM のコンテナへの移行をご覧ください。
Google Cloud への移行を設計する
WAS の従来型アプリケーションを移行元の環境から Google Cloud で実行中のコンテナに移行するには、Google Cloud への移行のシリーズで説明されているフレームワークに従います。
次の図は、移行の過程を示しています。
上の図に示すフレームワークは、4 フェーズで構成されています。
- 評価: このフェーズでは、移行元の環境、Google Cloud に移行するアプリケーション、移行に適した WAS の従来型アプリケーションを評価します。
- 計画: このフェーズでは、リソース階層のプロビジョニングやネットワーク アクセスの設定など、Migrate to Containers の基本インフラストラクチャを作成します。
- デプロイ: このフェーズでは、Migrate to Containers を使用して、WAS の従来型アプリケーションを移行元の環境から GKE または GKE Enterprise に移行します。
- 最適化: このフェーズでは、クラウドのテクノロジーと機能を最大限に活用します。
移行元の環境とアプリケーションを評価する
評価フェーズでは、移行元の環境と移行するアプリケーションに関する情報を収集します。これは、移行と移行先の環境の両方で必要なリソースのサイズを適切に設定するのに役立ちます。
評価フェーズでは、次のことを行います。
- ワークロードの包括的なインベントリを作成します。
- プロパティと依存関係に応じてアプリケーションを分類します。
- チームを Google Cloud でトレーニングして教育します。
- Google Cloud 上で実験と概念実証を作成します。
- ターゲット環境の総所有コスト（TCO）を計算します。
- 最初に移行するアプリケーションを選びます。
以降のセクションは、Google Cloud への移行: ワークロードの評価と調査に基づいています。Migrate to Containers でコンテナに移行する WAS の従来型アプリケーションの評価については固有の情報を提供しています。
インベントリを構築する
移行のスコープを設定するには、WAS の従来の環境を把握している必要があります。環境を把握するには、ワークロードとそれらの依存関係に関する情報を収集します。
アプリのインベントリを作成するでは、WAS の従来の環境とそれらの依存関係でワークロードのインベントリを作成する方法について説明します。対象のガイダンスに沿って、インベントリを作成します。この作業が完了したら、以下の説明に進んでください。
ワークロードとそれらの依存関係のインベントリを作成できたため、インベントリを絞り込みます。Migrate to Containers で WAS の従来型アプリケーションを移行するときに、組織で重要となる側面と機能を評価します。
移行のために WAS 環境を評価する前に、Migrate to Containers を使用した VM のコンテナへの移行と Google Cloud への移行: ワークロードの評価と調査における評価作業を行います。その作業が終了したら、ワークロードのインベントリを実施します。
ワークロードのインベントリを完了するには、次の点を考慮してください。
- WAS VM で実行されているオペレーティング システム: WAS VM で実行されているオペレーティング システムとそのライセンスに関する情報を収集し、オペレーティング システムが互換性のあるオペレーティング システムと Kubernetes のバージョン に含まれる 64 ビット Linux オペレーティング システムであることを確認します。
アプリケーションを実行している WAS バージョン: アプリケーションを実行している WAS バージョンに関する情報を収集し、Migrate to Containers との互換性を確認します。Migrate to Containers は、WAS Base 環境と WAS Network Deployment 環境の両方の WAS 従来型アプリケーション（WebSphere Application Server の従来のバージョン 8.5.5.x と WebSphere Application Server の従来のバージョン 9.0.5.x）の移行をサポートしています。
WAS にデプロイされたアプリケーション: 各 WAS にどのアプリケーションがデプロイされているかを評価します。次に、アプリケーション間、およびアプリケーションと外部サービス間の依存関係をマッピングします。次に、アプリケーションの構成ソースに関する情報を収集します。たとえば、以下の対象を使用しています。
- 環境変数
- 非標準の WAS インストール パス
- LDAP ユーザー レジストリ
- セキュリティ ロールのマッピング
- ローダの順序にクラスを適用するための修正
Migrate to Containers の適合性スコア: WAS の従来型アプリケーションが Migrate to Containers による移行に適しているかどうかを評価します。Migrate to Containers には、WAS の従来型アプリケーションで実行して適合性スコアを計算できる適合性評価ツールが用意されています。Migrate to Containers には、WAS の従来型アプリケーションを正常に移行するための一連の最小要件があります。また、WAS の従来型アプリケーションの移行を自動化する場合は、いくつかの制限があります。こうした制限は、移行時にアプリケーションを手動で構成することで対処できます。
認証: WAS には、Simple WebSphere 認証メカニズム（SWAM）、 Lightweight Third Party Authentication（LTPA）、Kerberos などの複数の認証メカニズムが用意されています。WAS セキュリティ ドメインのアクティブ ユーザー レジストリとして構成できるユーザー レジストリの実装は 1 つだけです。Migrate to Containers では、認証の詳細を自動的に移行しません。つまり、認証を構成するには、通常、移行時に手動で構成する必要があります。
データアクセス（JDBC）: J2EE コネクタ アーキテクチャは、WAS をエンタープライズ情報システムに接続する標準のリソース アダプタを定義します。このアダプタは、企業情報システム、アプリケーション サーバー、アプリケーション間の接続を提供します。Migrate to Containers は、JDBC 構成をモダナイズされた WAS コンテナに自動的に移行します。移行されたアプリケーションと既存のデータストア間の接続が有効になっていることを確認します。
メッセージング（JMS）: WAS は、Java Messaging Service（JMS）プログラミング インターフェースによる非同期通信をサポートします。Migrate to Containers では、JMS の構成情報を自動的に移行します。ただし、SSL などの特定の構成には、手動の移行作業が必要となります。
メール: WAS は、JavaMail API によるメールの送信をサポートしています。Migrate to Containers では、JavaMail の構成ファイルを自動的に移行しません。移行フェーズ時にこれらのファイルを手動で構成します。
評価を完了する
環境と WAS の従来のワークロードに関連するインベントリを作成したら、Google Cloud への移行: ワークロードの評価と調査の評価フェーズの残りの作業を行います。この作業が完了したら、以下の説明に進んでください。
基盤の計画と構築
VM の移行時に基盤を計画して構築するのガイダンスに沿って操作してから、WAS 基盤を完成させます。
- Cloud Storage バケットの名前を確認します。
アプリケーション バイナリ用 IBM WebSphere Application Server Migration Toolkit の一部として利用可能な
binaryAppScanner.jarファイルは、次の手順でアップロードします。binaryAppScannerInstaller.jarインストーラ ファイルをダウンロードします。ダウンロードの一部として使用許諾契約に同意する必要があります。次のコマンドを実行して binaryAppScanner.jar ファイルを抽出し、使用許諾契約に同意します。
java -jar binaryAppScannerInstaller.jar --acceptLicense --verbose抽出対象のディレクトリを指定します（例:
/tmp）。インストーラは、ターゲット ディレクトリの中に/wamtという名前のディレクトリを作成します。/wamtディレクトリに移動します。次に例を示します。cd /tmp/wamtbinaryAppScanner.jarファイルを Cloud Storage バケットのルートにアップロードします。gsutil cp binaryAppScanner.jar gs://BUCKET_NAMEここで BUCKET_NAME は Cloud Storage バケット名です。
Migrate to Containers の設定では、コンテナ移行とその依存関係をプロビジョニングして構成する方法について説明しています。そのガイダンスに従って、Migrate to Containers を設定します。
この作業が完了したら、以下の説明に進んでください。
WAS の従来型アプリケーションをコンテナに移行する
移行のデプロイ フェーズの詳細については、VM のコンテナへの移行のガイダンスをご覧ください。
移行計画を作成して確認する
WAS の従来型アプリケーション用に Migrate to Containers の移行計画を作成します。
- 移行元の環境を Migrate to Containers の移行元として構成する: WAS の従来型アプリケーションを移行するには、Migrate to Containers で、VM が実行される移行元の環境に関する情報が必要です。これらの情報は、このドキュメントのインベントリの作成セクションで説明している手順で収集します。移行元の環境の構成について詳しくは、移行元の追加をご覧ください。
移行計画を作成する: 移行元の環境からサポートされている移行先の環境に移行する WAS の従来型アプリケーションを指定するには、移行計画を作成します。たとえば、永続データの保存場所を構成できます。
移行計画の作成とモニタリングの詳細については、移行の作成をご覧ください。
移行を作成するには、コマンドラインを使用する必要があります。Google Cloud コンソールは使用できません。完全なコマンドは次のとおりです。
migctl migration create my-migration --source my-was-src --vm-id PROJECT_ID --intent Image --os-type Linux --app-type websphere-traditionalここで、PROJECT_ID は移行プロジェクトに割り当てられた ID、
Imageはインテント フラグの値です。ワークロードのステートレスな性質により、「イメージ」を使用します。移行計画を確認してカスタマイズする: 移行する各 VM の移行計画を生成したら、要件に沿えるよう、各移行プランを見直し、カスタマイズします。移行計画のカスタマイズの詳細については、移行計画のカスタマイズをご覧ください。
移行アーティファクトとデプロイ記述子を生成する
Migrate to Containers は、アプリケーションのターゲット WAS アーティファクトを生成するために、移行計画で構成した VM で実行されているアプリケーションを抽出します。その後、複数のアーティファクトを作成し、Cloud Storage バケット内に配置します。Migrate to Containers は、ターゲット環境でコンテナ イメージのインスタンスをデプロイするためにカスタマイズして使用できるデプロイ記述子も生成します。
Migrate to Containers は、移行したアプリケーションごとに、Docker コンテキスト、アプリケーション バイナリ、ビルド スクリプト、WAS 構成スクリプトを含むフォルダを作成します。
作成して移行するコンテナ アーティファクトの進行状況をモニタリングできます。移行のモニタリングの詳細については、移行されたワークロードのモニタリングをご覧ください。
生成されたリソースと記述子を確認して検証する
Migrate to Containers でコンテナ アーティファクトとデプロイ記述子を生成したら、これらのアーティファクトと記述子を確認し、要件に合わせて更新します。たとえば、次の側面を考慮します。
- コンテナ イメージ記述子: Migrate to Containers で生成したコンテナ イメージ記述子を調べ、コンテナ ワークロードに対して十分であることを確認します。コンテナ イメージ記述子を更新する必要がある場合は、アプリケーション イメージのビルドをご覧ください。プロパティを追加し、iFixes をインストールできます。
- アプリケーション レベルのロギング: Migrate to Containers は、WAS ログを JSON 形式で自動的に書き込みます。基本のロギングに変更するには、ロギング構成をご覧ください。
コンテナ アーティファクトとデプロイ記述子の確認方法について詳しくは、生成されたデプロイ ファイルの確認をご覧ください。
コンテナ化されたワークロードを GKE または GKE Enterprise にデプロイして検証する
ワークロードのデプロイ記述子の準備ができたら、次の手順を行います。
アプリケーション コンテナ イメージをビルドする: ビルドするアプリケーション アーティファクト フォルダで、移行したワークロードのアプリケーション コンテナ イメージをビルドします。
bash ./build.sh移行した環境に移行したアプリケーションをデプロイする: 移行したアプリケーションをデプロイします。
kubectl apply -f deployment_spec.yaml移行したワークロードをモニタリングする: WAS の従来型アプリケーション コンテナをデプロイした後、移行先の環境でのパフォーマンスに関する情報を収集できます。詳細については、移行したワークロードのモニタリングをご覧ください。
移行したワークロードを統合する: 移行先の環境でデプロイしたワークロードが動作したら、ワークロードのコンテナ アーティファクト生成とデプロイのプロセスを、デプロイ プロセスおよびパイプラインと統合します。現在、自動デプロイ プロセスを実施しておらず、ワークロードを手動でデプロイしている場合は、手動デプロイから自動デプロイに移行することをおすすめします。
Migrate to Containers をアンインストールする
Migrate to Containers でのワークロード移行の完了後は、次のことをおすすめします。
- 移行中に Migrate to Containers で生成されたアーティファクトへのすべての参照が存在することを確認します。
- Migrate to Containers をアンインストールします。
作業が完了したら、このドキュメントの先に進みます。
移行後に環境を最適化する
移行を完了するには、移行後に環境を最適化するのガイドラインをご覧ください。
これらの WAS 固有の最適化は、移行された WAS 従来型アプリケーションに対して実行できます。
- 構成を外部化する: 従来の WAS コンテナを構築すると、環境間で構成の違いが生じる場合があります。環境ごとのコンテナの再ビルドを避けるには、WAS 構成をプロパティに外部化し、ConfigMap を使用してコンテナの起動時にこれらのプロパティを設定することをおすすめします。
- 機密データの保護: パスワードやその他の機密データは Kubernetes Secret に保存する必要があります。Kubernetes Secret を使用して、コンテナの起動時に構成のプレースホルダを置き換えます。
次のステップ
- コンテナの構築と操作のベスト プラクティスを確認する。
- 費用を最適化した Kubernetes アプリケーションを GKE で実行するためのベスト プラクティスを確認する。
- Migrate to Containers を使用した VM のコンテナへの移行
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。