Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

1.6. アプリケーションの移行

MTC (Migration Toolkit for Containers) の Web コンソールまたはコマンドラインでアプリケーションを移行できます。

1.6.1. 前提条件
リンクのコピー

MTC (Migration Toolkit for Containers) には以下の要件があります。

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。
  • MTC のバージョンは、すべてのクラスターで同一である必要があります。

  • アプリケーションが openshift namespace の内部イメージを使用する場合、イメージの必要なバージョンがターゲットクラスターに存在することを確認する必要があります。

    OpenShift Container Platform 4.5 クラスターで非推奨の OpenShift Container Platform 3 イメージを使用できるように、イメージストリームタグを手動で更新できます。

  • クラスター:

    • ソースクラスターは、最新の z-stream リリースにアップグレードされる必要があります。
    • migration-controller Pod が実行されているクラスターには他のクラスターへの無制限のネットワークアクセスが必要です。
    • クラスターには、相互への無制限のネットワークアクセスが必要です。
    • クラスターには、レプリケーションリポジトリーへの無制限のネットワークアクセスが必要です。
    • クラスターは、ポート 443 で OpenShift ルートを使用して通信できる必要があります。
    • クラスターには、Critical (重大) 状態があってはなりません。
    • クラスターは Ready (準備) 状態である必要があります。

  • ボリュームの移行:

    • 永続ボリューム (PV) は有効である必要があります。
    • PV は永続ボリューム要求にバインドされる必要があります。
    • move メソッドを使用して PV をコピーする場合、クラスターにはリモートボリュームへの無制限のネットワークアクセスが必要です。

    • スナップショット のコピー方法を使用して PV をコピーする場合、以下の前提条件が適用されます。

      • クラウドプロバイダーはスナップショットをサポートしている必要があります。
      • ボリュームに同じクラウドプロバイダーがなければなりません。
      • ボリュームは同じ地理的リージョンにある必要があります。
      • ボリュームには同じストレージクラスがなければなりません。
  • プロキシー環境でボリュームの直接移行を実行する場合、Stunnel の TCP プロキシーを設定する必要があります。
  • イメージの直接移行を実行する場合、ソースクラスターの内部レジストリーを外部トラフィックに公開する必要があります。

1.6.1.1. podman を使用した非推奨の内部イメージの更新
リンクのコピー

アプリケーションが openshift namespace のイメージを使用する場合、イメージの必要なバージョンがターゲットクラスターに存在する必要があります。

OpenShift Container Platform 3 イメージが OpenShift Container Platform 4.5 で非推奨になる場合、podman を使用してイメージストリームタグを手動で更新できます。

前提条件

  • podman がインストールされている必要があります。
  • cluster-admin 権限を持つユーザーとしてログインしている必要があります。

手順

  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.6.1.2. 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
1
エンドポイントのホスト FQDN およびポートを指定します (例: api.my-cluster.example.com:6443)。
2
CA バンドルファイルの名前を指定します。

1.6.1.3. ボリュームの直接移行のためのプロキシー設定
リンクのコピー

プロキシーの背後にあるソースクラスターからボリュームの直接移行を実行している場合、MigrationController カスタムリソース (CR) で Stunnel プロキシーを設定する必要があります。Stunnel は、証明書を変更せずに、TCP 接続のソースクラスターとターゲットクラスター間に透過的なトンネルを作成します。

注記

ボリュームの直接移行は 1 つのプロキシーのみをサポートします。ターゲットクラスターもプロキシーの背後にある場合、ソースクラスターはターゲットクラスターのルートにアクセスできません。

前提条件

  • cluster-admin 権限を持つユーザーとしてすべてのクラスターにログインしている必要があります。

手順

  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.6.1.4. 移行フックの Ansible Playbook の作成
リンクのコピー

Ansible Playbook を作成して移行フックとして使用することができます。フックは、MTC Web コンソールを使用するか、MigPlan カスタムリソース (CR) マニフェストに spec.hooks パラメーターの値を指定して移行計画に追加できます。

Ansible Playbook はフックコンテナーに設定マップとしてマウントされます。フックコンテナーは、MigPlan で指定されるクラスター、サービスアカウントおよび namespace を使用してジョブとして実行されます。フックコンテナーは指定されたサービスアカウントトークンを使用して、タスクがクラスターで実行される前に認証を必要としないようにします。

1.6.1.4.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

1.6.1.4.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') }}"

1.6.1.5. 追加リソース
リンクのコピー

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る