従来型のワークロードをモダナイズする

このトピックでは、VM ベースのワークロードを Google Kubernetes Engine（GKE）、GKE クラスタ、または Cloud Run プラットフォームで実行されるコンテナにモダナイズする方法について説明します。VMware または Compute Engine で動作する VM からワークロードを移行できるので、既存のワークロードを柔軟にコンテナ化できます。

モダナイゼーション（移行ともいいます）を行うには、Migrate to Containers のインストールの手順で作成した処理クラスタを使用します。

サポートされているどのワークロードタイプでも、ワークロード移行の基本的なフローは似ていますが、ワークロードタイプごとにいくつかの違いがあります。対象のワークロードタイプのセクションを参照して、手順の概要と詳細を確認してください。

サポートされているワークロード

Linux VM を移行する

移行手順

次の図は、Linux ワークロードの移行手順を示しています。

移行元を追加する。

移行元のソースプラットフォームを表すソースを構成して移行を開始します。前回の移行のソースがすでにあり、移行対象の VM が同じソースに含まれている場合は、そのソースを再利用できます。
移行を作成する。

初期移行計画を使用して移行オブジェクトを作成します。
Linux データを移行する。

データを移行するかどうかを選択します。
移行計画をカスタマイズする。

移行を実行する前に、個別の要件に応じて移行プランを編集します。
移行を実行する。

移行を実行して、コンテナイメージや Dockerfile などのコンテナアーティファクトを抽出します。これらのアーティファクトを使用して、コンテナをテスト環境または本番環境にデプロイします。
移行をモニタリングする。

移行の進行状況をモニタリングし、移行アクティビティログを調査します。
移行を削除する。

移行を削除することで、移行に使用したすべてのリソースが解放されます。

Windows IIS アプリケーションを移行する

移行手順

次の図は、Windows ワークロードの移行手順を示しています。

Migrate to Containers を使用した移行手順は次のとおりです。

移行元を追加する。

移行元のソースプラットフォームを表すソースを構成して、移行を開始します。前回の移行のソースがすでにあり、移行対象の VM が同じソースに含まれている場合は、そのソースを再利用できます。

注: Windows の移行では、移行元としてサポートされるのは Compute Engine のみです。ただし、Migrate to Virtual Machines を使用すると、Windows VM を他の移行元から Compute Engine に移行（またはクローンを作成）し、生成された VM を移行できます。移行後の Windows VM を Compute Engine で動作するように構成する必要はありません。
移行計画を作成する。

初期移行計画を使用して移行オブジェクトを作成します。
移行計画をカスタマイズする。

移行を実行する前に、個別の要件に応じて移行プランを編集します。
移行を実行する。

移行を実行してコンテナアーティファクトを展開します。これには、Dockerfile など、コンテナイメージのビルドに必要なファイルが含まれています。
移行をモニタリングする。

移行の進行状況をモニタリングし、移行アクティビティログを調査します。
Windows コンテナイメージをビルドする。

生成したアーティファクトを使用して、クラスタにデプロイできる Windows コンテナをビルドします。
移行を削除する。

移行を削除することで、移行に使用したすべてのリソースが解放されます。

サポートされている機能

Migrate to Containers: Windows では現在、IIS .Net フレームワークサイトの移行をサポートしています。サイトは、目的別にイメージに分割することも、必要に応じてグループ化することもできます。

移行元 VM で移行可能なサイトをより正確に把握するには、Migration Center のディスカバリークライアント CLI のオフライン評価を実行してみてください。

Tomcat サーバーを移行する

次の図は、Tomcat ワークロードの移行手順を示しています。

Tomcat ワークロードを移行するために Migrate to Containers を使用する場合は、Tomcat の機能とアーキテクチャを利用して、以下のことを行うことができます。

アプリケーションのサブセットを個々のコンテナに自動的に分割する。
Tomcat アプリケーションの既存のキーストア、トラストストア、証明書を移行元の VM から保持する。
JVM アプリケーションに最適なメモリ割り当てを動的に決定する。
移行元の VM から特定のデータボリュームとデータボリュームの要求をコピーする。

前提条件

Linux VM ベースの Apache Tomcat アプリサーバー v8.5 以降。
オフライン評価を実行して、ワークロードの移行への適合性を判定する。
Linux VM の移行用に Cloud クラスタを構成する。

移行手順

Migrate to Containers を使用した移行手順は次のとおりです。

移行元を追加する。

移行元のソースプラットフォームを表すソースを構成して、移行を開始します。前回の移行のソースがすでにあり、移行対象の VM が同じソースに含まれている場合は、そのソースを再利用できます。
移行を作成する。

初期移行計画を使用して移行オブジェクトを作成します。
Tomcat データを移行する。

データを移行するかどうかを選択します。
移行計画をカスタマイズする。

移行を実行する前に、個別の要件に応じて移行プランを編集します。
移行を実行する。

移行を実行してコンテナアーティファクトを展開します。これには、Dockerfile など、コンテナイメージのビルドに必要なファイルが含まれています。
移行をモニタリングする。

移行の進行状況をモニタリングし、移行アクティビティログを調査します。
Tomcat コンテナイメージをビルドする

生成したアーティファクトを使用して、クラスタにデプロイできるコンテナをビルドします。
移行を削除する。

移行を削除することで、移行に使用したすべてのリソースが解放されます。

サポートされていない機能

次の Tomcat 機能はサポートされていません。

クラスタリングまたはセッションのレプリケーション。
Windows ワークロードを使用した Tomcat 移行の Windows サポート。

WebSphere traditional アプリケーションを移行する

移行の概要

従来の IBM WebSphere Application Server（WAS）は、Java ベースのワークロードをホストするためのソフトウェアフレームワークです。Migrate to Containers を使用すると、WAS traditional で実行されているアプリのワークロードをアプリケーションコンテナに変換してモダナイズできます。その後、アプリコンテナを Google Cloud 上の GKE または GKE Enterprise クラスタにデプロイできます。

WebSphere Application Server traditional アプリの移行について

WAS の従来の VM には複数のアプリが含まれている場合があります。Migrate to Containers を使用すると、ソース VM にデプロイされているアプリが検出され、モダナイゼーションの構成が自動的に提案されます。これにより、WAS アプリのコンテナをモダナイズできます。

各アプリは、ユーザーが独自のコンテナイメージ（ibmcom/websphere-traditional、ibmcom/websphere-liberty、または openliberty/open-liberty）に移行する必要があります。その後、移行したアプリを個別にテストしてデプロイできます。複数のアプリを同時にテストしてデプロイする必要はありません。

移行ソースは WAS ND または WAS ベースになります。ターゲットは Liberty または従来の WAS ベースコンテナで、対応する ND クラスタリング機能は Kubernetes に委任されます。

要件

次のシステム要件を確認し、移行環境とデプロイ環境が Migrate to Containers に対応していることを確認します。

WAS traditional アプリを移行する場合の要件

移行を開始する前に、IBM WAS の従来の環境と移行処理クラスタが以下の要件を満たしていることを確認します。

WAS traditional のシステム要件

Migrate to Containers は、次のバージョンの IBM WAS にホストされているアプリの移行をサポートします。

WebSphere Application Server traditional 8.5.5.x
WebSphere Application Server traditional 9.0.5.x

Migrate for Containers は、WAS traditional アプリを含む VM を処理するために、VM から 2 種類の構成を抽出します。

各アプリケーションの構成。
ターゲットプロファイルの構成。プロファイルは、ポート、JVM 設定など、WAS のランタイム環境を定義します。

Migrate to Containers ソフトウェアは、GKE Enterprise または GKE クラスタでのアプリケーションバイナリ用 IBM WebSphere Application Server Migration Toolkit の使用を自動化し、移行レポートと構成スクリプトを検出、評価、生成します。ツールキットの調達、ライセンス取得、使用については、お客様の責任で行っていただきます。

移行を開始するにはまず、ツールキットをアカウントの Google Cloud Storage バケットにアップロードする必要があります。手順については、binaryAppScanner.jar を設定するをご覧ください。

互換性のある VM オペレーティングシステム

Migrate to Containers は、互換性のある VM オペレーティングシステムに記載されている 64 ビット Linux オペレーティングシステムにインストールされている VM からの、WAS traditional アプリの移行をサポートしています。

処理クラスタの要件

Google Kubernetes Engine（GKE）または GKE Enterprise クラスタを使用して、ソース VM からターゲットコンテナへアプリを移行するために必要な変換を実行する Migrate to Containers コンポーネントを実行します。WAS VM 内のアプリの場合:

処理クラスタは次の対象としてデプロイできます。

処理クラスタでは、互換性のある処理クラスタのオペレーティングシステムに記載されている Linux オペレーティングシステムを使用する必要があります。

各タイプの処理クラスタの作成方法については、処理クラスタのタイプを選択するをご覧ください。

移行したアプリをデプロイする場合の要件

アプリの移行後に、アプリケーション環境とターゲットクラスタが下記の要件を満たしていることを確認します。

ターゲットクラスタの要件

Google Kubernetes Engine（GKE）、Google Cloud 上の GKE Enterprise クラスタ、または Google Distributed Cloud Virtual for Bare Metal を使用します。ターゲットクラスタでは、互換性のあるワークロードクラスタのオペレーティングシステムに記載されている Linux オペレーティングシステムを使用する必要があります。

移行の一環として、Migrate to Containers は移行された WAS アプリを表す Dockerfile を作成し、Docker レジストリにアップロードします。こちらで説明されているように、ターゲットクラスタに Docker レジストリへの読み取りアクセス権が付与されていることを確認する必要があります。

サポートされているターゲットコンテナ

WebSphere Application Server traditional
WebSphere Application Server Liberty
Open Liberty

始める前に

移行を開始する前に、まず次のタスクを行う必要があります。

Migrate to Containers をインストールする

Migrate to Containers を処理クラスタにインストールします。処理クラスタとは、Migrate to Containers コンポーネントがインストールされた Google Kubernetes Engine（GKE）または GKE Enterprise クラスタで、VM の移行に使用するものです。すべてのインストール手順については、インストールの概要をご覧ください。

必要に応じて Migrate to Virtual Machines を設定する

Migrate to Containers を使用して VMware から Websphere ワークロードを Google Cloud に移行するには、トランスポートを処理する Migrate to Virtual Machines を設定する必要があります。

詳細については、Migrate to Virtual Machines を設定するをご覧ください。

binaryAppScanner.jar を設定する

注:

binaryAppScanner.jar の最新バージョンをダウンロードしてください。すでにダウンロードしている場合は、ダウンロードページで変更日を見て、最新バージョンであることを確認できます。

また、次のコマンドを使用して、現在のバージョンを確認することもできます。

java -jar binaryAppScanner.jar --version

次に、[Migration Toolkit for Application Binaries] をクリックして、ファイルをダウンロードする際に表示される IBM ライセンスのバージョンと比較します。

Migrate to Containers は、IBM WebSphere Application Server Migration Toolkit for Application Binaries の一部として利用可能な binaryAppScanner.jar の使用を自動化し、ソース VM 内の WAS アプリケーションの構成情報とファイルを抽出します。

移行を行うには、次の操作を行う必要があります。

使用許諾契約に同意し、IBM WebSphere Application Server Migration Toolkit for Application Binaries をダウンロードして、binaryAppScanner.jar ファイルを抽出します。
Dockerfile を作成し、バイナリスキャナにバンドルされているプラグインを準備します。

binaryAppScanner.jar を設定するには:

IBM サポートからインストーラファイル binaryAppScannerInstaller.jar をダウンロードします。ダウンロードの際に、ライセンス契約に同意する必要があります。
次のコマンドを実行して binaryAppScanner.jar ファイルを抽出し、使用許諾契約に同意します。
```
java -jar binaryAppScannerInstaller.jar --acceptLicense --verbose
```
抽出先のターゲットディレクトリを指定します。たとえば /tmp です。インストーラは、ターゲットディレクトリの下に /wamt という名前のディレクトリを作成します。
/wamt ディレクトリに移動します。次に例を示します。
```
cd /tmp/wamt
```

次のコマンドを使用して 2 つの Dockerfile を作成します。

FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-discover:1.3.1
ADD binaryAppScanner.jar /

FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-extract:1.3.1
ADD binaryAppScanner.jar /

Docker イメージをビルドして push します。

gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1 --project PROJECT_ID
gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1 --project PROJECT_ID

プラグインの CRD を編集して、次のように binary-scanner にバンドルします。

$ kubectl edit appxplugins.anthos-migrate.cloud.google.com -n v2k-system websphere-traditional-container

# Set the value of spec.discoveryImage and spec.generateArtifactsImage:

apiVersion: anthos-migrate.cloud.google.com/v1beta2
kind: AppXPlugin
metadata:
  namespace: v2k-system
  name: websphere-traditional-container
  labels:
    anthos-migrate.cloud.google.com/preview-type: public
  annotations:
    anthos-migrate.cloud.google.com/display-name: WebSphere traditional container
spec:
  discoverImage: gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1
  discoverCommand:
  - /ko-app/websphere-traditional
  - discover
  generateArtifactsImage: gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1
  generateArtifactsCommand:
  - /ko-app/websphere-traditional
  - extract
  parameterDefs:
  - name: was-home
    usage: Path of the WebSphere WAS_HOME on the original instance.
    envVar: APPX_WAS_HOME

CRD を保存します。

移行手順

次の図は、WebSphere ワークロードの移行手順を示しています。

Migrate to Containers を使用した移行手順は次のとおりです。

移行元を追加する。

ソースプラットフォームを表す移行元を追加します。
移行を作成する。

初期移行計画を使用して移行オブジェクトを作成します。
WebSphere のデータを移行する。

データを移行するかどうかを選択します。
移行計画をカスタマイズする。

移行を実行する前に、個別の要件に応じて移行計画を編集します。1 回の移行で 1 つの WAS アプリを移行します。
移行を実行する。

移行を実行してコンテナアーティファクトを展開します。これには、Dockerfile など、コンテナイメージのビルドに必要なファイルが含まれています。
移行アーティファクトの生成と確認を行う。

移行を実行してアプリコンテナを生成します。移行プロセスをモニタリングできます。完了したら、デプロイ可能なアプリイメージをビルドする準備としてアーティファクトを確認します。
移行をモニタリングする。

移行の進行状況をモニタリングし、移行アクティビティログを調査します。
アプリコンテナイメージをビルドする。

生成したアーティファクトを使用して、クラスタにデプロイできるコンテナをビルドします。
ターゲットクラスタにアプリコンテナをデプロイする。

イメージをターゲットクラスタにデプロイします。
移行を削除する。

移行を削除することで、移行に使用したすべてのリソースが解放されます。

JBoss サーバーを移行する

次の図は、JBoss ワークロードの移行手順を示しています。

Migrate to Containers を使用して JBoss ワークロードを移行する場合は、JBoss の機能とアーキテクチャを利用して、特定のデータボリュームとデータボリュームのクレームを移行元の VM からコピーできます。

前提条件

JBoss AS アプリサーバー v8.1.0 以降、または JBoss EAP アプリサーバー v7.0、v7.1、v7.2、v7.3、v7.4。

注: JBoss AS と JBoss EAP アプリケーションサーバーの両方が JBoss AS コミュニティコンテナに移行されます。
VM の移行用に Google Cloud クラスタを構成する。

移行手順

Migrate to Containers を使用した移行手順は次のとおりです。

移行元を追加する。

移行元のソースプラットフォームを表すソースを構成して、移行を開始します。前回の移行のソースがすでにあり、移行対象の VM が同じソースに含まれている場合は、そのソースを再利用できます。
移行を作成する。

初期移行計画を使用して移行オブジェクトを作成します。
JBoss データを移行する。

データを移行するかどうかを選択します。
移行計画をカスタマイズする。

移行を実行する前に、個別の要件に応じて移行プランを編集します。
移行を実行する。

移行を実行してコンテナアーティファクトを展開します。これには、Dockerfile など、コンテナイメージのビルドに必要なファイルが含まれています。
移行をモニタリングする。

移行の進行状況をモニタリングし、移行アクティビティログを調査します。
JBoss コンテナイメージをビルドする。

生成したアーティファクトを使用して、クラスタにデプロイできるコンテナをビルドします。
移行を削除する。

移行を削除することで、移行に使用したすべてのリソースが解放されます。

サポートされていない機能

次の JBoss 機能はサポートされていません。

機密データとシークレット - JBOSS_HOME/standalone ディレクトリに保存されている機密データとシークレットは削除されません。このデータはコンテナイメージに含まれます。
JBoss ロガーの構成 - ロガーの構成は、ソースマシンからそのまま取得されます。JBoss コンテナをビルドする前に jbossServer.tar.gz を手動で変更しない限り、移行プロセス中に変更されることはありません。
メモリ割り当て - Java Virtual Machine（JVM）のリソース割り当ては、コミュニティコンテナから取得されます。ソースマシンの JVM リソースには依存しません。
環境変数 - 移行元マシンの環境変数と JVM パラメータはコンテナイメージに移行されません。
オフライン評価 - 移行する JBoss ワークロードの適合性を判断することはできません。

Apache サーバーを移行する

次の図は、Apache ワークロードの移行手順を示しています。

Apache ワークロードを移行するために Migrate to Containers を使用する場合は、Apache の機能とアーキテクチャを利用して、以下のことを行うことができます。

移行元の VM から特定のデータボリュームとデータボリュームの要求をコピーする。

前提条件

Linux VM ベースの Apache 2 ウェブサーバー。
Linux VM の移行用に Google Cloud クラスタを構成する。

移行手順

Migrate to Containers を使用した移行手順は次のとおりです。

移行元を追加する。

移行元のソースプラットフォームを表すソースを構成して、移行を開始します。前回の移行のソースがすでにあり、移行対象の VM が同じソースに含まれている場合は、そのソースを再利用できます。
移行を作成する。

初期移行計画を使用して移行オブジェクトを作成します。
データを移行する。

データを移行するかどうかを選択します。
移行計画をカスタマイズする。

移行を実行する前に、個別の要件に応じて移行プランを編集します。
移行を実行する。

移行を実行してコンテナアーティファクトを展開します。これには、Dockerfile など、コンテナイメージのビルドに必要なファイルが含まれています。
移行をモニタリングする。

移行の進行状況をモニタリングし、移行アクティビティログを調査します。
Apache コンテナイメージをビルドする。

生成したアーティファクトを使用して、クラスタにデプロイできるコンテナをビルドします。
移行を削除する。

移行を削除することで、移行に使用したすべてのリソースが解放されます。

サポートされていない機能

Apache 1 ワークロードはサポートされていません。

次の Apache 機能はサポートされていません。

証明書。
Windows ワークロードを使用した Apache 移行の Windows サポート。

WordPress サイトを移行する

Migrate to Containers を使用して WordPress ワークロードを移行する場合は、WordPress の機能とアーキテクチャを利用して、特定のデータボリュームとデータボリュームのクレームを移行元の VM からコピーできます。

前提条件

WordPress バージョン 4.0 以降（Linux VM ベースの Apache 2 ウェブサーバーで実行）。
Linux VM の移行用に Google Cloud クラスタを構成する。

移行手順

Migrate to Containers を使用した移行手順は次のとおりです。

移行元を追加する。

移行元のソースプラットフォームを表すソースを構成して、移行を開始します。前回の移行のソースがすでにあり、移行対象の VM が同じソースに含まれている場合は、そのソースを再利用できます。
移行を作成する。

初期移行計画を使用して移行オブジェクトを作成します。
移行計画をカスタマイズする。

移行を実行する前に、個別の要件に応じて移行プランを編集します。
WordPress のデータを移行する。

移行を実行する前に、特定の要件に合わせたデータ移行計画を確認して編集します。
移行を実行する。

移行を実行してコンテナアーティファクトを展開します。これには、Dockerfile など、コンテナイメージのビルドに必要なファイルが含まれています。
移行をモニタリングする。

移行の進行状況をモニタリングし、移行アクティビティログを調査します。
WordPress コンテナイメージをビルドする。

生成したアーティファクトを使用して、クラスタにデプロイできるコンテナをビルドします。
移行を削除する。

移行を削除することで、移行に使用したすべてのリソースが解放されます。

サポートされていない機能

Linux VM ベースの Apache 2 ウェブサーバー以外のホストで実行されている WordPress サイトはサポートされていません。

次の WordPress 機能はサポートされていません。

WordPress データベースの移行。

データベースに依存するアプリケーションの移行については、データベースへのアクセスを確保するをご覧ください。
WordPress サーバーにローカルに保存されているデータ（メディアアップロード、プラグイン、テーマなど）の NFS ドライブへのエクスポート。

ローカルに保存されたデータを NFS にエクスポートする方法については、NFS マウントを永続ボリュームとして定義するをご覧ください。
移行したデプロイの水平方向のスケーリング。

WordPress サーバーにローカルに保存されているデータは、移行されたデプロイ Pod にマウントされる Compute Engine の永続ディスクにエクスポートされます。Compute Engine 永続ディスクは複数の Pod に接続できないため、移行されたデプロイの水平方向のスケーリングはできません。
証明書と機密データの Kubernetes Secret オブジェクトへのエクスポート。

次のステップ

移行元の追加方法を学習する。

従来型のワークロードをモダナイズする

サポートされているワークロード

Linux VM を移行する

移行手順

Windows IIS アプリケーションを移行する

移行手順

サポートされている機能

Tomcat サーバーを移行する

前提条件

移行手順

サポートされていない機能

WebSphere traditional アプリケーションを移行する

移行の概要

WebSphere Application Server traditional アプリの移行について

要件

WAS traditional アプリを移行する場合の要件

WAS traditional のシステム要件

互換性のある VM オペレーティング システム

処理クラスタの要件

移行したアプリをデプロイする場合の要件

ターゲット クラスタの要件

サポートされているターゲット コンテナ

始める前に

Migrate to Containers をインストールする

必要に応じて Migrate to Virtual Machines を設定する

binaryAppScanner.jar を設定する

移行手順

JBoss サーバーを移行する

前提条件

移行手順

サポートされていない機能

Apache サーバーを移行する

前提条件

移行手順

サポートされていない機能

WordPress サイトを移行する

前提条件

移行手順

サポートされていない機能

次のステップ

互換性のある VM オペレーティングシステム

ターゲットクラスタの要件

サポートされているターゲットコンテナ