非接続環境

手順

1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
2. Product Variant ドロップダウンリストからアーキテクチャーを選択します。
3. バージョン ドロップダウンリストから適切なバージョンを選択します。
4. OpenShift v4.17 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

5. アーカイブを展開します。

   $ tar xvf <file>

6. oc バイナリーを、PATH にあるディレクトリーに配置します。

   PATH を確認するには、以下のコマンドを実行します。

   $ echo $PATH

手順

1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
2. バージョン ドロップダウンリストから適切なバージョンを選択します。
3. OpenShift v4.17 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
4. ZIP プログラムでアーカイブを展開します。

5. oc バイナリーを、PATH にあるディレクトリーに移動します。

   PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

   C:\> path

手順

1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
2. バージョン ドロップダウンリストから適切なバージョンを選択します。

3. OpenShift v4.17 macOS Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

   注記

   macOS arm64 の場合は、OpenShift v4.17 macOS arm64 Client エントリーを選択します。

4. アーカイブを展開し、解凍します。

5. oc バイナリーをパスにあるディレクトリーに移動します。

   PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

   $ echo $PATH

1. イメージセット設定ファイルを作成します。

2. 次のいずれかの方法を使用して、イメージセットをターゲットミラーレジストリーにミラーリングします。

   • イメージセットをターゲットミラーレジストリーに直接ミラーリングします。
   • イメージセットをディスクにミラーリングし、イメージセットをターゲット環境に転送してから、イメージセットをターゲットミラーレジストリーにアップロードします。
3. oc-mirror プラグインが生成したリソースを使用するようにクラスターを設定します。
4. 必要に応じてこれらの手順を繰り返して、ターゲットミラーレジストリーを更新します。

手順

1. oc-mirror CLI プラグインをダウンロードします。

   1. OpenShift Cluster Manager の ダウンロード ページに移動します。
   2. OpenShift 切断インストールツール セクションで、OpenShift Client (oc) ミラープラグイン の ダウンロード をクリックしてファイルを保存します。

2. アーカイブを抽出します。

   $ tar xvzf oc-mirror.tar.gz

3. 必要に応じて、プラグインファイルを更新して実行可能にします。

   $ chmod +x oc-mirror

   注記

   oc-mirror ファイルの名前を変更しないでください。

4. ファイルを PATH に配置して、oc-mirror CLI プラグインをインストールします (例: /usr/local/bin):。

   $ sudo mv oc-mirror /usr/local/bin/.

1. registry.redhat.io プルシークレットを Red Hat OpenShift Cluster Manager からダウンロードします。

2. JSON 形式でプルシークレットのコピーを作成します。

   $ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json> 1

   1

   プルシークレットを保存するフォルダーへのパスおよび作成する JSON ファイルの名前を指定します。

   ファイルの内容は以下の例のようになります。

   {
     "auths": {
       "cloud.openshift.com": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "quay.io": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "registry.connect.redhat.com": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       },
       "registry.redhat.io": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       }
     }
   }

3. ファイルを ~/.docker/config.json または $XDG_RUNTIME_DIR/containers/auth.json として保存します。

1. ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードまたはトークンを生成します。

   $ echo -n '<user_name>:<password>' | base64 -w0 1
   BGVtbYk3ZHAtqXs=

   1

   <user_name> および <password> には、レジストリーに設定したユーザー名およびパスワードを指定します。

2. JSON ファイルを編集し、レジストリーを記述するセクションをこれに追加します。

     "auths": {
       "<mirror_registry>": { 1
         "auth": "<credentials>", 2
         "email": "you@example.com"
       }
     },

   1

   ミラーレジストリーがコンテンツを提供するために使用するレジストリーのドメイン名およびポート (オプション) を指定します。例: registry.example.com または registry.example.com:8443

   2

   ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

   ファイルは以下の例のようになります。

   {
     "auths": {
       "registry.example.com": {
         "auth": "BGVtbYk3ZHAtqXs=",
         "email": "you@example.com"
       },
       "cloud.openshift.com": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "quay.io": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "registry.connect.redhat.com": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       },
       "registry.redhat.io": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       }
     }
   }

手順

1. oc-mirror CLI プラグインをダウンロードします。

   1. OpenShift Cluster Manager の ダウンロード ページに移動します。
   2. OpenShift 切断インストールツール セクションで、OpenShift Client (oc) ミラープラグイン の ダウンロード をクリックしてファイルを保存します。

2. アーカイブを抽出します。

   $ tar xvzf oc-mirror.tar.gz

3. 必要に応じて、プラグインファイルを更新して実行可能にします。

   $ chmod +x oc-mirror

   注記

   oc-mirror ファイルの名前を変更しないでください。

4. ファイルを PATH に配置して、oc-mirror CLI プラグインをインストールします (例: /usr/local/bin):。

   $ sudo mv oc-mirror /usr/local/bin/.

1. registry.redhat.io プルシークレットを Red Hat OpenShift Cluster Manager からダウンロードします。

2. JSON 形式でプルシークレットのコピーを作成します。

   $ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json> 1

   1

   プルシークレットを保存するフォルダーへのパスおよび作成する JSON ファイルの名前を指定します。

   ファイルの内容は以下の例のようになります。

   {
     "auths": {
       "cloud.openshift.com": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "quay.io": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "registry.connect.redhat.com": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       },
       "registry.redhat.io": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       }
     }
   }

3. ファイルを $XDG_RUNTIME_DIR/containers/auth.json として保存します。

4. ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードまたはトークンを生成します。

   $ echo -n '<user_name>:<password>' | base64 -w0 1
   BGVtbYk3ZHAtqXs=

   1

   <user_name> および <password> には、レジストリーに設定したユーザー名およびパスワードを指定します。

5. JSON ファイルを編集し、レジストリーを記述するセクションをこれに追加します。

     "auths": {
       "<mirror_registry>": { 1
         "auth": "<credentials>", 2
         "email": "you@example.com"
       }
     },

   1

   ミラーレジストリーがコンテンツを提供するために使用するレジストリーのドメイン名およびポート (オプション) を指定します。例: registry.example.com または registry.example.com:8443

   2

   ミラーレジストリーの base64 でエンコードされたユーザー名およびパスワードを指定します。

   ファイルは以下の例のようになります。

   {
     "auths": {
       "registry.example.com": {
         "auth": "BGVtbYk3ZHAtqXs=",
         "email": "you@example.com"
       },
       "cloud.openshift.com": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "quay.io": {
         "auth": "b3BlbnNo...",
         "email": "you@example.com"
       },
       "registry.connect.redhat.com": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       },
       "registry.redhat.io": {
         "auth": "NTE3Njg5Nj...",
         "email": "you@example.com"
       }
     }
   }

検証

1. <file_path> ディレクトリーに生成された working-dir ディレクトリー内の cluster-resources ディレクトリーに移動します。
2. ImageDigestMirrorSet、ImageTagMirrorSet、CatalogSource リソースの YAML ファイルが存在することを確認します。

1. ディスクにミラーリングする: ミラーリングするイメージセットを含むアーカイブを準備します。インターネットアクセスは必要ありません。
2. 手動手順: 非接続ミラーレジストリーのネットワークにアーカイブを転送します。
3. ミラーリングするディスク: アーカイブからターゲットの非接続レジストリーにイメージセットをミラーリングするには、ミラーレジストリーにアクセスできる環境から oc-mirror プラグイン v2 を実行します。

検証

1. 次のコマンドを実行して、ImageDigestMirrorSet リソースが正常にインストールされたことを確認します。

   $ oc get imagedigestmirrorset

2. 次のコマンドを実行して、ImageTagMirrorSet リソースが正常にインストールされたことを確認します。

   $ oc get imagetagmirrorset

3. 以下のコマンドを実行して、CatalogSource リソースが正常にインストールされたことを確認します。

   $ oc get catalogsource -n openshift-marketplace

手順

1. 以前のイメージを削除する YAML ファイルを作成します。

   $ oc mirror delete --config delete-image-set-config.yaml --workspace file://<previously_mirrored_work_folder> --v2 --generate docker://<remote_registry>

   ここでは、以下のようになります。

   • <previously_mirrored_work_folder>: ミラーリングプロセス中に、イメージが以前にミラーリングまたは保存されたディレクトリーを使用します。
   • <remote_registry>: 削除するイメージがあるリモートコンテナーレジストリーの URL またはアドレスを挿入します。
2. 作成された <previously_mirrored_work_folder>/delete directory に移動します。
3. delete-images.yaml ファイルが生成されたことを確認します。
4. ファイルにリストされている各イメージがクラスターで不要になり、レジストリーから安全に削除できることを手動で確認します。

5. delete YAML ファイルを生成した後に、リモートレジストリーからイメージを削除します。

   $ oc mirror delete --v2 --delete-yaml-file <previously_mirrored_work_folder>/working-dir/delete/delete-images.yaml docker://<remote_registry>

   ここでは、以下のようになります。

   • <previously_mirrored_work_folder>: 以前にミラーリングした作業フォルダーを指定します。

     重要

     mirror-to-mirror 手順を使用する場合、イメージはローカルにキャッシュされないため、ローカルキャッシュからイメージを削除することはできません。

検証

1. 生成されたワークスペースディレクトリーに移動します。

   $ cd <oc_mirror_workspace_path>

2. 生成された mapping.txt ファイルと missing.txt ファイルを確認します。これらのファイルには、ミラーリングされるすべてのイメージのリストが含まれています。

手順

1. サーバー関連の問題を確認します。

   エラーの例

   [ERROR]  : [Worker] error mirroring image localhost:55000/openshift/graph-image:latest error: copying image 1/4 from manifest list: trying to reuse blob sha256:edab65b863aead24e3ed77cea194b6562143049a9307cd48f86b542db9eecb6e at destination: pinging container registry localhost:5000: Get "https://localhost:5000/v2/": http: server gave HTTP response to HTTPS client

   1. oc-mirror プラグイン v2 出力ディレクトリーにある working-dir/logs フォルダー内の mirroring_error_date_time.log ファイルを開きます。
   2. HTTP 500 エラー、期限切れのトークン、タイムアウトなどの、通常はサーバー側の問題を示すエラーメッセージを探します。
   3. 問題が解決しない場合は、ミラーリングプロセスを再試行するか、サポートにお問い合わせください。

2. Operator の不完全なミラーリングを確認します。

   エラーの例

   error mirroring image docker://registry.redhat.io/3scale-amp2/zync-rhel9@sha256:8bb6b31e108d67476cc62622f20ff8db34efae5d58014de9502336fcc479d86d (Operator bundles: [3scale-operator.v0.11.12] - Operators: [3scale-operator]) error: initializing source docker://localhost:55000/3scale-amp2/zync-rhel9:8bb6b31e108d67476cc62622f20ff8db34efae5d58014de9502336fcc479d86d: reading manifest 8bb6b31e108d67476cc62622f20ff8db34efae5d58014de9502336fcc479d86d in localhost:55000/3scale-amp2/zync-rhel9: manifest unknown
   error mirroring image docker://registry.redhat.io/3scale-amp2/3scale-rhel7-operator-metadata@sha256:de0a70d1263a6a596d28bf376158056631afd0b6159865008a7263a8e9bf0c7d error: skipping operator bundle docker://registry.redhat.io/3scale-amp2/3scale-rhel7-operator-metadata@sha256:de0a70d1263a6a596d28bf376158056631afd0b6159865008a7263a8e9bf0c7d because one of its related images failed to mirror
   error mirroring image docker://registry.redhat.io/3scale-amp2/system-rhel7@sha256:fe77272021867cc6b6d5d0c9bd06c99d4024ad53f1ab94ec0ab69d0fda74588e (Operator bundles: [3scale-operator.v0.11.12] - Operators: [3scale-operator]) error: initializing source docker://localhost:55000/3scale-amp2/system-rhel7:fe77272021867cc6b6d5d0c9bd06c99d4024ad53f1ab94ec0ab69d0fda74588e: reading manifest fe77272021867cc6b6d5d0c9bd06c99d4024ad53f1ab94ec0ab69d0fda74588e in localhost:55000/3scale-amp2/system-rhel7: manifest unknown

   1. コンソールまたはログファイルで、どの Operator が不完全であるかを示す警告を確認します。

      Operator が不完全としてフラグ付けされている場合、その Operator に関連するイメージのミラーリングに失敗した可能性があります。

   2. 不足しているイメージを手動でミラーリングするか、ミラーリングプロセスを再試行します。

3. 生成されたクラスターリソースに関連するエラーを確認します。一部のイメージのミラーリングに失敗した場合でも、oc-mirror v2 は、正常にミラーリングされたイメージに対して IDMS.yaml ファイルや ITMS.yaml ファイルなどのクラスターリソースを生成します。

   1. 生成されたファイルの出力ディレクトリーを確認します。
   2. 特定のイメージでこれらのファイルが見つからない場合、ミラーリングプロセス中にそれらのイメージに重大なエラーが発生していないことを確認します。

1. ユーザーが oc-mirror プラグイン v2 を実行して、オンラインレジストリーのコンテンツをローカルディスクディレクトリーにミラーリングします。
2. ミラーリングしたコンテンツを、オフライン環境への転送用のディスクに保存します。

手順

1. 非接続環境で oc-mirror プラグイン v2 を実行する前に、registries.conf ファイルを作成します。ファイルの TOML 形式は、この仕様で説明されています。

   注記

   ファイルは、$HOME/.config/containers/registries.conf または /etc/containers/registries.conf に保存することが推奨されます。

   registries.conf の例

   [[registry]]
   location="registry.redhat.io"
   [[registry.mirror]]
   location="<enterprise-registry.in>"
   
   [[registry]]
   location="quay.io"
   [[registry.mirror]]
   location="<enterprise-registry.in>"

2. ミラーアーカイブを生成します。

   1. すべての OpenShift Container Platform コンテンツを <file_path>/enterprise-content 配下のディスクのアーカイブに収集するには、次のコマンドを実行します。

      $ oc mirror --v2 -c isc.yaml file://<file_path>/enterprise-content

      isc.yaml の例

      apiVersion: mirror.openshift.io/v2alpha1
      kind: ImageSetConfiguration
      mirror:
        platform:
          architectures:
            - "amd64"
          channels:
            - name: stable-4.15
              minVersion: 4.15.0
              maxVersion: 4.15.3

      生成されたアーカイブは、非接続環境に転送されます。トランスポートメカニズムは、oc-mirror プラグイン v2 に含まれていません。転送ストラテジーは、エンタープライズネットワーク管理者が決定します。

      場合によっては、ディスクをある場所から物理的に取り外し、非接続環境内の別のコンピューターに接続することで、手動で転送します。その他の場合、セキュアファイル転送プロトコル (SFTP) またはその他のプロトコルを使用します。

3. アーカイブの転送が完了したら、次の例のとおり、oc-mirror プラグイン v2 を再度実行して関連するアーカイブの内容をレジストリー (例では entrerpise_registry.in) にミラーリングできます。

   $ oc mirror --v2 -c isc.yaml --from file://<disconnected_environment_file_path>/enterprise-content docker://<enterprise_registry.in>/

   ここでは、以下のようになります。

   • --from は、アーカイブを含むフォルダーを指します。file:// で始まります。
   • docker:// はミラーリングの宛先であり、最後の引数です。Docker レジストリーであるため、そのようになります。
   • -c (--config) は必須の引数です。これにより、oc-mirror プラグイン v2 は最終的にアーカイブのサブ部分のみをレジストリーにミラーリングできます。1 つのアーカイブに複数の OpenShift Container Platform リリースが含まれる場合がありますが、非接続環境またはエンクレーブではそのうちのいくつかのみミラーリングされる可能性があります。

4. エンクレーブにミラーリングするコンテンツを記述する imageSetConfig YAML ファイルを準備します。

   isc-enclave.yaml の例

   apiVersion: mirror.openshift.io/v2alpha1
   kind: ImageSetConfiguration
   mirror:
     platform:
       architectures:
         - "amd64"
       channels:
         - name: stable-4.15
           minVersion: 4.15.2
           maxVersion: 4.15.2

   非接続レジストリーにアクセスできるマシン上で、oc-mirror プラグイン v2 を実行する必要があります。上記の例では、非接続環境 enterprise-registry.in にアクセスできます。

5. グラフの URL を更新する

   graph:true を使用している場合、oc-mirror プラグイン v2 は cincinnati API エンドポイントに到達しようとします。この環境は接続されていないため、OpenShift Update Service (OSUS) の URL を参照するためには環境変数 UPDATE_URL_OVERRIDE をエクスポートする必要があります。

   $ export UPDATE_URL_OVERRIDE=https://<osus.enterprise.in>/graph

   OpenShift クラスターで OSUS を設定する方法の詳細は、「OpenShift Update Service を使用した非接続環境でのクラスターの更新」を参照してください。

1. エンクレーブのエンタープライズレジストリーからミラーアーカイブを生成します。

   enclave1 のアーカイブを準備するには、ユーザーはそのエンクレーブ固有の imageSetConfiguration を使用して、エンタープライズ非接続環境で oc-mirror プラグイン v2 を実行します。これにより、そのエンクレーブに必要なイメージのみがミラーリングされます。

   $ oc mirror --v2 -c isc-enclave.yaml
   file:///disk-enc1/

   このアクションは、OpenShift Container Platform のすべてのコンテンツをアーカイブに収集し、ディスク上にアーカイブを生成します。

2. 生成されたアーカイブは、enclave1 ネットワークに転送されます。トランスポートメカニズムは、oc-mirror プラグイン v2 の責任にはあたりません。

3. エンクレーブレジストリーにコンテンツをミラーリングする

   アーカイブの転送が完了すると、ユーザーは関連するアーカイブの内容をレジストリーにミラーリングするために、oc-mirror プラグイン v2 を再度実行できます。

   $ oc mirror --v2 -c isc-enclave.yaml --from file://local-disk docker://registry.enc1.in

   これで、enclave1 の OpenShift Container Platform クラスターの管理者が、そのクラスターをインストールまたはアップグレードする準備が整いました。

手順

1. Red Hat OpenShift Container Platform Update Graph visualizer および update planner を使用して、あるバージョンから別のバージョンへの更新を計画します。OpenShift Update Graph はチャネルのグラフと、現行バージョンと意図されるクラスターのバージョン間に更新パスがあることを確認する方法を提供します。

2. 必要な環境変数を設定します。

   1. リリースバージョンをエクスポートします。

      $ export OCP_RELEASE=<release_version>

      <release_version> について、更新する OpenShift Container Platform のバージョンに対応するタグを指定します (例: 4.5.4)。

   2. ローカルレジストリー名とホストポートをエクスポートします。

      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'

      <local_registry_host_name> については、ミラーレジストリーのレジストリードメイン名を指定し、<local_registry_host_port> については、コンテンツの送信に使用するポートを指定します。

   3. ローカルリポジトリー名をエクスポートします。

      $ LOCAL_REPOSITORY='<local_repository_name>'

      <local_repository_name> については、ocp4/openshift4 などのレジストリーに作成するリポジトリーの名前を指定します。

   4. OpenShift Update Service を使用している場合は、追加のローカルリポジトリー名をエクスポートして、リリースイメージを含めます。

      $ LOCAL_RELEASE_IMAGES_REPOSITORY='<local_release_images_repository_name>'

      <local_release_images_repository_name> については、ocp4/openshift4-release-images などのレジストリーに作成するリポジトリーの名前を指定します。

   5. ミラーリングするリポジトリーの名前をエクスポートします。

      $ PRODUCT_REPO='openshift-release-dev'

      実稼働環境のリリースの場合には、openshift-release-dev を指定する必要があります。

   6. パスをレジストリープルシークレットにエクスポートします。

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

      <path_to_pull_secret> については、作成したミラーレジストリーのプルシークレットの絶対パスおよびファイル名を指定します。

      注記

      クラスターが ImageContentSourcePolicy オブジェクトを使用してリポジトリーのミラーリングを設定する場合、ミラーリングされたレジストリーにグローバルプルシークレットのみを使用できます。プロジェクトにプルシークレットを追加することはできません。

   7. リリースミラーをエクスポートします。

      $ RELEASE_NAME="ocp-release"

      実稼働環境のリリースは、ocp-release を指定する必要があります。

   8. クラスターのアーキテクチャーのタイプをエクスポートします。

      $ ARCHITECTURE=<cluster_architecture> 1

      1

      x86_64、aarch64、s390x、または ppc64le など、クラスターのアーキテクチャーを指定します。

   9. ミラーリングされたイメージをホストするためにディレクトリーへのパスをエクスポートします。

      $ REMOVABLE_MEDIA_PATH=<path> 1

      1

      最初のスラッシュ (/) 文字を含む完全パスを指定します。

3. ミラーリングするイメージおよび設定マニフェストを確認します。

   $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run

4. バージョンイメージをミラーレジストリーにミラーリングします。

   • ミラーホストがインターネットにアクセスできない場合は、以下の操作を実行します。

     1. リムーバブルメディアをインターネットに接続しているシステムに接続します。

     2. イメージおよび設定マニフェストをリムーバブルメディア上のディレクトリーにミラーリングします。

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}

        注記

        このコマンドは、ミラーリングされたリリースイメージ署名 config map も、リムーバブルメディアに保存します。

     3. メディアを非接続環境に移動し、イメージをローカルコンテナーレジストリーにアップロードします。

        $ oc image mirror  -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 1

        1

        REMOVABLE_MEDIA_PATH の場合、イメージのミラーリング時に指定した同じパスを使用する必要があります。

     4. oc コマンドラインインターフェイス (CLI) を使用して、更新しているクラスターにログインします。

     5. ミラーリングされたリリースイメージ署名設定マップを接続されたクラスターに適用します。

        $ oc apply -f ${REMOVABLE_MEDIA_PATH}/mirror/config/<image_signature_file> 1

        1

        <image_signature_file> について、ファイルのパスおよび名前を指定します (例: signature-sha256-81154f5c03294534.yaml)。

     6. OpenShift Update Service を使用している場合は、リリースイメージを別のリポジトリーにミラーリングします。

        $ oc image mirror -a ${LOCAL_SECRET_JSON} ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} ${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}

   • ローカルコンテナーレジストリーとクラスターがミラーホストに接続されている場合は、次の操作を行います。

     1. 次のコマンドを使用して、リリースイメージをローカルレジストリーに直接プッシュし、config map をクラスターに適用します。

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
          --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} --apply-release-image-signature

        注記

        --apply-release-image-signature オプションが含まれる場合は、イメージ署名の検証用に設定マップを作成しません。

     2. OpenShift Update Service を使用している場合は、リリースイメージを別のリポジトリーにミラーリングします。

        $ oc image mirror -a ${LOCAL_SECRET_JSON} ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} ${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}

手順

1. Web コンソールで Operators → OperatorHub をクリックします。

   注記

   Update Service と Filter by keyword…​ フィールドに入力し、素早く Operator を見つけます。

2. 利用可能な Operator のリストから OpenShift Update Service を選択し、Install をクリックします。

   1. Update channel を選択します。
   2. Version を選択します。
   3. A specific namespace on the cluster が Installation Mode で選択します。
   4. Installed Namespace の namespace を選択するか、推奨される namespace openshift-update-service を受け入れます。

   5. Update approval strategy を選択します。

      • Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
      • Manual ストラテジーには、クラスター管理者が Operator の更新を承認する必要があります。
   6. Install をクリックします。
3. Operators → Installed Operators に移動し、OpenShift Update Service Operator がインストールされていることを確認します。
4. OpenShift Update Service が選択した namespace に、Status が Succeeded でリストされていることを確認します。

手順

1. OpenShift Update Service Operator の namespace を作成します。

   1. OpenShift Update Service Operator の namespace オブジェクト YAML ファイル (update-service-namespace.yaml など) を作成します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-update-service
        annotations:
          openshift.io/node-selector: ""
        labels:
          openshift.io/cluster-monitoring: "true" 1

      1

      openshift.io/cluster-monitoring ラベルを設定して、k この namespace で Operator が推奨するクラスターのモニタリングを有効にします。

   2. namespace を作成します。

      $ oc create -f <filename>.yaml

      以下に例を示します。

      $ oc create -f update-service-namespace.yaml

2. 以下のオブジェクトを作成して OpenShift Update Service Operator をインストールします。

   1. OperatorGroup オブジェクト YAML ファイルを作成します (例: update-service-operator-group.yaml)。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: update-service-operator-group
        namespace: openshift-update-service
      spec:
        targetNamespaces:
        - openshift-update-service

   2. OperatorGroup オブジェクトを作成します。

      $ oc -n openshift-update-service create -f <filename>.yaml

      以下に例を示します。

      $ oc -n openshift-update-service create -f update-service-operator-group.yaml

   3. Subscription オブジェクト YAML ファイルを作成します (例: update-service-subscription.yaml)。

      Subscription の例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: update-service-subscription
        namespace: openshift-update-service
      spec:
        channel: v1
        installPlanApproval: "Automatic"
        source: "redhat-operators" 1
        sourceNamespace: "openshift-marketplace"
        name: "cincinnati-operator"

      1

      Operator を提供するカタログソースの名前を指定します。カスタム Operator Lifecycle Manager (OLM) を使用しないクラスターの場合には、redhat-operators を指定します。OpenShift Container Platform クラスターが非接続環境にインストールされている場合、Operator Lifecycle Manager (OLM) を設定したときに作成された CatalogSource オブジェクトの名前を指定します。

   4. Subscription オブジェクトを作成します。

      $ oc create -f <filename>.yaml

      以下に例を示します。

      $ oc -n openshift-update-service create -f update-service-subscription.yaml

      OpenShift Update Service Operator は openshift-update-service namespace にインストールされ、openshift-update-service namespace をターゲットにします。

3. Operator のインストールを確認します。

   $ oc -n openshift-update-service get clusterserviceversions

   出力例

   NAME                             DISPLAY                    VERSION   REPLACES   PHASE
   update-service-operator.v4.6.0   OpenShift Update Service   4.6.0                Succeeded
   ...

   OpenShift Update Service Operator が記載されている場合には、インストールが成功しています。バージョン番号は表示されているものと異なる場合があります。

手順

1. Web コンソールで Operators → Installed Operators をクリックします。
2. インストールされた Operator のリストから OpenShift Update Service を選択します。
3. Update Service タブをクリックします。
4. Create UpdateService をクリックします。
5. service など、Name フィールドに名前を入力します。
6. Graph Data Image フィールドに「OpenShift Update Service グラフデータコンテナーイメージの作成」で作成した graph-data コンテナーイメージにローカルの pullspec を入力します (例: registry.example.com/openshift/graph-data:latest)。
7. Releases フィールドに、「OpenShift Container Platform イメージリポジトリーのミラーリング」でリリースイメージを含むように作成したレジストリーとリポジトリー (例: registry.example.com/ocp4/openshift4-release-images) を入力します。
8. Replicas フィールドに 2 と入力します。
9. Create をクリックして OpenShift Update Service アプリケーションを作成します。

10. OpenShift Update Service アプリケーションを検証します。

    • Update Service タブの UpdateServices リストから、作成した Update Service アプリケーションをクリックします。
    • Resources タブをクリックします。
    • 各アプリケーションリソースのステータスが Created であることを確認します。

手順

1. OpenShift Update Service ターゲット namespace を設定します (例: openshift-update-service)。

   $ NAMESPACE=openshift-update-service

   namespace は Operator グループの targetNamespaces 値と一致する必要があります。

2. OpenShift Update Service アプリケーションの名前 (例: service) を設定します。

   $ NAME=service

3. 「OpenShift Container Platform イメージリポジトリーのミラーリング」と同じ方法で、リリースイメージのレジストリーおよびリポジトリーを設定します (例: registry.example.com/ocp4/openshift4-release-images)。

   $ RELEASE_IMAGES=registry.example.com/ocp4/openshift4-release-images

4. 「OpenShift Update Service グラフデータコンテナーイメージの作成」で作成したグラフデータコンテナーイメージに、ローカルの pullspec を入力します (例: registry.example.com/openshift/graph-data:latest)。

   $ GRAPH_DATA_IMAGE=registry.example.com/openshift/graph-data:latest

5. OpenShift Update Service アプリケーションオブジェクトを作成します。

   $ oc -n "${NAMESPACE}" create -f - <<EOF
   apiVersion: updateservice.operator.openshift.io/v1
   kind: UpdateService
   metadata:
     name: ${NAME}
   spec:
     replicas: 2
     releases: ${RELEASE_IMAGES}
     graphDataImage: ${GRAPH_DATA_IMAGE}
   EOF

6. OpenShift Update Service アプリケーションを検証します。

   1. 以下のコマンドを使用してポリシーエンジンルートを取得します。

      $ while sleep 1; do POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"; SCHEME="${POLICY_ENGINE_GRAPH_URI%%:*}"; if test "${SCHEME}" = http -o "${SCHEME}" = https; then break; fi; done

      コマンドが成功するまでポーリングが必要になる場合があります。

   2. ポリシーエンジンからグラフを取得します。チャネル に有効なバージョンを指定してください。たとえば、OpenShift Container Platform 4.17 で実行している場合は、stable-4.17 を使用します。

      $ while sleep 10; do HTTP_CODE="$(curl --header Accept:application/json --output /dev/stderr --write-out "%{http_code}" "${POLICY_ENGINE_GRAPH_URI}?channel=stable-4.6")"; if test "${HTTP_CODE}" -eq 200; then break; fi; echo "${HTTP_CODE}"; done

      これにより、グラフ要求が成功するまでポーリングされます。ただし、ミラーリングしたリリースイメージによっては、生成されるグラフが空白の場合があります。

手順

1. ミラーリングされたリポジトリーを設定します。以下のいずれかを実行します。

   • Repository Mirroring in Red Hat Quay で説明されているように、Red Hat Quay でミラーリングされたリポジトリーを設定します。Red Hat Quay を使用すると、あるリポジトリーから別のリポジトリーにイメージをコピーでき、これらのリポジトリーを一定期間繰り返し自動的に同期することもできます。

   • skopeo などのツールを使用して、ソースリポジトリーからミラーリングされたリポジトリーにイメージを手動でコピーします。

     たとえば、Red Hat Enterprise Linux (RHEL 7 または RHEL 8) システムに skopeo RPM パッケージをインストールした後、以下の例に示すように skopeo コマンドを使用します。

     $ skopeo copy --all \
     docker://registry.access.redhat.com/ubi9/ubi-minimal:latest@sha256:5cf... \
     docker://example.io/example/ubi-minimal

     この例では、example.io いう名前のコンテナーイメージレジストリーと example という名前のイメージリポジトリーがあり、そこに registry.access.redhat.com から ubi9/ubi-minimal イメージをコピーします。ミラーリングされたレジストリーを作成した後、ソースリポジトリーに対する要求をミラーリングされたリポジトリーにリダイレクトするように OpenShift Container Platform クラスターを構成できます。

2. 次の例のいずれかを使用して、インストール後のミラー設定 CR を作成します。

   • 必要に応じて ImageDigestMirrorSet または ImageTagMirrorSet CR を作成し、ソースとミラーを独自のレジストリーとリポジトリーのペアとイメージに置き換えます。

     apiVersion: config.openshift.io/v1 1
     kind: ImageDigestMirrorSet 2
     metadata:
       name: ubi9repo
     spec:
       imageDigestMirrors: 3
       - mirrors:
         - example.io/example/ubi-minimal 4
         - example.com/example/ubi-minimal 5
         source: registry.access.redhat.com/ubi9/ubi-minimal 6
         mirrorSourcePolicy: AllowContactingSource 7
       - mirrors:
         - mirror.example.com/redhat
         source: registry.example.com/redhat 8
         mirrorSourcePolicy: AllowContactingSource
       - mirrors:
         - mirror.example.com
         source: registry.example.com 9
         mirrorSourcePolicy: AllowContactingSource
       - mirrors:
         - mirror.example.net/image
         source: registry.example.com/example/myimage 10
         mirrorSourcePolicy: AllowContactingSource
       - mirrors:
         - mirror.example.net
         source: registry.example.com/example 11
         mirrorSourcePolicy: AllowContactingSource
       - mirrors:
         - mirror.example.net/registry-example-com
         source: registry.example.com 12
         mirrorSourcePolicy: AllowContactingSource

     1

     この CR で使用する API を示します。これは config.openshift.io/v1 である必要があります。

     2

     プルタイプに応じてオブジェクトの種類を示します。

     • ImageDigestMirrorSet: ダイジェスト参照イメージをプルします。
     • ImageTagMirrorSet: タグ参照イメージをプルします。

     3

     次のいずれかのイメージプルメソッドのタイプを示します。

     • imageDigestMirrors: ImageDigestMirrorSet CR に使用します。
     • imageTagMirrors: ImageTagMirrorSet CR に使用します。

     4

     ミラーリングされたイメージのレジストリーとリポジトリーの名前を示します。

     5

     オプション: 各ターゲットリポジトリーのセカンダリーミラーリポジトリーを示します。1 つのミラーがダウンすると、ターゲットリポジトリーはセカンダリーミラーを使用できます。

     6

     レジストリーとリポジトリーソースを示します。これは、イメージプル仕様で参照されるリポジトリーです。

     7

     オプション: イメージのプルが失敗した場合のフォールバックポリシーを示します。

     • AllowContactingSource: ソースリポジトリーからのイメージのプルの継続的な試行を許可します。これはデフォルトになります。
     • NeverContactSource: ソースリポジトリーからのイメージのプルの継続的な試行を防ぎます。

     8

     オプション: レジストリー内の namespace を示します。これにより、その namespace で任意のイメージを使用できます。レジストリードメインをソースとして使用する場合、オブジェクトはレジストリーからすべてのリポジトリーに適用されます。

     9

     オプション: レジストリーを示し、そのレジストリー内の任意のイメージを使用できるようにします。レジストリー名を指定すると、ソースレジストリーからミラーレジストリーまでのすべてのリポジトリーにオブジェクトが適用されます。

     10

     イメージ registry.example.com/example/myimage@sha256:…​ をミラー mirror.example.net/image@sha256:.. からプルします。

     11

     ミラー mirror.example.net/image@sha256:… からソースレジストリー namespace のイメージ registry.example.com/example/image@sha256:…​ をプルします。

     12

     ミラーレジストリー example.net/registry-example-com/myimage@sha256:…​ からイメージ registry.example.com/myimage@sha256 をプルします。

   • ImageContentSourcePolicy カスタムリソースを作成し、ソースとミラーを独自のレジストリーとリポジトリーのペアとイメージに置き換えます。

     apiVersion: operator.openshift.io/v1alpha1
     kind: ImageContentSourcePolicy
     metadata:
       name: mirror-ocp
     spec:
       repositoryDigestMirrors:
       - mirrors:
         - mirror.registry.com:443/ocp/release 1
         source: quay.io/openshift-release-dev/ocp-release 2
       - mirrors:
         - mirror.registry.com:443/ocp/release
         source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

     1

     ミラーイメージレジストリーおよびリポジトリーの名前を指定します。

     2

     ミラーリングされるコンテンツが含まれるオンラインレジストリーおよびリポジトリーを指定します。

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

   $ oc create -f registryrepomirror.yaml

   オブジェクトの作成後、Machine Config Operator (MCO) は ImageTagMirrorSet オブジェクトのみのノードをドレインします。MCO は、ImageDigestMirrorSet オブジェクトと ImageContentSourcePolicy オブジェクトのノードをドレインしません。

4. ミラーリングされた設定が適用されていることを確認するには、ノードのいずれかで以下を実行します。

   1. ノードの一覧を表示します。

      $ oc get node

      出力例

      NAME                           STATUS                     ROLES    AGE  VERSION
      ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.30.3
      ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.30.3
      ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.30.3
      ip-10-0-147-35.ec2.internal    Ready                      worker   7m   v1.30.3
      ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.30.3
      ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.30.3

   2. デバッグプロセスを開始し、ノードにアクセスします。

      $ oc debug node/ip-10-0-147-35.ec2.internal

      出力例

      Starting pod/ip-10-0-147-35ec2internal-debug ...
      To use host binaries, run `chroot /host`

   3. ルートディレクトリーを /host に変更します。

      sh-4.2# chroot /host

   4. /etc/containers/registries.conf ファイルをチェックして、変更が行われたことを確認します。

      sh-4.2# cat /etc/containers/registries.conf

      次の出力は、インストール後のミラー設定 CR が適用された registries.conf ファイルを表しています。最後の 2 つのエントリーは、それぞれ digest-only および tag-only とマークされています。

      出力例

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
      short-name-mode = ""
      
      [[registry]]
        prefix = ""
        location = "registry.access.redhat.com/ubi9/ubi-minimal" 1
      
        [[registry.mirror]]
          location = "example.io/example/ubi-minimal" 2
          pull-from-mirror = "digest-only" 3
      
        [[registry.mirror]]
          location = "example.com/example/ubi-minimal"
          pull-from-mirror = "digest-only"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com"
      
        [[registry.mirror]]
          location = "mirror.example.net/registry-example-com"
          pull-from-mirror = "digest-only"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com/example"
      
        [[registry.mirror]]
          location = "mirror.example.net"
          pull-from-mirror = "digest-only"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com/example/myimage"
      
        [[registry.mirror]]
          location = "mirror.example.net/image"
          pull-from-mirror = "digest-only"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com"
      
        [[registry.mirror]]
          location = "mirror.example.com"
          pull-from-mirror = "digest-only"
      
      [[registry]]
        prefix = ""
        location = "registry.example.com/redhat"
      
        [[registry.mirror]]
          location = "mirror.example.com/redhat"
          pull-from-mirror = "digest-only"
      [[registry]]
        prefix = ""
        location = "registry.access.redhat.com/ubi9/ubi-minimal"
        blocked = true 4
      
        [[registry.mirror]]
          location = "example.io/example/ubi-minimal-tag"
          pull-from-mirror = "tag-only" 5

      1

      プルスペックで参照されるリポジトリーを示します。

      2

      そのリポジトリーのミラーを示します。

      3

      ミラーからプルされたイメージがダイジェスト参照イメージであることを示します。

      4

      このリポジトリーに NeverContactSource パラメーターが設定されていることを示します。

      5

      ミラーからプルされたイメージがタグ参照イメージであることを示します。

   5. ソースからノードにイメージをプルし、ミラーによって解決されるかどうかを確認します。

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi9/ubi-minimal@sha256:5cf...