第3章 OpenShift Container Platform 4.2 以降からの移行
3.1. 移行ツールおよび前提条件
アプリケーションワークロードを、Cluster Application Migration (CAM) ツールを使用して OpenShift Container Platform 4.2 以降から OpenShift Container Platform 4.4 に移行できます。CAM ツールを使用すると、移行を制御し、アプリケーションのダウンタイムを最小限に抑えることができます。
ソースおよびターゲットクラスターが正しく設定されている場合、同じバージョンの OpenShift Container Platform クラスター間で移行できます (4.2 から 4.2 または 4.3 から 4.3 への移行など)。
Kubernetes カスタムリソースをベースとする CAM ツールの Web コンソールおよび API により、namespace の粒度でステートフルおよびステートレスのアプリケーションワークロードを移行できます。
CAM ツールは、ソースクラスターからターゲットクラスターにデータを移行するためにファイルシステムおよびスナップショットによるデータのコピー方法をサポートします。ご使用の環境に適した方法で、ストレージプロバイダーでサポートされる方法を選択できます。
移行フックを使用して、移行中の特定の時点で Ansible Playbook を実行できます。フックは移行計画の作成時に追加されます。
3.1.1. 移行の前提条件
- ソースクラスターを最新の z-stream リリースにアップグレードすること。
-
すべてのクラスターで
cluster-admin権限がある。 - ソースおよびターゲットクラスターには、レプリケーションリポジトリーへの無制限のネットワークアクセスがなければなりません。
- Migration コントローラーがインストールされているクラスターには、他のクラスターへの無制限のアクセスが必要です。
アプリケーションが
openshiftnamespace のイメージを使用する場合、イメージの必要なバージョンがターゲットクラスターに存在する必要があります。必要なイメージがない場合は、アプリケーションと互換性のある利用可能なバージョンを使用するように
imagestreamtags参照を更新する必要があります。imagestreamtagを更新できない場合、同等のイメージをアプリケーション namespace に手動でアップロードし、それらを参照するようにアプリケーションを更新できます。
以下の imagestreamtags は OpenShift Container Platform 4.2 から 削除 されています。
-
dotnet:1.0、dotnet:1.1、dotnet:2.0 -
dotnet-runtime:2.0 -
mariadb:10.1 -
mongodb:2.4、mongodb:2.6 -
mysql:5.5、mysql:5.6 -
nginx:1.8 -
nodejs:0.10、nodejs:4、nodejs:6 -
perl:5.16、perl:5.20 -
php:5.5、php:5.6 -
postgresql:9.2、postgresql:9.4、postgresql:9.5 -
python:3.3、python:3.4 -
ruby:2.0,ruby:2.2
以下の imagestreamtags は OpenShift Container Platform 4.4 から 削除 されています。
-
dotnet: 2.2 -
dotnet-runtime: 2.2 -
nginx: 1.12 -
nodejs: 8, 8-RHOAR, 10-SCL -
perl:5.24 -
php: 7.0, 7.1 -
redis: 3.2
3.1.2. Cluster Application Migration ツールについて
Cluster Application Migration (CAM) ツールを使用すると、CAM Web コンソールまたは Kubernetes API を使用して Kubernetes リソース、永続ボリュームデータ、および内部コンテナーイメージを OpenShift Container Platform ソースクラスターから OpenShift Container Platform 4.4 ターゲットクラスターに移行できます。
CAM Web コンソールを使用してアプリケーションを移行するには、以下の手順が必要です。
Cluster Application Migration Operator をすべてのクラスターにインストールします。
インターネットアクセスが制限されているか、またはインターネットアクセスのない環境で Cluster Application Migration Operator をインストールできます。ソースおよびターゲットクラスターは、相互に対するネットワークアクセスおよびミラーレジストリーへのネットワークアクセスがなければなりません。
CAM ツールがデータ移行に使用する中間オブジェクトストレージであるレプリケーションリポジトリーを設定します。
ソースおよびターゲットクラスターには、移行時にレプリケーションリポジトリーへのネットワークアクセスがなければなりません。制限された環境では、内部でホストされる S3 ストレージリポジトリーを使用できます。プロキシーサーバーを使用する場合は、レプリケーションリポジトリーがホワイトリスト化されていることを確認する必要があります。
- ソースクラスターを CAM Web コンソールに追加します。
- レプリケーションリポジトリーを CAM Web コンソールに追加します。
以下のデータ移行オプションのいずれかを使用して、移行計画を作成します。
Copy: CAM ツールは、データをソースクラスターからレプリケーションリポジトリーにコピーし、レプリケーションリポジトリーからターゲットクラスターにコピーします。
Move: CAM ツールはリモートボリューム (NFS など) をソースクラスターからアンマウントし、リモートボリュームをポイントするターゲットクラスターで PV リソースを作成し、その後にリモートボリュームをターゲットクラスターにマウントします。ターゲットクラスターで実行されているアプリケーションは、ソースクラスターが使用していたものと同じリモートボリュームを使用します。リモートボリュームは、ソースクラスターおよびターゲットクラスターからアクセスできる必要があります。
注記レプリケーションリポジトリーはこの図には表示されていませんが、実際の移行には必要になります。
以下のオプションのいずれかを使用して、移行計画を実行します。
Stage (オプション) は、アプリケーションを停止せずにデータをターゲットクラスターにコピーします。
ステージングは、移行前にほとんどのデータがターゲットにコピーされるように複数回実行することができます。これにより、実際の移行時間やアプリケーションのダウンタイムが最小限に抑えられます。
- Migrate は、ソースクラスターでアプリケーションを停止し、ターゲットクラスターでそのリソースを再作成します。オプションで、アプリケーションを停止せずにワークロードを移行できます。
3.1.3. データのコピー方法
CAM ツールは、ソースクラスターからターゲットクラスターにデータを移行するためにファイルシステムおよびスナップショットによるデータのコピー方法をサポートします。ご使用の環境に適した方法で、ストレージプロバイダーでサポートされる方法を選択できます。
3.1.3.1. ファイルシステムのコピー方法
CAM ツールは、データファイルをソースクラスターからレプリケーションリポジトリーにコピーし、そこからターゲットクラスターにコピーします。
| 利点 | 制限 |
|---|---|
|
|
3.1.3.2. スナップショットのコピー方法
CAM ツールは、ソースクラスターのデータのスナップショットを、レプリケーションリポジトリーとして設定されたクラウドプロバイダーのオブジェクトストレージにコピーします。データはターゲットクラスターで復元されます。
AWS、Google Cloud Provider、および Microsoft Azure は、スナップショットのコピー方法をサポートします。
| 利点 | 制限 |
|---|---|
|
|
3.1.4. 移行フックについて
移行フックを使用して、移行中の特定の時点で Ansible Playbook を実行できます。フックは移行計画の作成時に追加されます。
Ansible Playbook を使用する必要がない場合は、カスタムコンテナーイメージを作成し、これを移行計画に追加することができます。
移行フックは、アプリケーションの休止状態のカスタマイズ、サポート外のデータタイプの手動の移行、および移行後のアプリケーションの更新などのタスクを実行します。
単一の移行フックは、以下の移行手順のいずれかでソースまたはターゲットクラスターで実行されます。
- PreBackup: バックアップタスクがソースクラスターで開始される前
- PostBackup: バックアップタスクがソースクラスターで完了した後
- PreRestore: 復元タスクがターゲットクラスターで開始される前
PostRestore: 復元タスクがターゲットクラスターで完了した後
1 つのフックをそれぞれの移行ステップに割り当て、単一の移行計画について最大 4 つのフックを割り当てることができます。
デフォルトの hook-runner イメージは registry.redhat.io/rhcam-1-2/openshift-migration-hook-runner-rhel7 です。このイメージは Ansible Runner をベースとしており、Ansible Kubernetes リソース用の python-openshift および更新された oc バイナリーが含まれます。追加の Ansible モジュールまたはツールで独自のフックイメージを作成することもできます。
Ansible Playbook はフックコンテナーに ConfigMap としてマウントされます。フックコンテナーは、指定されたサービスアカウントおよび namespace を使用してクラスターでジョブとして実行されます。ジョブは、初期の Pod がエビクトされるか、または強制終了される場合でも、デフォルトの backoffLimit (6) または正常に完了した状態に達するまで実行されます。
