12.5. 移行のロールバック
MTC の Web コンソールまたは CLI を使用して移行をロールバックできます。
移行を手動でロールバック することもできます。
12.5.1. MTC の Web コンソールでの移行のロールバック
Migration Toolkit for Containers (MTC) Web コンソールで移行をロールバックできます。
以下のリソースは、直接的なボリューム移行 (DVM) の失敗後もデバッグ用に移行した名前空間に留まります。
- config map (ソースおよび宛先クラスター)
-
Secret
オブジェクト (ソースクラスターと宛先クラスター) -
Rsync
CR (ソースクラスター)
これらのリソースはロールバックには影響しません。これらは手動で削除できます。
後で同じ移行プランを正常に実行すると、失敗した移行のリソースが自動的に削除されます。
移行の失敗時にアプリケーションが停止されている場合、永続ボリュームでのデータの破損を防ぐために移行をロールバックする必要があります。
移行時にアプリケーションが停止しなかった場合には、ロールバックは必要ありません。元のアプリケーションがソースクラスター上で依然として実行されているためです。
手順
- MTC Web コンソールで、Migration plans をクリックします。
- 移行計画の横にある Options メニュー をクリックし、Migration の下にある Rollback を選択します。
Rollback をクリックし、ロールバックが完了するまで待機します。
移行計画の詳細に、Rollback succeeded が表示されます。
ソースクラスターの OpenShift Container Platform Web コンソールでロールバックが正常に行われたことを確認します。
-
Home
Projects をクリックします。 - 移行されたプロジェクトをクリックしてそのステータスを表示します。
- Routes セクションで Location をクリックし、アプリケーションが機能していることを確認します (該当する場合)。
-
Workloads
Pods をクリックし、Pod が移行した namespace で実行されていることを確認します。 -
Storage
Persistent volumes をクリックして、移行した永続ボリュームが正常にプロビジョニングされていることを確認します。
-
Home
12.5.2. コマンドラインインターフェイスでの移行のロールバック
コマンドラインインターフェイスで MigMigration
カスタムリソース (CR) を作成して移行をロールバックできます。
以下のリソースは、直接的なボリューム移行 (DVM) の失敗後もデバッグ用に移行した名前空間に留まります。
- config map (ソースおよび宛先クラスター)
-
Secret
オブジェクト (ソースクラスターと宛先クラスター) -
Rsync
CR (ソースクラスター)
これらのリソースはロールバックには影響しません。これらは手動で削除できます。
後で同じ移行プランを正常に実行すると、失敗した移行のリソースが自動的に削除されます。
移行の失敗時にアプリケーションが停止されている場合、永続ボリュームでのデータの破損を防ぐために移行をロールバックする必要があります。
移行時にアプリケーションが停止しなかった場合には、ロールバックは必要ありません。元のアプリケーションがソースクラスター上で依然として実行されているためです。
手順
以下の例に基づいて
MigMigration
CR オブジェクトを作成します。$ cat << EOF | oc apply -f - apiVersion: migration.openshift.io/v1alpha1 kind: MigMigration metadata: labels: controller-tools.k8s.io: "1.0" name: <migmigration> namespace: openshift-migration spec: ... rollback: true ... migPlanRef: name: <migplan> 1 namespace: openshift-migration EOF
- 1
- 関連付けられた
MigPlan
CR の名前を指定します。
- MTC の Web コンソールで、移行したプロジェクトリソースがターゲットクラスターから削除されていることを確認します。
- 移行したプロジェクトリソースがソースクラスターにあり、アプリケーションが実行中であることを確認します。
12.5.3. 移行の手動ロールバック
stage
Pod を削除して、アプリケーションの停止を解除することで、失敗した移行を手動でロールバックできます。
同じ移行プランを正常に実行すると、失敗した移行のリソースが自動的に削除されます。
以下のリソースは、直接的なボリューム移行 (DVM) の失敗後も移行した名前空間に留まります。
- config map (ソースおよび宛先クラスター)
-
Secret
オブジェクト (ソースクラスターと宛先クラスター) -
Rsync
CR (ソースクラスター)
これらのリソースはロールバックには影響しません。これらは手動で削除できます。
手順
すべてのクラスターの
stage
Pod を削除します。$ oc delete $(oc get pods -l migration.openshift.io/is-stage-pod -n <namespace>) 1
- 1
MigPlan
CR に指定される名前空間。
レプリカを移行前の数にスケーリングして、ソースクラスターでアプリケーションを減らします。
$ oc scale deployment <deployment> --replicas=<premigration_replicas>
Deployment
CR のmigration.openshift.io/preQuiesceReplicas
アノテーションには、レプリカの移行前の数が表示されます。apiVersion: extensions/v1beta1 kind: Deployment metadata: annotations: deployment.kubernetes.io/revision: "1" migration.openshift.io/preQuiesceReplicas: "1"
アプリケーション Pod がソースクラスターで実行されていることを確認します。
$ oc get pod -n <namespace>