3.4. アプリケーションの移行
MTC (Migration Toolkit for Containers) の Web コンソールまたはコマンドラインでアプリケーションを移行できます。
3.4.1. 前提条件
MTC (Migration Toolkit for Containers) には以下の要件があります。
-
cluster-admin
権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。 - MTC のバージョンは、すべてのクラスターで同一である必要があります。
クラスター:
- ソースクラスターは、最新の z-stream リリースにアップグレードされる必要があります。
-
migration-controller
Pod が実行されているクラスターには他のクラスターへの無制限のネットワークアクセスが必要です。 - クラスターには、相互への無制限のネットワークアクセスが必要です。
- クラスターには、レプリケーションリポジトリーへの無制限のネットワークアクセスが必要です。
- クラスターは、ポート 443 で OpenShift ルートを使用して通信できる必要があります。
- クラスターには、Critical (重大) 状態があってはなりません。
- クラスターは Ready (準備) 状態である必要があります。
ボリュームの移行:
- 永続ボリューム (PV) は有効である必要があります。
- PV は永続ボリューム要求にバインドされる必要があります。
- move メソッドを使用して PV をコピーする場合、クラスターにはリモートボリュームへの無制限のネットワークアクセスが必要です。
スナップショット のコピー方法を使用して PV をコピーする場合、以下の前提条件が適用されます。
- クラウドプロバイダーはスナップショットをサポートしている必要があります。
- ボリュームに同じクラウドプロバイダーがなければなりません。
- ボリュームは同じ地理的リージョンにある必要があります。
- ボリュームには同じストレージクラスがなければなりません。
- プロキシー環境でボリュームの直接移行を実行する場合、Stunnel の TCP プロキシーを設定する必要があります。
- イメージの直接移行を実行する場合、ソースクラスターの内部レジストリーを外部トラフィックに公開する必要があります。
3.4.1.1. CA 証明書バンドルファイルの作成
自己署名証明書を使用して MTC (Migration Toolkit for Containers) のクラスターまたはレプリケーションリポジトリーのセキュリティーを保護する場合、証明書の検証は Certificate signed by unknown authority
というエラーメッセージを出して失敗する可能性があります。
カスタム CA 証明書バンドルファイルを作成し、クラスターまたはレプリケーションリポジトリーの追加時に MTC の Web コンソールでこれをアップロードできます。
手順
リモートエンドポイントから CA 証明書をダウンロードし、これを CA バンドルファイルとして保存します。
$ echo -n | openssl s_client -connect <host_FQDN>:<port> \ 1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <ca_bundle.cert> 2
3.4.1.2. ボリュームの直接移行のためのプロキシー設定
プロキシーの背後にあるソースクラスターからボリュームの直接移行を実行している場合、MigrationController
カスタムリソース (CR) で Stunnel プロキシーを設定する必要があります。Stunnel は、証明書を変更せずに、TCP 接続のソースクラスターとターゲットクラスター間に透過的なトンネルを作成します。
ボリュームの直接移行は 1 つのプロキシーのみをサポートします。ターゲットクラスターもプロキシーの背後にある場合、ソースクラスターはターゲットクラスターのルートにアクセスできません。
前提条件
-
cluster-admin
権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
手順
-
MigrationController
Pod が実行されるクラスターにログインします。 MigrationController
CR マニフェストを取得します。$ oc get migrationcontroller <migration_controller> -n openshift-migration
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>
-
マニフェストを
migration-controller.yaml
として保存します。 更新したマニフェストを適用します。
$ oc replace -f migration-controller.yaml -n openshift-migration
3.4.1.3. 移行フックの Ansible Playbook の作成
Ansible Playbook を作成して移行フックとして使用することができます。フックは、MTC Web コンソールを使用するか、MigPlan
カスタムリソース (CR) マニフェストに spec.hooks
パラメーターの値を指定して移行計画に追加できます。
Ansible Playbook はフックコンテナーに設定マップとしてマウントされます。フックコンテナーは、MigPlan
で指定されるクラスター、サービスアカウントおよび namespace を使用してジョブとして実行されます。フックコンテナーは指定されたサービスアカウントトークンを使用して、タスクがクラスターで実行される前に認証を必要としないようにします。
3.4.1.3.1. Ansible モジュール
Ansible shell
モジュールを使用して oc
コマンドを実行できます。
shell
モジュールの例
- hosts: localhost gather_facts: false tasks: - name: get pod name shell: oc get po --all-namespaces
k8s_info
などの kubernetes.core
モジュールを使用して Kubernetes リソースと対話できます。
k8s_facts
モジュールの例
- hosts: localhost gather_facts: false tasks: - name: Get pod k8s_info: kind: pods api: v1 namespace: openshift-migration name: "{{ lookup( 'env', 'HOSTNAME') }}" register: pods - name: Print pod name debug: msg: "{{ pods.resources[0].metadata.name }}"
fail
モジュールを使用して、ゼロ以外の終了ステータスが正常に生成されない場合にゼロ以外の終了ステータスを生成し、フックの成功または失敗が検出されるようにします。フックはジョブとして実行され、フックの成功または失敗のステータスはジョブコンテナーの終了ステータスに基づいて表示されます。
fail
モジュールの例
- hosts: localhost gather_facts: false tasks: - name: Set a boolean set_fact: do_fail: true - name: "fail" fail: msg: "Cause a failure" when: do_fail
3.4.1.3.2. 環境変数
MigPlan
CR 名および移行 namespace は環境変数としてフックコンテナーに渡されます。これらの変数は lookup
プラグインを使用してアクセスされます。
環境変数の例
- hosts: localhost gather_facts: false tasks: - set_fact: namespaces: "{{ (lookup( 'env', 'migration_namespaces')).split(',') }}" - debug: msg: "{{ item }}" with_items: "{{ namespaces }}" - debug: msg: "{{ lookup( 'env', 'migplan_name') }}"