MTC (Migration Toolkit for Containers)

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. Filter by keyword フィールドを使用して、 Migration Toolkit for Containers Operator を見つけます。

3. Migration Toolkit for Containers Operator を選択し、Install をクリックします。

   注記

   サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

4. Install をクリックします。

   Installed Operators ページで、Migration Toolkit for Containers Operator は、Succeeded のステータスで openshift-migration プロジェクトに表示されます。

5. Migration Toolkit for Containers Operator をクリックします。
6. Provided APIs の下で Migration Controller タイルを見つけ、Create Instance をクリックします。
7. Create をクリックします。
8. Workloads → Pods をクリックし、MTC Pod が実行されていることを確認します。

手順

1. Red Hat カスタマーポータルの認証情報を使用して registry.redhat.io にログインします。

   $ sudo podman login registry.redhat.io

2. operator.yml ファイルをダウンロードします。

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./

3. controller-3.yml ファイルをダウンロードします。

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./

4. OpenShift Container Platform 3 クラスターにログインします。

5. クラスターが registry.redhat.io で認証できることを確認します。

   $ oc run test --image registry.redhat.io/ubi8 --command sleep infinity

6. Migration Toolkit for Containers Operator オブジェクトを作成します。

   $ oc create -f operator.yml

   出力例

   namespace/openshift-migration created
   rolebinding.rbac.authorization.k8s.io/system:deployers created
   serviceaccount/migration-operator created
   customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
   role.rbac.authorization.k8s.io/migration-operator created
   rolebinding.rbac.authorization.k8s.io/migration-operator created
   clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
   deployment.apps/migration-operator created
   Error from server (AlreadyExists): error when creating "./operator.yml":
   rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
   Error from server (AlreadyExists): error when creating "./operator.yml":
   rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

   1

   Error from server (AlreadyExists) メッセージは無視できます。これらは、以降のリソースで提供される OpenShift Container Platform 3 の以前のバージョン用にリソースを作成する Migration Toolkit for Containers Operator によって生じます。

7. MigrationController オブジェクトを作成します。

   $ oc create -f controller-3.yml

8. Velero および Restic Pod が実行されていることを確認します。

   $ oc get pods -n openshift-migration

手順

1. ネットワークアクセスが無制限のワークステーションで、ターゲットミラーレジストリーを使用して認証を行います。

   $ podman login <registry_host_name>

   また、ビルド時にベースイメージをプルできるように、registry.redhat.io で認証します。

   $ podman login registry.redhat.io

2. Quay.io から redhat-operators カタログをベースにカタログイメージをビルドし、そのイメージにタグを付け、ミラーレジストリーにプッシュします。

   $ oc adm catalog build \
       --appregistry-org redhat-operators \1
       --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
       --filter-by-os="linux/amd64" \3
       --to=<registry_host_name>:<port>/olm/redhat-operators:v1 \4
       [-a ${REG_CREDS}] \5
       [--insecure] \6
       [--auth-token "${AUTH_TOKEN}"] 7

   1

   App Registry インスタンスからのプルに使用する組織 (namespace)。

   2

   ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用して、--from を ose-operator-registry ベースイメージに設定します。

   3

   --filter-by-os を、ターゲットの OpenShift Container Platform クラスターと一致する必要のある、ベースイメージに使用するオペレーティングシステムおよびアーキテクチャーに設定します。使用できる値は、linux/amd64、linux/ppc64le、および linux/s390x です。

   4

   カタログイメージに名前を付け、v1 などのタグを追加します。

   5

   オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。

   6

   オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。

   7

   オプション: 公開されていない他のアプリケーションレジストリーカタログが使用されている場合、Quay 認証トークンを指定します。

   出力例

   INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
   ...
   Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1

   無効なマニフェストが Red Hat のカタログに誤って導入されることあります。これが実際に生じる場合には、以下のようなエラーが表示される可能性があります。

   エラーのある出力の例

   ...
   INFO[0014] directory                                     dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package
   W1114 19:42:37.876180   34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found
   Uploading ... 244.9kB/s

   通常、これらのエラーは致命的なエラーではなく、該当する Operator パッケージにインストールする予定の Operator やその依存関係が含まれない場合、それらを無視することができます。

手順

1. oc adm catalog mirror コマンドは、カスタム Operator カタログイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。以下のいずれかを選択できます。

   • コマンドのデフォルト動作で、マニフェストの生成後にすべてのイメージコンテンツをミラーレジストリーに自動的にミラーリングできるようにします。または、
   • --manifests-only フラグを追加して、ミラーリングに必要なマニフェストのみを生成しますが、これにより、イメージコンテンツがレジストリーに自動的にミラーリングされる訳ではありません。これは、ミラーリングする内容を確認するのに役立ちます。また、コンテンツのサブセットのみが必要な場合に、マッピングの一覧に変更を加えることができます。次に、そのファイルを oc image mirror コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。

   ネットワークアクセスが無制限のワークステーションで、以下のコマンドを実行します。

   $ oc adm catalog mirror \
       <registry_host_name>:<port>/olm/redhat-operators:v1 \1
       <registry_host_name>:<port> \
       [-a ${REG_CREDS}] \2
       [--insecure] \3
       --filter-by-os='.*' \4
       [--manifests-only] 5

   1

   Operator カタログイメージを指定します。

   2

   オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。

   3

   オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。

   4

   このフラグは、現時点で複数のアーキテクチャーのサポートに関して問題が存在するために必要になります。

   5

   オプション: ミラーリングに必要なマニフェストのみを生成し、実際にはイメージコンテンツをレジストリーにミラーリングしません。

   警告

   --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。詳細は、BZ#1890951 を参照してください。

   出力例

   using database path mapping: /:/tmp/190214037
   wrote database to /tmp/190214037
   using database at: /tmp/190214037/bundles.db 1
   ...

   1

   コマンドで生成される一時的なデータベース。

   コマンドの実行後に、<image_name>-manifests/ ディレクトリーが現在のディレクトリーに作成され、以下のファイルが生成されます。

   • これにより、imageContentSourcePolicy.yaml ファイルは ImageContentSourcePolicy オブジェクトを定義します。このオブジェクトは、ノードを Operator マニフェストおよびミラーリングされたレジストリーに保存されるイメージ参照間で変換できるように設定します。
   • mapping.txt ファイルには、すべてのソースイメージが含まれ、これはそれらのイメージをターゲットレジストリー内のどこにマップするかを示します。このファイルは oc image mirror コマンドと互換性があり、ミラーリング設定をさらにカスタマイズするために使用できます。

2. 直前の手順で --manifests-only フラグを使用して、コンテンツのサブセットのみをミラーリングする場合は、以下を実行します。

   1. mapping.txt ファイルのイメージの一覧を仕様に変更します。ミラーリングするイメージのサブセットの名前とバージョンが不明な場合は、以下の手順で確認します。

      1. oc adm catalog mirror コマンドで生成された一時的なデータベースに対して sqlite3 ツールを実行し、一般的な検索クエリーに一致するイメージの一覧を取得します。出力は、後に mapping.txt ファイルを編集する方法を通知するのに役立ちます。

         たとえば、clusterlogging.4.3 の文字列のようなイメージの一覧を取得するには、以下を実行します。

         $ echo "select * from related_image \
             where operatorbundle_name like 'clusterlogging.4.3%';" \
             | sqlite3 -line /tmp/190214037/bundles.db 1

         1

         oc adm catalog mirror コマンドの直前の出力を参照し、データベースファイルのパスを見つけます。

         出力例

         image = registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61
         operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
         
         image = registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506
         operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
         ...

      2. 直前の手順で取得した結果を使用して mapping.txt ファイルを編集し、ミラーリングする必要のあるイメージのサブセットのみを追加します。

         たとえば、前述の出力例の image 値を使用して、mapping.txt ファイルに以下の一致する行が存在することを確認できます。

         mapping.txt の一致するイメージマッピング。

         registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/openshift4-ose-logging-kibana5:a767c8f0
         registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2b

         この例では、これらのイメージのみをミラーリングする場合に、mapping.txt ファイルの他のすべてのエントリーを削除し、上記の 2 行のみを残します。

   2. ネットワークアクセスが無制限のワークステーション上で、変更した mapping.txt ファイルを使用し、 oc image mirror コマンドを使用してイメージをレジストリーにミラーリングします。

      $ oc image mirror \
          [-a ${REG_CREDS}] \
          --filter-by-os='.*' \
          -f ./redhat-operators-manifests/mapping.txt

      警告

      --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。

3. ImageContentSourcePolicy オブジェクトを適用します。

   $ oc apply -f ./redhat-operators-manifests/imageContentSourcePolicy.yaml

4. カタログイメージを参照する CatalogSource オブジェクトを作成します。

   1. 仕様を以下のように変更し、これを catalogsource.yaml ファイルとして保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry_host_name>:<port>/olm/redhat-operators:v1 1
        displayName: My Operator Catalog
        publisher: grpc

      1

      Operator カタログイメージを指定します。

   2. このファイルを使用して CatalogSource オブジェクトを作成します。

      $ oc create -f catalogsource.yaml

5. 以下のリソースが正常に作成されていることを確認します。

   1. Pod を確認します。

      $ oc get pods -n openshift-marketplace

      出力例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

   2. カタログソースを確認します。

      $ oc get catalogsource -n openshift-marketplace

      出力例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

   3. パッケージマニフェストを確認します。

      $ oc get packagemanifest -n openshift-marketplace

      出力例

      NAME    CATALOG              AGE
      etcd    My Operator Catalog  34s

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. Filter by keyword フィールドを使用して、 Migration Toolkit for Containers Operator を見つけます。

3. Migration Toolkit for Containers Operator を選択し、Install をクリックします。

   注記

   サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

4. Install をクリックします。

   Installed Operators ページで、Migration Toolkit for Containers Operator は、Succeeded のステータスで openshift-migration プロジェクトに表示されます。

5. Migration Toolkit for Containers Operator をクリックします。
6. Provided APIs の下で Migration Controller タイルを見つけ、Create Instance をクリックします。
7. Create をクリックします。
8. Workloads → Pods をクリックし、MTC Pod が実行されていることを確認します。

手順

1. ネットワークアクセスが無制限のワークステーションで、Red Hat カスタマーポータルの認証情報を使用して registry.redhat.io にログインします。

   $ sudo podman login registry.redhat.io

2. operator.yml ファイルをダウンロードします。

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./

3. controller-3.yml ファイルをダウンロードします。

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./

4. OpenShift Container Platform 4 クラスターで oc adm catalog mirror の実行時に作成された mapping.txt ファイルから Operator イメージの値を取得します。

   $ grep openshift-migration-rhel7-operator ./mapping.txt | grep rhmtc

   出力には、registry.redhat.io イメージとミラーレジストリーイメージ間のマッピングが表示されます。

   出力例

   registry.redhat.io/rhmtc/openshift-migration-rhel7-operator@sha256:468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a=<registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator

5. Operator 設定ファイルの image および REGISTRY の値を更新します。

   containers:
     - name: ansible
       image: <registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 1
   ...
     - name: operator
       image: <registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 2
   ...
       env:
       - name: REGISTRY
         value: <registry.apps.example.com> 3

   1

   ミラーレジストリー、および mapping.txt ファイルで Operator イメージの sha256 の値を指定します。

   2

   ミラーレジストリー、および mapping.txt ファイルで Operator イメージの sha256 の値を指定します。

   3

   ミラーレジストリーを指定します。

6. OpenShift Container Platform 3 クラスターにログインします。

7. Migration Toolkit for Containers Operator オブジェクトを作成します。

   $ oc create -f operator.yml

   出力例

   namespace/openshift-migration created
   rolebinding.rbac.authorization.k8s.io/system:deployers created
   serviceaccount/migration-operator created
   customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
   role.rbac.authorization.k8s.io/migration-operator created
   rolebinding.rbac.authorization.k8s.io/migration-operator created
   clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
   deployment.apps/migration-operator created
   Error from server (AlreadyExists): error when creating "./operator.yml":
   rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
   Error from server (AlreadyExists): error when creating "./operator.yml":
   rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

   1

   Error from server (AlreadyExists) メッセージは無視できます。これらは、以降のリソースで提供される OpenShift Container Platform 3 の以前のバージョン用にリソースを作成する Migration Toolkit for Containers Operator によって生じます。

8. MigrationController オブジェクトを作成します。

   $ oc create -f controller-3.yml

9. Velero および Restic Pod が実行されていることを確認します。

   $ oc get pods -n openshift-migration

手順

1. OpenShift Container Platform コンソールで、Operators → Installed Operators に移動します。

   更新が保留中の Operator は Upgrade available のステータスを表示します。

2. Migration Toolkit for Containers Operator をクリックします。
3. Subscription タブをクリックします。アップグレードの承認を必要とするアップグレードは、Upgrade Status の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
4. 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
5. アップグレードに利用可能なリソースとして一覧表示されているリソースを確認し、Approve をクリックします。
6. Operators → Installed Operators ページに戻り、アップグレードの進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。
7. Workloads → Pods をクリックし、MTC Pod が実行されていることを確認します。

手順

1. Red Hat カスタマーポータルの認証情報を使用して registry.redhat.io にログインします。

   $ sudo podman login registry.redhat.io

2. 最新の operator.yml ファイルをダウンロードします。

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./ 1

   1

   必要な場合は z-stream リリースを指定できます。

3. Migration Toolkit for Containers Operator を置き換えます。

   $ oc replace --force -f operator.yml

4. 変更を適用します。

   • MTC 1.1.2 以前のバージョンの場合は、Restic Pod を削除します。

     $ oc delete pod <restic_pod>

   • MTC 1.2 以降のバージョンの場合:

     1. migration-operator デプロイメントを 0 にスケーリングし、デプロイメントを停止します。

        $ oc scale -n openshift-migration --replicas=0 deployment/migration-operator

     2. migration-operator デプロイメントを 1 にスケーリングし、デプロイメントを開始して変更を適用します。

        $ oc scale -n openshift-migration --replicas=1 deployment/migration-operator

5. migration-operator がアップグレードされていることを確認します。

   $ oc -o yaml -n openshift-migration get deployment/migration-operator | grep image: | awk -F ":" '{ print $NF }'

6. 最新の controller-3.yml ファイルをダウンロードします。

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./

7. migration-controller オブジェクトを作成します。

   $ oc create -f controller-3.yml

8. OpenShift Container Platform バージョンが 3.10 以前である場合、migration-controller サービスアカウントの SCC (Security Context Constraints) を anyuid に設定して、イメージの直接移行およびボリュームの直接移行を有効にします。

   $ oc adm policy add-scc-to-user anyuid -z migration-controller -n openshift-migration

9. MTC Pod が実行されていることを確認します。

   $ oc get pods -n openshift-migration

10. OpenShift Container Platform 3 クラスターを MTC Web コンソールに追加している場合、アップグレードプロセスにより openshift-migration namespace が削除され、復元されるため、Web コンソースでサービスアカウントトークンを更新する必要があります。

    1. サービスアカウントトークンを取得します。

       $ oc sa get-token migration-controller -n openshift-migration

    2. MTC の Web コンソールで、Clusters をクリックします。
    3. クラスターの横にある Options メニュー をクリックし、Edit を選択します。
    4. Service account token フィールドに新規サービスアカウントトークンを入力します。
    5. Update cluster をクリックしてから、Close をクリックします。

手順

1. MigrationController Pod が実行されるクラスターにログインします。

2. MigPlan CR マニフェストを取得します。

   $ oc get migplan <migplan> -o yaml -n openshift-migration

3. 以下のパラメーター値を更新し、ファイルを migplan.yaml として保存します。

   ...
   spec:
     indirectImageMigration: true
     indirectVolumeMigration: true

4. MigPlan CR マニフェストを置き換えて変更を適用します。

   $ oc replace -f migplan.yaml -n openshift-migration

5. 更新された MigPlan CR マニフェストを取得して変更を確認します。

   $ oc get migplan <migplan> -o yaml -n openshift-migration

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. Filter by keyword (この場合は、OCS) を使用し、 OpenShift Container Storage Operator を見つけます。
3. OpenShift Container Storage Operator を選択し、Install をクリックします。
4. Update Channel、Installation Mode、および Approval Strategy を選択します。

5. Install をクリックします。

   Installed Operators ページで、OpenShift Container Storage Operator は、Succeeded のステータスと共に openshift-storage プロジェクトに表示されます。

手順

1. OpenShift Container Platform クラスターにログインします。

   $ oc login

2. NooBaa CR 設定ファイル noobaa.yml を以下の内容で作成します。

   apiVersion: noobaa.io/v1alpha1
   kind: NooBaa
   metadata:
     name: noobaa
     namespace: openshift-storage
   spec:
    dbResources:
      requests:
        cpu: 0.5 1
        memory: 1Gi
    coreResources:
      requests:
        cpu: 0.5 2
        memory: 1Gi

   1 2

   非常に小規模なクラスターの場合、cpu の値を 0.1 に変更できます。

3. NooBaa オブジェクトを作成します。

   $ oc create -f noobaa.yml

4. 以下の内容で、BackingStore CR 設定ファイル bs.yml を作成します。

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: mcg-pv-pool-bs
     namespace: openshift-storage
   spec:
     pvPool:
       numVolumes: 3 1
       resources:
         requests:
           storage: 50Gi 2
       storageClass: gp2 3
     type: pv-pool

   1

   永続ボリュームプール内のボリューム数を指定します。

   2

   ボリュームのサイズを指定します。

   3

   ストレージクラスを作成します。

5. BackingStore オブジェクトを作成します。

   $ oc create -f bs.yml

6. 以下の内容で BucketClass CR 設定ファイル bc.yml を作成します。

   apiVersion: noobaa.io/v1alpha1
   kind: BucketClass
   metadata:
     labels:
       app: noobaa
     name: mcg-pv-pool-bc
     namespace: openshift-storage
   spec:
     placementPolicy:
       tiers:
       - backingStores:
         - mcg-pv-pool-bs
         placement: Spread

7. BucketClass オブジェクトを作成します。

   $ oc create -f bc.yml

8. 以下の内容で ObjectBucketClaim CR 設定ファイル obc.yml を作成します。

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: migstorage
     namespace: openshift-storage
   spec:
     bucketName: migstorage 1
     storageClassName: openshift-storage.noobaa.io
     additionalConfig:
       bucketclass: mcg-pv-pool-bc

   1

   レプリケーションリポジトリーを MTC の Web コンソールに追加するために使用するバケット名を記録します。

9. ObjectBucketClaim オブジェクトを作成します。

   $ oc create -f obc.yml

10. リソース作成プロセスを監視し、ObjectBucketClaim ステータスが Bound であることを確認します。

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    このプロセスには、5 分から 10 分の時間がかかる場合があります。

11. 以下の値を取得して記録します。この値は、レプリケーションリポジトリーを MTC の Web コンソールに追加する際に必要になります。

    • S3 エンドポイント:

      $ oc get route -n openshift-storage s3

    • S3 プロバイダーアクセスキー:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode

    • S3 プロバイダーシークレットアクセスキー:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

手順

1. ソースおよびターゲットクラスターで内部レジストリーを公開します。
2. 非セキュアなレジストリーを使用している場合、レジストリーホスト値を /etc/container/registries.conf の [registries.insecure] セクションの追加し、podman で TLS 検証エラーが生じないようにします。

3. ソースクラスターレジストリーにログインします。

   $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <source_cluster>

4. ターゲットクラスターレジストリーにログインします。

   $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <target_cluster>

5. 非推奨のイメージをプルします。

   $ podman pull <source_cluster>/openshift/<image>

6. ターゲットクラスターレジストリーのイメージにタグを付けます。

   $ podman tag <source_cluster>/openshift/<image> <target_cluster>/openshift/<image>

7. イメージをターゲットクラスター 4 レジストリーにプッシュします。

   $ podman push <target_cluster>/openshift/<image>

8. イメージにターゲットクラスターの有効なイメージストリームがあることを確認します。

   $ oc get imagestream -n openshift | grep <image>

   出力例

   <image>    <target_cluster>/openshift/<image>     <versions>
   more...      6 seconds ago

手順

1. MigrationController Pod が実行されるクラスターにログインします。

2. MigrationController CR マニフェストを取得します。

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

3. stunnel_tcp_proxy パラメーターを追加します。

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: migration-controller
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: <stunnel_proxy> 1

   1

   Stunnel プロキシーを指定します: http://<user_name>:<password>@<ip_address>:<port>

4. マニフェストを migration-controller.yaml として保存します。

5. 更新したマニフェストを適用します。

   $ oc replace -f migration-controller.yaml -n openshift-migration

手順

1. MTC がインストールされている OpenShift Container Platform クラスターにログインします。

2. 以下のコマンドを実行して MTC の Web コンソール URL を取得します。

   $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

   出力は https://migration-openshift-migration.apps.cluster.openshift.com のようになります。

3. ブラウザーを起動し、MTC の Web コンソールに移動します。

   注記

   Migration Toolkit for Containers Operator のインストール後すぐに MTC の Web コンソールにアクセスしようとする場合、Operator は依然としてクラスターを設定しているため、コンソールが読み込まれない可能性があります。数分待機した後に再試行します。

4. 自己署名 CA 証明書を使用している場合、ソースクラスター API サーバーの CA 証明書を受け入れることを求めるプロンプトが出されます。Web ページは、残りの証明書を受け入れるプロセスについて説明します。
5. OpenShift Container Platform の ユーザー名 および パスワード を使用してログインします。

手順

1. クラスターにログインする。

2. migration-controller サービスアカウントトークンを取得します。

   $ oc sa get-token migration-controller -n openshift-migration

   出力例

   eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ

3. MTC の Web コンソールで、Clusters をクリックします。
4. Add cluster をクリックします。

5. 以下のフィールドに値を入力します。

   • Cluster name: クラスター名には、小文字 (a-z) および数字 (0-9) を含めることができます。スペースや国際的な文字を含めることはできません。
   • URL: API サーバー URL を指定します (例: https://<www.example.com>:8443)。
   • Service account token: migration-controller サービスアカウントトークンを貼り付けます。

   • Exposed route host to image registry: イメージの直接移行を使用している場合、ソースクラスターのイメージレジストリーへの公開されたルートを指定します (例: www.example.apps.cluster.com)。

     ポートを指定できます。デフォルトのポートは 5000 です。

   • Azure クラスター: Azure スナップショットを使用してデータをコピーする場合は、このオプションを選択する必要があります。
   • Azure resource group: このフィールドは、Azure cluster が選択されている場合に表示されます。Azure リソースグループを指定します。
   • Require SSL verification: オプション: このオプションを選択してクラスターへの SSL 接続を検証します。
   • CA bundle file: このフィールドは、Require SSL verification が選択されている場合に表示されます。自己署名証明書用にカスタム CA 証明書バンドルファイルを作成している場合は、Browse をクリックして CA バンドルファイルを選択し、これをアップロードします。

6. Add cluster をクリックします。

   クラスターが Clusters 一覧に表示されます。

手順

1. MTC の Web コンソールで、Replication repositories をクリックします。
2. Add repository をクリックします。

3. Storage provider type を選択し、以下のフィールドに入力します。

   • AWS (AWS S3、MCG、および汎用 S3 プロバイダーの場合):

     • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
     • S3 bucket name: 作成した S3 バケットの名前を指定します。
     • S3 bucket region: S3 バケットリージョンを指定します。AWS S3 の場合に必須です。Optional (他の S3 プロバイダーの場合)。
     • S3 endpoint: バケットではなく S3 サービスの URL を指定します (例: https://<s3-storage.apps.cluster.com>)。汎用 S3 プロバイダーの場合は必須です。https:// 接頭辞を使用する必要があります。
     • S3 provider access key: AWS には <AWS_SECRET_ACCESS_KEY> を指定するか、または MCG には S3 プロバイダーアクセスキーを指定します。
     • S3 provider secret access key: AWS には <AWS_ACCESS_KEY_ID> を指定するか、または MCG には S3 プロバイダーシークレットアクセスキーを指定します。
     • Require SSL verification: 汎用 S3 プロバイダーを使用している場合は、このチェックボックスをクリアします。
     • カスタム CA バンドルを使用する場合は、Browse をクリックし、Base64 でエンコードされた CA バンドルファイルを参照します。

   • GCP:

     • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
     • GCP bucket name: GCP バケットの名前を指定します。
     • GCP credential JSON blob: credentials-velero ファイルに文字列を指定します。

   • Azure:

     • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
     • Azure resource group: Azure Blob ストレージのリソースグループを指定します。
     • Azure storage account name: Azure Blob ストレージアカウント名を指定します。
     • Azure credentials - INI file contents: credentials-velero ファイルに文字列を指定します。
4. Add repository をクリックし、接続の検証を待機します。

5. Close をクリックします。

   新規リポジトリーが Replication repositories 一覧に表示されます。

手順

1. MTC Web コンソールで、Migration plans をクリックします。
2. Add migration plan をクリックします。

3. Plan name を入力し、Next をクリックします。

   移行計画名には、254 以上の小文字の英数字 (a-z, 0-9) を使用できず、スペースやアンダースコア (_) を含めることはできません。

4. Source cluster を選択します。
5. Target clusterを選択します。
6. Replication repository を選択します。
7. 移行するプロジェクトを選択し、Next をクリックします。
8. Source cluster、Target cluster、および Repository を選択し、 Next をクリックします。
9. Namespaces ページで、移行するプロジェクトを選択し、 Next をクリックします。

10. Persistent volumes ページで、各 PV の Migration type をクリックします。

    • Copy オプションは、ソースクラスターの PV のデータをレプリケーションリポジトリーにコピーしてから、データを同様の特徴のある新規に作成された PV でターゲットクラスターで復元します。
    • Move オプションは、ソースクラスターからリモートボリューム (例: NFS) をアンマウントし、リモートボリュームをポイントするターゲットクラスターで PV リソースを作成し、その後にリモートボリュームをターゲットクラスターにマウントします。ターゲットクラスターで実行されているアプリケーションは、ソースクラスターが使用していたものと同じリモートボリュームを使用します。
11. Next をクリックします。

12. Copy options ページで、それぞれの PV について Copy method を選択します。

    • スナップショットのコピー は、クラウドプロバイダーのスナップショット機能を使用してデータのバックアップおよび復元を行います。この場合、ファイルシステムのコピー を使用する場合よりもはるかに高速になります。

    • ファイルシステムのコピー は、ソースクラスターのファイルをバックアップし、それらをターゲットクラスターで復元します。

      ファイルシステムのコピー方法は、ボリュームの直接移行に必要です。

13. Verify copy を選択して、ファイルシステムのコピー で移行されたデータを確認します。データは、各ソースファイルのチェックサムを生成し、復元後のチェックサムを確認して検証されます。データ検証は、パフォーマンスを大幅に低下させます。

14. Target storage class を選択します。

    Filesystem copy を選択している場合、ターゲットストレージクラスを変更できます。

15. Next をクリックします。

16. Migration options ページで、ソースクラスターに公開されたイメージレジストリールートを指定した場合に Direct image migration オプションが選択されます。Filesystem copy でデータを移行する場合、Direct PV migration オプションが選択されます。

    直接の移行オプションは、イメージおよびファイルをソースクラスターからターゲットクラスターに直接コピーします。このオプションは、イメージおよびファイルをソースクラスターからレプリケーションリポジトリーにコピーしてから、レプリケーションリポジトリーからターゲットクラスターにコピーする場合よりもはるかに高速になります。

17. Next をクリックします。

18. オプション: Hooks ページで Add Hook をクリックし、移行計画にフックを追加します。

    フックはカスタムコードを実行します。単一の移行計画計画に最大 4 つのフックを追加できます。各フックは異なる移行ステップで実行されます。

    1. Web コンソールに表示するフックの名前を入力します。
    2. フックが Ansible Playbook の場合はAnsible playbook を選択し、Browse をクリックして Playbook をアップロードするか、フィールドに Playbook の内容を貼り付けます。
    3. オプション: デフォルトのフックイメージを使用していない場合は、Ansible ランタイムイメージを指定します。

    4. フックが Ansible Playbook ではない場合には、Custom container image をクリックし、イメージ名とパスを指定します。

       カスタムコンテナーイメージには、Ansible Playbook を含めることができます。

    5. Source cluster または Target cluster を選択します。
    6. Service account name および Service account namespace を入力します。

    7. フックの移行手順を選択します。

       • preBackup: アプリケーションのワークロードがソースクラスターでバックアップされる前
       • postBackup: アプリケーションのワークロードがソースクラスターでバックアップされた後
       • preRestore: アプリケーションのワークロードがターゲットクラスターで復元される前
       • postRestore: アプリケーションのワークロードがターゲットクラスターで復元された後
    8. Add をクリックします。

19. Finish をクリックします。

    移行計画は、Migration plans 一覧に表示されます。

手順

1. ソースクラスターにログインします。

2. 古いイメージを削除します。

   $ oc adm prune images

3. MTC の Web コンソールにログインし、Migration plans をクリックします。

4. 移行計画の横にある Options メニュー をクリックし、Stage を選択して、アプリケーションを停止せずにソースクラスターからターゲットクラスターにデータをコピーします。

   実際の移行時間を短縮するには、Stage を複数回実行することができます。

5. アプリケーションのワークロードを移行する準備ができたら、移行計画の横にある Options メニュー をクリックし、Migrate を選択します。
6. オプション: Migrate ウィンドウで Do not stop applications on the source cluster during migration を選択できます。
7. Migrate をクリックします。

8. 移行が完了したら、アプリケーションが OpenShift Container Platform Web コンソールで正常に移行されていることを確認します。

   1. Home → Projects をクリックします。
   2. 移行されたプロジェクトをクリックしてそのステータスを表示します。
   3. Routes セクションで Location をクリックし、アプリケーションが機能していることを確認します (該当する場合)。
   4. Workloads → Pods をクリックし、Pod が移行した namespace で実行されていることを確認します。
   5. Storage → Persistent volumes をクリックして、移行した永続ボリュームが正常にプロビジョニングされていることを確認します。

手順

1. host-cluster.yaml という host クラスターの MigCluster CR マニフェストを作成します。

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: host
     namespace: openshift-migration
   spec:
     isHostCluster: true

2. host クラスターの MigCluster CR を作成します。

   $ oc create -f host-cluster.yaml -n openshift-migration

3. 各リモートクラスターに、cluster-secret.yaml という Secret CR マニフェストを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: <cluster_secret>
     namespace: openshift-config
   type: Opaque
   data:
     saToken: <sa_token> 1

   1

   リモートクラスターの base64 でエンコードされた migration-controller サービスアカウント (SA) トークンを指定します。

   以下のコマンドを実行して SA トークンを取得できます。

   $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0

4. それぞれのリモートクラスターに Secret CR を作成します。

   $ oc create -f cluster-secret.yaml

5. それぞれのリモートクラスターに、remote-cluster.yaml という MigCluster CR マニフェストを作成します。

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <remote_cluster>
     namespace: openshift-migration
   spec:
     exposedRegistryPath: <exposed_registry_route> 1
     insecure: false 2
     isHostCluster: false
     serviceAccountSecretRef:
       name: <remote_cluster_secret> 3
       namespace: openshift-config
     url: <remote_cluster_url> 4

   1

   オプション: 直接的なイメージの移行を実行する場合、公開されるレジストリールートを指定します (例: docker-registry-default.apps.example.com)。

   2

   SSL 検証は、false の場合に有効になります。CA 証明書は、true の場合は必要ではなく、チェックされません。

   3

   リモートクラスターの Secret CR を指定します。

   4

   リモートクラスターの URL を指定します。

6. それぞれのリモートクラスターについて MigCluster CR を作成します。

   $ oc create -f remote-cluster.yaml -n openshift-migration

7. すべてのクラスターが Ready 状態にあることを確認します。

   $ oc describe cluster <cluster_name>

8. storage-secret.yaml というレプリケーションリポジトリーの Secret CR マニフェストを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     namespace: openshift-config
     name: <migstorage_creds>
   type: Opaque
   data:
     aws-access-key-id: <key_id_base64> 1
     aws-secret-access-key: <secret_key_base64> 2

   1

   キー ID を base64 形式で指定します。

   2

   シークレットキーを base64 形式で指定します。

   AWS 認証情報はデフォルトで base64 でエンコードされます。別のストレージプロバイダーを使用している場合、それぞれのキーを使用して以下のコマンドを実行して、認証情報をエンコードする必要があります。

   $ echo -n "<key>" | base64 -w 0 1

   1

   キー ID またはシークレットキーを指定します。どちらの値も base64 でエンコードする必要があります。

9. レプリケーションリポジトリーの Secret CR を作成します。

   $ oc create -f storage-secret.yaml

10. migstorage.yaml というレプリケーションリポジトリーの MigStorage CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5

    1

    バケット名を指定します。

    2

    オブジェクトストレージの Secrets CR を指定します。オブジェクトストレージの Secrets CR に保存される認証情報が正しいことを確認する必要があります。

    3

    ストレージプロバイダーを指定します。

    4

    オプション: スナップショットを使用してデータをコピーする場合は、オブジェクトストレージの Secrets CR を指定します。オブジェクトストレージの Secrets CR に保存される認証情報が正しいことを確認する必要があります。

    5

    オプション: スナップショットを使用してデータをコピーする場合は、ストレージプロバイダーを指定します。

11. MigStorage CR を作成します。

    $ oc create -f migstorage.yaml -n openshift-migration

12. MigStorage CR が Ready 状態にあることを確認します。

    $ oc describe migstorage <migstorage_name>

13. migplan.yaml という MigPlan CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration

    1

    false の場合、直接的なイメージ移行が有効にされます。

    2

    false の場合、直接的なボリューム移行が有効にされます。

    3

    MigStorage CR インスタンスの名前を指定します。

    4

    移行する namespace を 1 つ以上指定します。

    5

    ソースクラスター MigCluster インスタンスの名前を指定します。

14. MigPlan CR を作成します。

    $ oc create -f migplan.yaml -n openshift-migration

15. MigPlan インスタンスを表示し、そのインスタンスが Ready 状態にあることを確認します。

    $ oc describe migplan <migplan_name> -n openshift-migration

16. migmigration.yaml という MigMigration CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4

    1

    MigPlan CR 名を指定します。

    2

    true の場合、ソースクラスターの Pod は停止します。

    3

    true の場合、アプリケーションを停止せずにほとんどのデータをコピーする段階移行が実行されます。

    4

    true の場合、完了した移行がロールバックされます。

17. MigMigration CR を作成し、MigPlan CR に定義された移行を開始します。

    $ oc create -f migmigration.yaml -n openshift-migration

18. MigMigration CR を監視して移行の進捗を確認します。

    $ oc watch migmigration <migmigration_name> -n openshift-migration

    出力は以下のようになります。

    出力例

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       my_application
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

手順

1. MigrationController カスタムリソース (CR) マニフェストを編集します。

   $ oc edit migrationcontroller -n openshift-migration

2. 以下のパラメーターを更新します。

   ...
   mig_controller_limits_cpu: "1" 1
   mig_controller_limits_memory: "10Gi" 2
   ...
   mig_controller_requests_cpu: "100m" 3
   mig_controller_requests_memory: "350Mi" 4
   ...
   mig_pv_limit: 100 5
   mig_pod_limit: 100 6
   mig_namespace_limit: 10 7
   ...

   1

   MigrationController CR で利用可能な CPU の数を指定します。

   2

   MigrationController CR で利用可能なメモリー量を指定します。

   3

   MigrationController CR 要求で利用可能な CPU ユニットの数を指定します。100m は 0.1 CPU ユニット (100 * 1e-3) を表します。

   4

   MigrationController CR 要求で利用可能なメモリーの量を指定します。

   5

   移行可能な永続ボリュームの数を指定します。

   6

   移行可能な Pod の数を指定します。

   7

   移行可能な namespace の数を指定します。

3. 更新されたパラメーターを使用して変更を検証する移行計画を作成します。

   移行計画が MigrationController CR の制限を超える場合、MTC コンソールには移行計画を保存する際に警告メッセージが表示されます。

手順

1. MigrationController カスタムリソースマニフェストを編集します。

   $ oc edit migrationcontroller <migration_controller> -n openshift-migration

2. spec セクションの更新は、特定リソースを除外するためにパラメーターを追加するか、または独自の除外パラメーターがない場合はリソースを excluded_resources パラメーターに追加して実行します。

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: migration-controller
     namespace: openshift-migration
   spec:
     disable_image_migration: true 1
     disable_pv_migration: true 2
     ...
     excluded_resources: 3
     - imagetags
     - templateinstances
     - clusterserviceversions
     - packagemanifests
     - subscriptions
     - servicebrokers
     - servicebindings
     - serviceclasses
     - serviceinstances
     - serviceplans
     - operatorgroups
     - events

   1

   disable_image_migration: true を追加して、移行からイメージストリームを除外します。excluded_resources パラメーターは編集しないでください。imagestreams は、 MigrationController Pod の再起動時に excluded_resources に追加されます。

   2

   disable_pv_migration: true を追加して、移行計画から PV を除外します。excluded_resources パラメーターは編集しないでください。persistentvolumes および persistentvolumeclaims は、MigrationController Pod の再起動時に excluded_resources に追加されます。PV 移行を無効にすると、移行計画の作成時に PV 検出も無効にできます。

   3

   OpenShift Container Platform リソースを excluded_resources 一覧に追加できます。デフォルトの除外されたリソースは削除しないでください。これらのリソースには移行に関連した問題があり、除外する必要があります。

3. MigrationController Pod が再起動し、変更が適用されるまで 2 分待機します。

4. リソースが除外されていることを確認します。

   $ oc get deployment -n openshift-migration migration-controller -o yaml | grep EXCLUDED_RESOURCES -A1

   出力には、除外されたリソースが含まれます。

   出力例

       - name: EXCLUDED_RESOURCES
         value:
         imagetags,templateinstances,clusterserviceversions,packagemanifests,subscriptions,servicebrokers,servicebindings,serviceclasses,serviceinstances,serviceplans,imagestreams,persistentvolumes,persistentvolumeclaims

手順

1. MTC コンソールに移動し、ブラウザーの Web インスペクターで要素を検査します。

2. MigrationUI Pod ログを確認します。

   $ oc logs <MigrationUI_Pod> -n openshift-migration

手順

1. OpenShift Container Platform Web コンソールで、Operators → Installed Operators に移動します。
2. Migration Toolkit for Containers Operator をクリックします。
3. MigrationController タブで、migration-controller をクリックします。

4. YAML タブで、以下のパラメーター値を更新します。

   spec:
     restic_timeout: 1h 1

   1

   有効な単位は h (時間)、m (分)、および s (秒) です (例: 3h30m15s)。

5. Save をクリックします。

手順

1. ターゲットクラスターにログインします。

2. Restore CR を表示します。

   $ oc describe <registry-example-migration-rvwcm> -n openshift-migration

   出力では、PodVolumeRestore エラーのある永続ボリュームを特定できます。

   出力例

   status:
     phase: Completed
     podVolumeRestoreErrors:
     - kind: PodVolumeRestore
       name: <registry-example-migration-rvwcm-98t49>
       namespace: openshift-migration
     podVolumeRestoreResticErrors:
     - kind: PodVolumeRestore
       name: <registry-example-migration-rvwcm-98t49>
       namespace: openshift-migration

3. PodVolumeRestore CR を表示します。

   $ oc describe <migration-example-rvwcm-98t49>

   出力では、エラーをログに記録した Restic Pod を特定できます。

   出力例

     completionTimestamp: 2020-05-01T20:49:12Z
     errors: 1
     resticErrors: 1
     ...
     resticPod: <restic-nr2v5>

4. Restic Pod ログを表示し、エラーを見つけます。

   $ oc logs -f <restic-nr2v5>

手順

1. MigMigration CR のステータスを確認します。

   $ oc get migmigration <migmigration> -o yaml

   出力例

   status:
     conditions:
     - category: Warn
       durable: true
       lastTransitionTime: "2021-01-26T20:48:40Z"
       message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
       status: "True"
       type: VeleroFinalRestorePartiallyFailed
     - category: Advisory
       durable: true
       lastTransitionTime: "2021-01-26T20:48:42Z"
       message: The migration has completed with warnings, please look at `Warn` conditions.
       reason: Completed
       status: "True"
       type: SucceededWithWarnings

2. Velero describe コマンドを使用して Restore CR のステータスを確認します。

   $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>

   出力例

   Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
   
   Errors:
     Velero:     <none>
     Cluster:    <none>
     Namespaces:
       migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource

3. Velero logs コマンドを使用して Restore CR ログを確認します。

   $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>

   出力例

   time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
   time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

   Restore CR のログエラーメッセージの the server could not find the requested resource は、部分的に失敗した移行の原因を示します。

手順

1. MTC Web コンソールで、Migration plans をクリックします。
2. 移行計画の横にある Options メニュー をクリックし、 Rollback を選択します。

3. Rollback をクリックし、ロールバックが完了するまで待機します。

   移行計画の詳細に、Rollback succeeded が表示されます。

4. ソースクラスターの OpenShift Container Platform Web コンソールでロールバックが正常に行われたことを確認します。

   1. Home → Projects をクリックします。
   2. 移行されたプロジェクトをクリックしてそのステータスを表示します。
   3. Routes セクションで Location をクリックし、アプリケーションが機能していることを確認します (該当する場合)。
   4. Workloads → Pods をクリックし、Pod が移行した namespace で実行されていることを確認します。
   5. Storage → Persistent volumes をクリックして、移行した永続ボリュームが正常にプロビジョニングされていることを確認します。

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. Filter by keyword フィールドを使用して、 Migration Toolkit for Containers Operator を見つけます。

3. Migration Toolkit for Containers Operator を選択し、Install をクリックします。

   注記

   サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

4. Install をクリックします。

   Installed Operators ページで、Migration Toolkit for Containers Operator は、Succeeded のステータスで openshift-migration プロジェクトに表示されます。

5. Migration Toolkit for Containers Operator をクリックします。
6. Provided APIs の下で Migration Controller タイルを見つけ、Create Instance をクリックします。
7. Create をクリックします。
8. Workloads → Pods をクリックし、MTC Pod が実行されていることを確認します。

手順

1. OpenShift Container Platform Web コンソールで、Catalog → OperatorHub をクリックします。
2. Filter by keyword フィールドを使用して、 Migration Toolkit for Containers Operator を見つけます。

3. Migration Toolkit for Containers Operator を選択し、Install をクリックします。

   注記

   サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

4. Install をクリックします。

   Installed Operators ページで、Migration Toolkit for Containers Operator は、Succeeded のステータスで openshift-migration プロジェクトに表示されます。

5. Migration Toolkit for Containers Operator をクリックします。
6. Provided APIs の下で Migration Controller タイルを見つけ、Create Instance をクリックします。

7. migration-controller カスタムリソースマニフェストで以下のパラメーターを更新します。

   spec:
   ...
     migration_controller: false
     migration_ui: false
   ...
     deprecated_cors_configuration: true 1

   1

   deprecated_cors_configuration パラメーターとその値を追加します。

8. Create をクリックします。
9. Workloads → Pods をクリックし、MTC Pod が実行されていることを確認します。

手順

1. ネットワークアクセスが無制限のワークステーションで、ターゲットミラーレジストリーを使用して認証を行います。

   $ podman login <registry_host_name>

   また、ビルド時にベースイメージをプルできるように、registry.redhat.io で認証します。

   $ podman login registry.redhat.io

2. Quay.io から redhat-operators カタログをベースにカタログイメージをビルドし、そのイメージにタグを付け、ミラーレジストリーにプッシュします。

   $ oc adm catalog build \
       --appregistry-org redhat-operators \1
       --from=registry.redhat.io/openshift4/ose-operator-registry:v4.5 \2
       --filter-by-os="linux/amd64" \3
       --to=<registry_host_name>:<port>/olm/redhat-operators:v1 \4
       [-a ${REG_CREDS}] \5
       [--insecure] \6
       [--auth-token "${AUTH_TOKEN}"] 7

   1

   App Registry インスタンスからのプルに使用する組織 (namespace)。

   2

   ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用して、--from を ose-operator-registry ベースイメージに設定します。

   3

   --filter-by-os を、ターゲットの OpenShift Container Platform クラスターと一致する必要のある、ベースイメージに使用するオペレーティングシステムおよびアーキテクチャーに設定します。使用できる値は、linux/amd64、linux/ppc64le、および linux/s390x です。

   4

   カタログイメージに名前を付け、v1 などのタグを追加します。

   5

   オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。

   6

   オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。

   7

   オプション: 公開されていない他のアプリケーションレジストリーカタログが使用されている場合、Quay 認証トークンを指定します。

   出力例

   INFO[0013] loading Bundles                               dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605
   ...
   Pushed sha256:f73d42950021f9240389f99ddc5b0c7f1b533c054ba344654ff1edaf6bf827e3 to example_registry:5000/olm/redhat-operators:v1

   無効なマニフェストが Red Hat のカタログに誤って導入されることあります。これが実際に生じる場合には、以下のようなエラーが表示される可能性があります。

   エラーのある出力の例

   ...
   INFO[0014] directory                                     dir=/var/folders/st/9cskxqs53ll3wdn434vw4cd80000gn/T/300666084/manifests-829192605 file=4.2 load=package
   W1114 19:42:37.876180   34665 builder.go:141] error building database: error loading package into db: fuse-camel-k-operator.v7.5.0 specifies replacement that couldn't be found
   Uploading ... 244.9kB/s

   通常、これらのエラーは致命的なエラーではなく、該当する Operator パッケージにインストールする予定の Operator やその依存関係が含まれない場合、それらを無視することができます。

手順

1. oc adm catalog mirror コマンドは、カスタム Operator カタログイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。以下のいずれかを選択できます。

   • コマンドのデフォルト動作で、マニフェストの生成後にすべてのイメージコンテンツをミラーレジストリーに自動的にミラーリングできるようにします。または、
   • --manifests-only フラグを追加して、ミラーリングに必要なマニフェストのみを生成しますが、これにより、イメージコンテンツがレジストリーに自動的にミラーリングされる訳ではありません。これは、ミラーリングする内容を確認するのに役立ちます。また、コンテンツのサブセットのみが必要な場合に、マッピングの一覧に変更を加えることができます。次に、そのファイルを oc image mirror コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。

   ネットワークアクセスが無制限のワークステーションで、以下のコマンドを実行します。

   $ oc adm catalog mirror \
       <registry_host_name>:<port>/olm/redhat-operators:v1 \1
       <registry_host_name>:<port> \
       [-a ${REG_CREDS}] \2
       [--insecure] \3
       --filter-by-os='.*' \4
       [--manifests-only] 5

   1

   Operator カタログイメージを指定します。

   2

   オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。

   3

   オプション: ターゲットレジストリーの信頼を設定しない場合は、--insecure フラグを追加します。

   4

   このフラグは、現時点で複数のアーキテクチャーのサポートに関して問題が存在するために必要になります。

   5

   オプション: ミラーリングに必要なマニフェストのみを生成し、実際にはイメージコンテンツをレジストリーにミラーリングしません。

   警告

   --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。詳細は、BZ#1890951 を参照してください。

   出力例

   using database path mapping: /:/tmp/190214037
   wrote database to /tmp/190214037
   using database at: /tmp/190214037/bundles.db 1
   ...

   1

   コマンドで生成される一時的なデータベース。

   コマンドの実行後に、<image_name>-manifests/ ディレクトリーが現在のディレクトリーに作成され、以下のファイルが生成されます。

   • これにより、imageContentSourcePolicy.yaml ファイルは ImageContentSourcePolicy オブジェクトを定義します。このオブジェクトは、ノードを Operator マニフェストおよびミラーリングされたレジストリーに保存されるイメージ参照間で変換できるように設定します。
   • mapping.txt ファイルには、すべてのソースイメージが含まれ、これはそれらのイメージをターゲットレジストリー内のどこにマップするかを示します。このファイルは oc image mirror コマンドと互換性があり、ミラーリング設定をさらにカスタマイズするために使用できます。

2. 直前の手順で --manifests-only フラグを使用して、コンテンツのサブセットのみをミラーリングする場合は、以下を実行します。

   1. mapping.txt ファイルのイメージの一覧を仕様に変更します。ミラーリングするイメージのサブセットの名前とバージョンが不明な場合は、以下の手順で確認します。

      1. oc adm catalog mirror コマンドで生成された一時的なデータベースに対して sqlite3 ツールを実行し、一般的な検索クエリーに一致するイメージの一覧を取得します。出力は、後に mapping.txt ファイルを編集する方法を通知するのに役立ちます。

         たとえば、clusterlogging.4.3 の文字列のようなイメージの一覧を取得するには、以下を実行します。

         $ echo "select * from related_image \
             where operatorbundle_name like 'clusterlogging.4.3%';" \
             | sqlite3 -line /tmp/190214037/bundles.db 1

         1

         oc adm catalog mirror コマンドの直前の出力を参照し、データベースファイルのパスを見つけます。

         出力例

         image = registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61
         operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
         
         image = registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506
         operatorbundle_name = clusterlogging.4.3.33-202008111029.p0
         ...

      2. 直前の手順で取得した結果を使用して mapping.txt ファイルを編集し、ミラーリングする必要のあるイメージのサブセットのみを追加します。

         たとえば、前述の出力例の image 値を使用して、mapping.txt ファイルに以下の一致する行が存在することを確認できます。

         mapping.txt の一致するイメージマッピング。

         registry.redhat.io/openshift4/ose-logging-kibana5@sha256:aa4a8b2a00836d0e28aa6497ad90a3c116f135f382d8211e3c55f34fb36dfe61=<registry_host_name>:<port>/openshift4-ose-logging-kibana5:a767c8f0
         registry.redhat.io/openshift4/ose-oauth-proxy@sha256:6b4db07f6e6c962fc96473d86c44532c93b146bbefe311d0c348117bf759c506=<registry_host_name>:<port>/openshift4-ose-oauth-proxy:3754ea2b

         この例では、これらのイメージのみをミラーリングする場合に、mapping.txt ファイルの他のすべてのエントリーを削除し、上記の 2 行のみを残します。

   2. ネットワークアクセスが無制限のワークステーション上で、変更した mapping.txt ファイルを使用し、 oc image mirror コマンドを使用してイメージをレジストリーにミラーリングします。

      $ oc image mirror \
          [-a ${REG_CREDS}] \
          --filter-by-os='.*' \
          -f ./redhat-operators-manifests/mapping.txt

      警告

      --filter-by-os フラグが設定されていない状態か、または .* 以外の値に設定されている場合、コマンドが複数の異なるアーキテクチャーをフィルターし、マニフェスト一覧のダイジェスト (multi-arch image イメージとしても知られる) が変更されます。ダイジェストが間違っていると、それらのイメージおよび Operator の非接続クラスターでのデプロイメントに失敗します。

3. ImageContentSourcePolicy オブジェクトを適用します。

   $ oc apply -f ./redhat-operators-manifests/imageContentSourcePolicy.yaml

4. カタログイメージを参照する CatalogSource オブジェクトを作成します。

   1. 仕様を以下のように変更し、これを catalogsource.yaml ファイルとして保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry_host_name>:<port>/olm/redhat-operators:v1 1
        displayName: My Operator Catalog
        publisher: grpc

      1

      Operator カタログイメージを指定します。

   2. このファイルを使用して CatalogSource オブジェクトを作成します。

      $ oc create -f catalogsource.yaml

5. 以下のリソースが正常に作成されていることを確認します。

   1. Pod を確認します。

      $ oc get pods -n openshift-marketplace

      出力例

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

   2. カタログソースを確認します。

      $ oc get catalogsource -n openshift-marketplace

      出力例

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

   3. パッケージマニフェストを確認します。

      $ oc get packagemanifest -n openshift-marketplace

      出力例

      NAME    CATALOG              AGE
      etcd    My Operator Catalog  34s

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. Filter by keyword フィールドを使用して、 Migration Toolkit for Containers Operator を見つけます。

3. Migration Toolkit for Containers Operator を選択し、Install をクリックします。

   注記

   サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

4. Install をクリックします。

   Installed Operators ページで、Migration Toolkit for Containers Operator は、Succeeded のステータスで openshift-migration プロジェクトに表示されます。

5. Migration Toolkit for Containers Operator をクリックします。
6. Provided APIs の下で Migration Controller タイルを見つけ、Create Instance をクリックします。
7. Create をクリックします。
8. Workloads → Pods をクリックし、MTC Pod が実行されていることを確認します。

手順

1. Filter by keyword フィールドを使用して、 Migration Toolkit for Containers Operator を見つけます。

2. Migration Toolkit for Containers Operator を選択し、Install をクリックします。

   注記

   サブスクリプションの承認オプションを Automatic に変更しないでください。MTC (Migration Toolkit for Containers) のバージョンは、ソースとターゲットクラスターで同一である必要があります。

3. Install をクリックします。

   Installed Operators ページで、Migration Toolkit for Containers Operator は、Succeeded のステータスで openshift-migration プロジェクトに表示されます。

4. Migration Toolkit for Containers Operator をクリックします。
5. Provided APIs の下で Migration Controller タイルを見つけ、Create Instance をクリックします。
6. Create をクリックします。
7. Workloads → Pods をクリックし、MTC Pod が実行されていることを確認します。

手順

1. OpenShift Container Platform コンソールで、Operators → Installed Operators に移動します。

   更新が保留中の Operator は Upgrade available のステータスを表示します。

2. Migration Toolkit for Containers Operator をクリックします。
3. Subscription タブをクリックします。アップグレードの承認を必要とするアップグレードは、Upgrade Status の横に表示されます。たとえば、1 requires approval が表示される可能性があります。
4. 1 requires approval をクリックしてから、Preview Install Plan をクリックします。
5. アップグレードに利用可能なリソースとして一覧表示されているリソースを確認し、Approve をクリックします。
6. Operators → Installed Operators ページに戻り、アップグレードの進捗をモニターします。完了時に、ステータスは Succeeded および Up to date に変更されます。
7. Migration Toolkit for Containers Operator をクリックします。
8. Provided APIs の下で Migration Controller タイルを見つけ、Create Instance をクリックします。

9. MTC を ソース クラスターでアップグレードする場合は、MigrationController カスタムリソース (CR) マニフェストで以下のパラメーターを更新します。

   spec:
   ...
     migration_controller: false
     migration_ui: false
   ...
     deprecated_cors_configuration: true

   ターゲットクラスターの MigrationController CR マニフェストを更新する必要はありません。

10. Create をクリックします。
11. Workloads → Pods をクリックし、MTC Pod が実行されていることを確認します。

手順

1. MigrationController Pod が実行されるクラスターにログインします。

2. MigPlan CR マニフェストを取得します。

   $ oc get migplan <migplan> -o yaml -n openshift-migration

3. 以下のパラメーター値を更新し、ファイルを migplan.yaml として保存します。

   ...
   spec:
     indirectImageMigration: true
     indirectVolumeMigration: true

4. MigPlan CR マニフェストを置き換えて変更を適用します。

   $ oc replace -f migplan.yaml -n openshift-migration

5. 更新された MigPlan CR マニフェストを取得して変更を確認します。

   $ oc get migplan <migplan> -o yaml -n openshift-migration

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
2. Filter by keyword (この場合は、OCS) を使用し、 OpenShift Container Storage Operator を見つけます。
3. OpenShift Container Storage Operator を選択し、Install をクリックします。
4. Update Channel、Installation Mode、および Approval Strategy を選択します。

5. Install をクリックします。

   Installed Operators ページで、OpenShift Container Storage Operator は、Succeeded のステータスと共に openshift-storage プロジェクトに表示されます。

手順

1. OpenShift Container Platform クラスターにログインします。

   $ oc login

2. NooBaa CR 設定ファイル noobaa.yml を以下の内容で作成します。

   apiVersion: noobaa.io/v1alpha1
   kind: NooBaa
   metadata:
     name: noobaa
     namespace: openshift-storage
   spec:
    dbResources:
      requests:
        cpu: 0.5 1
        memory: 1Gi
    coreResources:
      requests:
        cpu: 0.5 2
        memory: 1Gi

   1 2

   非常に小規模なクラスターの場合、cpu の値を 0.1 に変更できます。

3. NooBaa オブジェクトを作成します。

   $ oc create -f noobaa.yml

4. 以下の内容で、BackingStore CR 設定ファイル bs.yml を作成します。

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: mcg-pv-pool-bs
     namespace: openshift-storage
   spec:
     pvPool:
       numVolumes: 3 1
       resources:
         requests:
           storage: 50Gi 2
       storageClass: gp2 3
     type: pv-pool

   1

   永続ボリュームプール内のボリューム数を指定します。

   2

   ボリュームのサイズを指定します。

   3

   ストレージクラスを作成します。

5. BackingStore オブジェクトを作成します。

   $ oc create -f bs.yml

6. 以下の内容で BucketClass CR 設定ファイル bc.yml を作成します。

   apiVersion: noobaa.io/v1alpha1
   kind: BucketClass
   metadata:
     labels:
       app: noobaa
     name: mcg-pv-pool-bc
     namespace: openshift-storage
   spec:
     placementPolicy:
       tiers:
       - backingStores:
         - mcg-pv-pool-bs
         placement: Spread

7. BucketClass オブジェクトを作成します。

   $ oc create -f bc.yml

8. 以下の内容で ObjectBucketClaim CR 設定ファイル obc.yml を作成します。

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: migstorage
     namespace: openshift-storage
   spec:
     bucketName: migstorage 1
     storageClassName: openshift-storage.noobaa.io
     additionalConfig:
       bucketclass: mcg-pv-pool-bc

   1

   レプリケーションリポジトリーを MTC の Web コンソールに追加するために使用するバケット名を記録します。

9. ObjectBucketClaim オブジェクトを作成します。

   $ oc create -f obc.yml

10. リソース作成プロセスを監視し、ObjectBucketClaim ステータスが Bound であることを確認します。

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    このプロセスには、5 分から 10 分の時間がかかる場合があります。

11. 以下の値を取得して記録します。この値は、レプリケーションリポジトリーを MTC の Web コンソールに追加する際に必要になります。

    • S3 エンドポイント:

      $ oc get route -n openshift-storage s3

    • S3 プロバイダーアクセスキー:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode

    • S3 プロバイダーシークレットアクセスキー:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

手順

1. MigrationController Pod が実行されるクラスターにログインします。

2. MigrationController CR マニフェストを取得します。

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

3. stunnel_tcp_proxy パラメーターを追加します。

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: migration-controller
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: <stunnel_proxy> 1

   1

   Stunnel プロキシーを指定します: http://<user_name>:<password>@<ip_address>:<port>

4. マニフェストを migration-controller.yaml として保存します。

5. 更新したマニフェストを適用します。

   $ oc replace -f migration-controller.yaml -n openshift-migration

手順

1. MTC がインストールされている OpenShift Container Platform クラスターにログインします。

2. 以下のコマンドを実行して MTC の Web コンソール URL を取得します。

   $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

   出力は https://migration-openshift-migration.apps.cluster.openshift.com のようになります。

3. ブラウザーを起動し、MTC の Web コンソールに移動します。

   注記

   Migration Toolkit for Containers Operator のインストール後すぐに MTC の Web コンソールにアクセスしようとする場合、Operator は依然としてクラスターを設定しているため、コンソールが読み込まれない可能性があります。数分待機した後に再試行します。

4. 自己署名 CA 証明書を使用している場合、ソースクラスター API サーバーの CA 証明書を受け入れることを求めるプロンプトが出されます。Web ページは、残りの証明書を受け入れるプロセスについて説明します。
5. OpenShift Container Platform の ユーザー名 および パスワード を使用してログインします。

手順

1. クラスターにログインする。

2. migration-controller サービスアカウントトークンを取得します。

   $ oc sa get-token migration-controller -n openshift-migration

   出力例

   eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ

3. MTC の Web コンソールで、Clusters をクリックします。
4. Add cluster をクリックします。

5. 以下のフィールドに値を入力します。

   • Cluster name: クラスター名には、小文字 (a-z) および数字 (0-9) を含めることができます。スペースや国際的な文字を含めることはできません。
   • URL: API サーバー URL を指定します (例: https://<www.example.com>:8443)。
   • Service account token: migration-controller サービスアカウントトークンを貼り付けます。

   • Exposed route host to image registry: イメージの直接移行を使用している場合、ソースクラスターのイメージレジストリーへの公開されたルートを指定します (例: www.example.apps.cluster.com)。

     ポートを指定できます。デフォルトのポートは 5000 です。

   • Azure クラスター: Azure スナップショットを使用してデータをコピーする場合は、このオプションを選択する必要があります。
   • Azure resource group: このフィールドは、Azure cluster が選択されている場合に表示されます。Azure リソースグループを指定します。
   • Require SSL verification: オプション: このオプションを選択してクラスターへの SSL 接続を検証します。
   • CA bundle file: このフィールドは、Require SSL verification が選択されている場合に表示されます。自己署名証明書用にカスタム CA 証明書バンドルファイルを作成している場合は、Browse をクリックして CA バンドルファイルを選択し、これをアップロードします。

6. Add cluster をクリックします。

   クラスターが Clusters 一覧に表示されます。

手順

1. MTC の Web コンソールで、Replication repositories をクリックします。
2. Add repository をクリックします。

3. Storage provider type を選択し、以下のフィールドに入力します。

   • AWS (AWS S3、MCG、および汎用 S3 プロバイダーの場合):

     • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
     • S3 bucket name: 作成した S3 バケットの名前を指定します。
     • S3 bucket region: S3 バケットリージョンを指定します。AWS S3 の場合に必須です。Optional (他の S3 プロバイダーの場合)。
     • S3 endpoint: バケットではなく S3 サービスの URL を指定します (例: https://<s3-storage.apps.cluster.com>)。汎用 S3 プロバイダーの場合は必須です。https:// 接頭辞を使用する必要があります。
     • S3 provider access key: AWS には <AWS_SECRET_ACCESS_KEY> を指定するか、または MCG には S3 プロバイダーアクセスキーを指定します。
     • S3 provider secret access key: AWS には <AWS_ACCESS_KEY_ID> を指定するか、または MCG には S3 プロバイダーシークレットアクセスキーを指定します。
     • Require SSL verification: 汎用 S3 プロバイダーを使用している場合は、このチェックボックスをクリアします。
     • カスタム CA バンドルを使用する場合は、Browse をクリックし、Base64 でエンコードされた CA バンドルファイルを参照します。

   • GCP:

     • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
     • GCP bucket name: GCP バケットの名前を指定します。
     • GCP credential JSON blob: credentials-velero ファイルに文字列を指定します。

   • Azure:

     • Replication repository name: MTC の Web コンソールでレプリケーションリポジトリー名を指定します。
     • Azure resource group: Azure Blob ストレージのリソースグループを指定します。
     • Azure storage account name: Azure Blob ストレージアカウント名を指定します。
     • Azure credentials - INI file contents: credentials-velero ファイルに文字列を指定します。
4. Add repository をクリックし、接続の検証を待機します。

5. Close をクリックします。

   新規リポジトリーが Replication repositories 一覧に表示されます。

手順

1. MTC Web コンソールで、Migration plans をクリックします。
2. Add migration plan をクリックします。

3. Plan name を入力し、Next をクリックします。

   移行計画名には、254 以上の小文字の英数字 (a-z, 0-9) を使用できず、スペースやアンダースコア (_) を含めることはできません。

4. Source cluster を選択します。
5. Target clusterを選択します。
6. Replication repository を選択します。
7. 移行するプロジェクトを選択し、Next をクリックします。
8. Source cluster、Target cluster、および Repository を選択し、 Next をクリックします。
9. Namespaces ページで、移行するプロジェクトを選択し、 Next をクリックします。

10. Persistent volumes ページで、各 PV の Migration type をクリックします。

    • Copy オプションは、ソースクラスターの PV のデータをレプリケーションリポジトリーにコピーしてから、データを同様の特徴のある新規に作成された PV でターゲットクラスターで復元します。
    • Move オプションは、ソースクラスターからリモートボリューム (例: NFS) をアンマウントし、リモートボリュームをポイントするターゲットクラスターで PV リソースを作成し、その後にリモートボリュームをターゲットクラスターにマウントします。ターゲットクラスターで実行されているアプリケーションは、ソースクラスターが使用していたものと同じリモートボリュームを使用します。
11. Next をクリックします。

12. Copy options ページで、それぞれの PV について Copy method を選択します。

    • スナップショットのコピー は、クラウドプロバイダーのスナップショット機能を使用してデータのバックアップおよび復元を行います。この場合、ファイルシステムのコピー を使用する場合よりもはるかに高速になります。

    • ファイルシステムのコピー は、ソースクラスターのファイルをバックアップし、それらをターゲットクラスターで復元します。

      ファイルシステムのコピー方法は、ボリュームの直接移行に必要です。

13. Verify copy を選択して、ファイルシステムのコピー で移行されたデータを確認します。データは、各ソースファイルのチェックサムを生成し、復元後のチェックサムを確認して検証されます。データ検証は、パフォーマンスを大幅に低下させます。

14. Target storage class を選択します。

    Filesystem copy を選択している場合、ターゲットストレージクラスを変更できます。

15. Next をクリックします。

16. Migration options ページで、ソースクラスターに公開されたイメージレジストリールートを指定した場合に Direct image migration オプションが選択されます。Filesystem copy でデータを移行する場合、Direct PV migration オプションが選択されます。

    直接の移行オプションは、イメージおよびファイルをソースクラスターからターゲットクラスターに直接コピーします。このオプションは、イメージおよびファイルをソースクラスターからレプリケーションリポジトリーにコピーしてから、レプリケーションリポジトリーからターゲットクラスターにコピーする場合よりもはるかに高速になります。

17. Next をクリックします。

18. オプション: Hooks ページで Add Hook をクリックし、移行計画にフックを追加します。

    フックはカスタムコードを実行します。単一の移行計画計画に最大 4 つのフックを追加できます。各フックは異なる移行ステップで実行されます。

    1. Web コンソールに表示するフックの名前を入力します。
    2. フックが Ansible Playbook の場合はAnsible playbook を選択し、Browse をクリックして Playbook をアップロードするか、フィールドに Playbook の内容を貼り付けます。
    3. オプション: デフォルトのフックイメージを使用していない場合は、Ansible ランタイムイメージを指定します。

    4. フックが Ansible Playbook ではない場合には、Custom container image をクリックし、イメージ名とパスを指定します。

       カスタムコンテナーイメージには、Ansible Playbook を含めることができます。

    5. Source cluster または Target cluster を選択します。
    6. Service account name および Service account namespace を入力します。

    7. フックの移行手順を選択します。

       • preBackup: アプリケーションのワークロードがソースクラスターでバックアップされる前
       • postBackup: アプリケーションのワークロードがソースクラスターでバックアップされた後
       • preRestore: アプリケーションのワークロードがターゲットクラスターで復元される前
       • postRestore: アプリケーションのワークロードがターゲットクラスターで復元された後
    8. Add をクリックします。

19. Finish をクリックします。

    移行計画は、Migration plans 一覧に表示されます。

手順

1. ソースクラスターにログインします。

2. 古いイメージを削除します。

   $ oc adm prune images

3. MTC の Web コンソールにログインし、Migration plans をクリックします。

4. 移行計画の横にある Options メニュー をクリックし、Stage を選択して、アプリケーションを停止せずにソースクラスターからターゲットクラスターにデータをコピーします。

   実際の移行時間を短縮するには、Stage を複数回実行することができます。

5. アプリケーションのワークロードを移行する準備ができたら、移行計画の横にある Options メニュー をクリックし、Migrate を選択します。
6. オプション: Migrate ウィンドウで Do not stop applications on the source cluster during migration を選択できます。
7. Migrate をクリックします。

8. 移行が完了したら、アプリケーションが OpenShift Container Platform Web コンソールで正常に移行されていることを確認します。

   1. Home → Projects をクリックします。
   2. 移行されたプロジェクトをクリックしてそのステータスを表示します。
   3. Routes セクションで Location をクリックし、アプリケーションが機能していることを確認します (該当する場合)。
   4. Workloads → Pods をクリックし、Pod が移行した namespace で実行されていることを確認します。
   5. Storage → Persistent volumes をクリックして、移行した永続ボリュームが正常にプロビジョニングされていることを確認します。

手順

1. host-cluster.yaml という host クラスターの MigCluster CR マニフェストを作成します。

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: host
     namespace: openshift-migration
   spec:
     isHostCluster: true

2. host クラスターの MigCluster CR を作成します。

   $ oc create -f host-cluster.yaml -n openshift-migration

3. 各リモートクラスターに、cluster-secret.yaml という Secret CR マニフェストを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: <cluster_secret>
     namespace: openshift-config
   type: Opaque
   data:
     saToken: <sa_token> 1

   1

   リモートクラスターの base64 でエンコードされた migration-controller サービスアカウント (SA) トークンを指定します。

   以下のコマンドを実行して SA トークンを取得できます。

   $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0

4. それぞれのリモートクラスターに Secret CR を作成します。

   $ oc create -f cluster-secret.yaml

5. それぞれのリモートクラスターに、remote-cluster.yaml という MigCluster CR マニフェストを作成します。

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <remote_cluster>
     namespace: openshift-migration
   spec:
     exposedRegistryPath: <exposed_registry_route> 1
     insecure: false 2
     isHostCluster: false
     serviceAccountSecretRef:
       name: <remote_cluster_secret> 3
       namespace: openshift-config
     url: <remote_cluster_url> 4

   1

   オプション: 直接的なイメージの移行を実行する場合、公開されるレジストリールートを指定します (例: docker-registry-default.apps.example.com)。

   2

   SSL 検証は、false の場合に有効になります。CA 証明書は、true の場合は必要ではなく、チェックされません。

   3

   リモートクラスターの Secret CR を指定します。

   4

   リモートクラスターの URL を指定します。

6. それぞれのリモートクラスターについて MigCluster CR を作成します。

   $ oc create -f remote-cluster.yaml -n openshift-migration

7. すべてのクラスターが Ready 状態にあることを確認します。

   $ oc describe cluster <cluster_name>

8. storage-secret.yaml というレプリケーションリポジトリーの Secret CR マニフェストを作成します。

   apiVersion: v1
   kind: Secret
   metadata:
     namespace: openshift-config
     name: <migstorage_creds>
   type: Opaque
   data:
     aws-access-key-id: <key_id_base64> 1
     aws-secret-access-key: <secret_key_base64> 2

   1

   キー ID を base64 形式で指定します。

   2

   シークレットキーを base64 形式で指定します。

   AWS 認証情報はデフォルトで base64 でエンコードされます。別のストレージプロバイダーを使用している場合、それぞれのキーを使用して以下のコマンドを実行して、認証情報をエンコードする必要があります。

   $ echo -n "<key>" | base64 -w 0 1

   1

   キー ID またはシークレットキーを指定します。どちらの値も base64 でエンコードする必要があります。

9. レプリケーションリポジトリーの Secret CR を作成します。

   $ oc create -f storage-secret.yaml

10. migstorage.yaml というレプリケーションリポジトリーの MigStorage CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5

    1

    バケット名を指定します。

    2

    オブジェクトストレージの Secrets CR を指定します。オブジェクトストレージの Secrets CR に保存される認証情報が正しいことを確認する必要があります。

    3

    ストレージプロバイダーを指定します。

    4

    オプション: スナップショットを使用してデータをコピーする場合は、オブジェクトストレージの Secrets CR を指定します。オブジェクトストレージの Secrets CR に保存される認証情報が正しいことを確認する必要があります。

    5

    オプション: スナップショットを使用してデータをコピーする場合は、ストレージプロバイダーを指定します。

11. MigStorage CR を作成します。

    $ oc create -f migstorage.yaml -n openshift-migration

12. MigStorage CR が Ready 状態にあることを確認します。

    $ oc describe migstorage <migstorage_name>

13. migplan.yaml という MigPlan CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration

    1

    false の場合、直接的なイメージ移行が有効にされます。

    2

    false の場合、直接的なボリューム移行が有効にされます。

    3

    MigStorage CR インスタンスの名前を指定します。

    4

    移行する namespace を 1 つ以上指定します。

    5

    ソースクラスター MigCluster インスタンスの名前を指定します。

14. MigPlan CR を作成します。

    $ oc create -f migplan.yaml -n openshift-migration

15. MigPlan インスタンスを表示し、そのインスタンスが Ready 状態にあることを確認します。

    $ oc describe migplan <migplan_name> -n openshift-migration

16. migmigration.yaml という MigMigration CR マニフェストを作成します。

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4

    1

    MigPlan CR 名を指定します。

    2

    true の場合、ソースクラスターの Pod は停止します。

    3

    true の場合、アプリケーションを停止せずにほとんどのデータをコピーする段階移行が実行されます。

    4

    true の場合、完了した移行がロールバックされます。

17. MigMigration CR を作成し、MigPlan CR に定義された移行を開始します。

    $ oc create -f migmigration.yaml -n openshift-migration

18. MigMigration CR を監視して移行の進捗を確認します。

    $ oc watch migmigration <migmigration_name> -n openshift-migration

    出力は以下のようになります。

    出力例

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       my_application
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47