手順

1. Web コンソールから、Administration → Cluster Settings をクリックし、Details タブの内容を確認します。

2. 本番クラスターの場合は、チャネル が、stable-4.7 など、更新するバージョンの正しいチャネルに設定されていることを確認します。

   重要

   実稼働クラスターの場合、stable-* または fast-* チャネルにサブスクライブする必要があります。

   • Update Status が Updates Available ではない場合、クラスターを更新することはできません。
   • Select Channel は、クラスターが実行されているか、または更新されるクラスターのバージョンを示します。

3. 更新するバージョンを選択し、Save をクリックします。

   入力チャネルの Update Status が Update to <product-version> in progress 切り替わり、Operator およびノードの進捗バーを監視して、クラスター更新の進捗を確認できます。

   注記

   バージョン 4.y から 4.(y+1) などの次のマイナーバージョンにクラスターを更新する場合、新たな機能に依存するワークロードをデプロイする前にノードがアップグレードされていることを確認することが推奨されます。更新されていないワーカーノードを持つプールは Cluster Settings ページに表示されます。

4. 更新が完了し、Cluster Version Operator が利用可能な更新を更新したら、追加の更新が現在のチャネルで利用可能かどうかを確認します。

   • 更新が利用可能な場合は、更新ができなくなるまで、現在のチャネルでの更新を継続します。
   • 利用可能な更新がない場合は、Channel を次のマイナーバージョンの stable-* または fast-* チャネルに切り替え、そのチャネルで必要なバージョンに更新します。

   必要なバージョンに達するまで、いくつかの中間更新を実行する必要がある場合があります。

手順

1. Administration → Cluster Settings に移動し、version をクリックします。

2. YAML タブをクリックし、upstream パラメーター値を編集します。

   出力例

     ...
     spec:
       clusterID: db93436d-7b05-42cc-b856-43e11ad2d31a
       upstream: '<update-server-url>' 1
     ...

   1

   <update-server-url> 変数は、更新サーバーの URL を指定します。

   デフォルトの upstream は https://api.openshift.com/api/upgrades_info/v1/graph です。

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

手順

1. クラスターが利用可能であることを確認します。

   $ oc get clusterversion

   出力例

   NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
   version   4.6.9     True        False         158m    Cluster version is 4.6.9

2. 現在の更新チャネル情報を確認し、チャネルが stable-4.7 に設定されていることを確認します。

   $ oc get clusterversion -o json|jq ".items[0].spec"

   出力例

   {
     "channel": "stable-4.7",
     "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff"
   }

   重要

   実稼働クラスターの場合、stable-* または fast-* チャネルにサブスクライブする必要があります。

3. 利用可能な更新を確認し、適用する必要のある更新のバージョン番号をメモします。

   $ oc adm upgrade

   出力例

   Cluster version is 4.1.0
   
   Updates:
   
   VERSION IMAGE
   4.1.2   quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b

4. 更新を適用します。

   • 最新バージョンに更新するには、以下を実行します。

     $ oc adm upgrade --to-latest=true 1

   • 特定のバージョンに更新するには、以下を実行します。

     $ oc adm upgrade --to=<version> 1

     1 1

     <version> は、直前のコマンドの出力から得られる更新バージョンです。

5. クラスターバージョン Operator を確認します。

   $ oc get clusterversion -o json|jq ".items[0].spec"

   出力例

   {
     "channel": "stable-4.7",
     "clusterID": "990f7ab8-109b-4c95-8480-2bd1deec55ff",
     "desiredUpdate": {
       "force": false,
       "image": "quay.io/openshift-release-dev/ocp-release@sha256:9c5f0df8b192a0d7b46cd5f6a4da2289c155fd5302dec7954f8f06c878160b8b",
       "version": "4.7.0" 1
     }
   }

   1

   desiredUpdate スタンザの version 番号が指定した値と一致する場合、更新は進行中です。

6. クラスターバージョン履歴で、更新のステータスをモニターします。すべてのオブジェクトの更新が終了するまでに時間がかかる可能性があります。

   $ oc get clusterversion -o json|jq ".items[0].status.history"

   出力例

   [
     {
       "completionTime": null,
       "image": "quay.io/openshift-release-dev/ocp-release@sha256:b8fa13e09d869089fc5957c32b02b7d3792a0b6f36693432acc0409615ab23b7",
       "startedTime": "2021-01-28T20:30:50Z",
       "state": "Partial",
       "verified": true,
       "version": "4.7.0"
     },
     {
       "completionTime": "2021-01-28T20:30:50Z",
       "image": "quay.io/openshift-release-dev/ocp-release@sha256:b8fa13e09d869089fc5957c32b02b7d3792a0b6f36693432acc0409615ab23b7",
       "startedTime": "2021-01-28T17:38:10Z",
       "state": "Completed",
       "verified": false,
       "version": "4.7.0"
     }
   ]

   履歴には、クラスターに適用された最新バージョンの一覧が含まれます。この値は、CVO が更新を適用する際に更新されます。この一覧は日付順に表示され、最新の更新は一覧の先頭に表示されます。履歴の更新には、ロールアウトが完了した場合には Completed と表示され、更新が失敗したか、または完了しなかった場合には Partial と表示されます。

7. 更新が完了したら、クラスターのバージョンが新たなバージョンに更新されていることを確認できます。

   $ oc get clusterversion

   出力例

   NAME      VERSION     AVAILABLE   PROGRESSING   SINCE     STATUS
   version   4.7.0       True        False         2m        Cluster version is 4.7.0

8. バージョン 4.y から 4.(y+1) などの次のマイナーバージョンにクラスターをアップグレードする場合、新たな機能に依存するワークロードをデプロイする前にノードがアップグレードされていることを確認することが推奨されます。

   $ oc get nodes

   出力例

   NAME                           STATUS   ROLES    AGE   VERSION
   ip-10-0-168-251.ec2.internal   Ready    master   82m   v1.20.0
   ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.20.0
   ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.20.0
   ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.20.0
   ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.20.0
   ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.20.0

1. ワーカープールに基づいて MCP を作成します。各 MCP のノード数は、各 MCP のメンテナンス期間や予約容量 (つまりクラスターで利用可能な追加のワーカーノード) など、いくつかの要素に依存します。

   注記

   MCP の maxUnavailable 設定を変更して、任意の時点で更新できるパーセンテージまたはマシン数を指定できます。デフォルトでは 1 回です。

2. ノードセレクターをカスタム MCP に追加します。残りのクラスターと同時に更新しない各ノードに、一致するラベルをノードに追加します。このラベルは、ノードを MCP に関連付けます。

   注記

   ノードからデフォルトのワーカーラベルを削除しないでください。クラスターで適切に機能するには、ノードにロールラベルが 必要 です。

3. 更新プロセスの一部として更新しない MCP を一時停止します。

   注記

   MCP を一時停止すると、kube-apiserver-to-kubelet-signer 自動 CA 証明書のローテーションも一時停止します。新しい CA 証明書は、インストール日と古い証明書の 292 日で生成され、インストール日から 365 日は削除されます。次の自動 CA 証明書のローテーションまでの所要時間については、Understanding CA cert auto updates in Red Hat OpenShift 4 を参照してください。CA 証明書のローテーションが行われると、プールが一時停止されていないことを確認します。MCP が一時停止すると、証明書のローテーションが発生しません。これにより、クラスターは劣化し、複数の oc コマンドで失敗の原因となります。これには、oc debug、oc logs、oc exec、および oc attach が含まれますが、これに限定されません。

4. クラスターの更新を実行します。更新プロセスでは、コントロールプレーンノード (別名マスターノード) を含む、一時停止されない MCP を更新します。
5. 更新されたノードでアプリケーションをテストし、想定通りに機能していることを確認します。
6. 残りの MCP を 1 つずつ一時停止解除し、すべてのワーカーノードが更新されるまでそれらのノードでアプリケーションをテストします。MCP の一時停止を解除すると、その MCP に関連付けられたノードの更新プロセスが開始されます。Administration → Cluster settings をクリックして、Web コンソールから更新の進捗を確認できます。または、oc get machineconfigpools CLI コマンドを使用します。
7. 必要に応じて、更新されたノードからカスタムラベルを削除し、カスタム MCP を削除します。

1. ワーカーノードから MCP を作成します。

   1. クラスターのワーカーノードを一覧表示します。

      $ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}{.metadata.name}{"\n"}{end}' nodes

      出力例

      ci-ln-pwnll6b-f76d1-s8t9n-worker-a-s75z4
      ci-ln-pwnll6b-f76d1-s8t9n-worker-b-dglj2
      ci-ln-pwnll6b-f76d1-s8t9n-worker-c-lldbm

   2. 遅延させるノードの場合は、カスタムラベルをノードに追加します。

      $ oc label node <node name> node-role.kubernetes.io/<custom-label>=

      以下に例を示します。

      $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary=

      出力例

      node/ci-ln-gtrwm8t-f76d1-spbl7-worker-a-xk76k labeled

   3. 新規 MCP を作成します。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: workerpool-canary 1
      spec:
        machineConfigSelector:
          matchExpressions: 2
            - {
               key: machineconfiguration.openshift.io/role,
               operator: In,
               values: [worker,workerpool-canary]
              }
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/workerpool-canary: "" 3

      1

      MCP の名前を指定します。

      2

      worker およびカスタム MCP 名を指定します。

      3

      このプールで必要なノードに追加したカスタムラベルを指定します。

      $ oc create -f <file_name>

      出力例

      machineconfigpool.machineconfiguration.openshift.io/workerpool-canary created

   4. クラスター内の MCP およびそれらの現在の状態を表示します。

      $ oc get machineconfigpool

      出力例

      NAME              CONFIG                                                        UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
      master            rendered-master-b0bb90c4921860f2a5d8a2f8137c1867              True      False      False      3              3                   3                     0                      97m
      workerpool-canary rendered-workerpool-canary-87ba3dec1ad78cb6aecebf7fbb476a36   True      False      False      1              1                   1                     0                      2m42s
      worker            rendered-worker-87ba3dec1ad78cb6aecebf7fbb476a36              True      False      False      2              2                   2                     0                      97m

      新規マシン設定プールの workerpool-canary が作成され、カスタムラベルが追加されたノード数がマシン数に表示されます。ワーカー MCP マシン数は同じ数で縮小されます。マシン数の更新に数分かかることがあります。この例では、1 つのノードが worker MCP から workerpool-canary MCP に移動しました。

1. 一時停止する MCP にパッチを適用します。

   $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":true}}' --type=merge

   以下に例を示します。

   $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":true}}' --type=merge

   出力例

   machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

1. 一時停止を解除する MCP にパッチを適用します。

   $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":false}}' --type=merge

   以下に例を示します。

   $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":false}}' --type=merge

   出力例

   machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

   oc get machineconfigpools コマンドを使用して更新の進捗を確認できます。

2. 更新されたノードでアプリケーションをテストし、想定通りに機能していることを確認します。
3. 一時停止した他の MCP の一時停止を解除すると、1 回目でアプリケーションが機能することを確認します。

1. ノードからカスタムラベルを削除します。

   $ oc label node <node_name> node-role.kubernetes.io/<custom-label>-

   以下に例を示します。

   $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary-

   出力例

   node/ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz labeled

   MCO は、ノードを元の MCP に戻し、ノードを MCP 設定に調整します。

2. クラスター内の MCP およびそれらの現在の状態を表示します。

   $oc get mcp

   NAME                CONFIG                                                   UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master              rendered-master-1203f157d053fd987c7cbd91e3fbc0ed         True      False      False      3              3                   3                     0                      61m
   workerpool-canary   rendered-mcp-noupdate-5ad4791166c468f3a35cd16e734c9028   True      False      False      0              0                   0                     0                      21m
   worker              rendered-worker-5ad4791166c468f3a35cd16e734c9028         True      False      False      3              3                   3                     0                      61m

   ノードはカスタム MCP から削除され、元の MCP に戻ります。マシン数の更新に数分かかることがあります。この例では、1 つのノードが削除された workerpool-canary MCP から 'worker'MCP に移動しました。

3. 必要に応じて、カスタム MCP を削除します。

   $ oc delete mcp <mcp_name>

手順

1. Web コンソールから、Administration → Cluster Settings をクリックし、Details タブの内容を確認します。

2. 本番クラスターの場合は、チャネル が、stable-4.7 など、更新するバージョンの正しいチャネルに設定されていることを確認します。

   重要

   実稼働クラスターの場合、stable-* または fast-* チャネルにサブスクライブする必要があります。

   • Update Status が Updates Available ではない場合、クラスターを更新することはできません。
   • Select Channel は、クラスターが実行されているか、または更新されるクラスターのバージョンを示します。

3. 更新するバージョンを選択し、Save をクリックします。

   入力チャネルの Update Status が Update to <product-version> in progress 切り替わり、Operator およびノードの進捗バーを監視して、クラスター更新の進捗を確認できます。

   注記

   バージョン 4.y から 4.(y+1) などの次のマイナーバージョンにクラスターを更新する場合、新たな機能に依存するワークロードをデプロイする前にノードがアップグレードされていることを確認することが推奨されます。更新されていないワーカーノードを持つプールは Cluster Settings ページに表示されます。

4. 更新が完了し、Cluster Version Operator が利用可能な更新を更新したら、追加の更新が現在のチャネルで利用可能かどうかを確認します。

   • 更新が利用可能な場合は、更新ができなくなるまで、現在のチャネルでの更新を継続します。
   • 利用可能な更新がない場合は、Channel を次のマイナーバージョンの stable-* または fast-* チャネルに切り替え、そのチャネルで必要なバージョンに更新します。

   必要なバージョンに達するまで、いくつかの中間更新を実行する必要がある場合があります。

   注記

   Red Hat Enterprise Linux (RHEL) ワーカーマシンを含むクラスターを更新する場合、それらのワーカーは、更新プロセス時に一時的に使用できなくなります。クラスターの更新の終了において各 RHEL マシンがのステートが NotReady になる際に、更新 Playbook を各 RHEL マシンに対して実行する必要があります。

手順

1. ホストで firewalld を停止し、無効にします。

   # systemctl disable --now firewalld.service

   注記

   デフォルトでは、最小インストールオプションを持つベース OS RHEL により、firewalld スパッドが有効になります。ホストで firewalld サービスを有効にすると、ワーカーで OpenShift Container Platform ログにアクセスできなくなります。ワーカーの OpenShift Container Platform ログへのアクセスを継続する場合は、firewalld を後で有効にしないでください。

2. OpenShift Container Platform 4.7 で必要なリポジトリーを有効にします。

   1. Ansible Playbook を実行するマシンで、必要なリポジトリーを更新します。

      # subscription-manager repos --disable=rhel-7-server-ose-4.6-rpms \
                                   --enable=rhel-7-server-ansible-2.9-rpms \
                                   --enable=rhel-7-server-ose-4.7-rpms

   2. Ansible Playbook を実行するマシンで、openshift-ansible を含む必要なパッケージを更新します。

      # yum update openshift-ansible openshift-clients

   3. 各 RHEL コンピュートノードで、必要なリポジトリーを更新します。

      # subscription-manager repos --disable=rhel-7-server-ose-4.6-rpms \
                                   --enable=rhel-7-server-ose-4.7-rpms  \
                                   --enable=rhel-7-fast-datapath-rpms   \
                                   --enable=rhel-7-server-optional-rpms

3. RHEL ワーカーマシンを更新します。

   1. 現在のノードステータスを確認し、更新する RHEL ワーカーを判別します。

      # oc get node

      出力例

      NAME                        STATUS                        ROLES    AGE    VERSION
      mycluster-control-plane-0   Ready                         master   145m   v1.20.0
      mycluster-control-plane-1   Ready                         master   145m   v1.20.0
      mycluster-control-plane-2   Ready                         master   145m   v1.20.0
      mycluster-rhel7-0           NotReady,SchedulingDisabled   worker   98m    v1.14.6+97c81d00e
      mycluster-rhel7-1           Ready                         worker   98m    v1.14.6+97c81d00e
      mycluster-rhel7-2           Ready                         worker   98m    v1.14.6+97c81d00e
      mycluster-rhel7-3           Ready                         worker   98m    v1.14.6+97c81d00e

      ステータスが NotReady,SchedulingDisabled のマシンに留意してください。

   2. /<path>/inventory/hosts で Ansible インベントリーファイルを確認し、以下の例に示されるように、ステータスが NotReady,SchedulingDisabled のマシンのみが [workers] セクションに一覧表示されるようにそのコンテンツを更新します。

      [all:vars]
      ansible_user=root
      #ansible_become=True
      
      openshift_kubeconfig_path="~/.kube/config"
      
      [workers]
      mycluster-rhel7-0.example.com

   3. openshift-ansible ディレクトリーに移動します。

      $ cd /usr/share/ansible/openshift-ansible

   4. upgrade Playbook を実行します。

      $ ansible-playbook -i /<path>/inventory/hosts playbooks/upgrade.yml 1

      1

      <path> については、作成した Ansible インベントリーファイルへのパスを指定します。

      注記

      upgrade Playbook は OpenShift Container Platform パッケージのみをアップグレードします。オペレーティングシステムパッケージは更新されません。

4. 直前の手順で実行したプロセスに従って、クラスター内の各 RHEL ワーカーマシンを更新します。

5. すべてのワーカーを更新したら、すべてのクラスターノードが新規バージョンに更新されていることを確認します。

   # oc get node

   出力例

   NAME                        STATUS                        ROLES    AGE    VERSION
   mycluster-control-plane-0   Ready                         master   145m   v1.20.0
   mycluster-control-plane-1   Ready                         master   145m   v1.20.0
   mycluster-control-plane-2   Ready                         master   145m   v1.20.0
   mycluster-rhel7-0           NotReady,SchedulingDisabled   worker   98m    v1.20.0
   mycluster-rhel7-1           Ready                         worker   98m    v1.20.0
   mycluster-rhel7-2           Ready                         worker   98m    v1.20.0
   mycluster-rhel7-3           Ready                         worker   98m    v1.20.0

6. オプション: upgrade Playbook で更新されていないオペレーティングシステムパッケージを更新します。4.7 にないパッケージを更新するには、以下のコマンドを使用します。

   # yum update

   注記

   4.7 のインストール時に使用したものと同じ RPM リポジトリーを使用している場合は、RPM パッケージを除外する必要はありません。

1. registry.redhat.io プルシークレットを Red Hat OpenShift Cluster Manager からダウンロードし、.json ファイルに保存します。

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

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

   1

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

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

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

   1

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

4. ファイルを ~/.docker/config.json または $XDG_RUNTIME_DIR/containers/auth.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"
       }
     }
   }

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

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

   1

   <mirror_registry> については、レジストリードメイン名と、ミラーレジストリーがコンテンツを提供するために使用するポートをオプションで指定します。例: registry.example.com または registry.example.com:8443

   2

   <credentials> については、ミラーレジストリーの 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. Red Hat OpenShift Container Platform Upgrade Graph visualizer および update planner を使用して、あるバージョンから別のバージョンへの更新を計画します。OpenShift Upgrade 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. ミラーリングするリポジトリーの名前をエクスポートします。

      $ PRODUCT_REPO='openshift-release-dev'

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

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

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

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

      注記

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

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

      $ RELEASE_NAME="ocp-release"

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

   7. サーバーのアーキテクチャーのタイプをエクスポートします (例: x86_64)。

      $ ARCHITECTURE=<server_architecture>

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

      $ 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}

     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)。

   • ローカルコンテナーレジストリーとクラスターがミラーホストに接続されている場合、リリースイメージをローカルレジストリーに直接プッシュし、以下のコマンドを使用して設定マップをクラスターに適用します。

     $ 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 オプションが含まれる場合は、イメージ署名の検証用に設定マップを作成しません。

手順

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 \
     docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
     docker://example.io/example/ubi-minimal

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

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

3. ImageContentSourcePolicy ファイル (例: registryrepomirror.yaml) を作成し、ソースとミラーを固有のレジストリー、およびリポジトリーのペアとイメージのものに置き換えます。

   apiVersion: operator.openshift.io/v1alpha1
   kind: ImageContentSourcePolicy
   metadata:
     name: ubi8repo
   spec:
     repositoryDigestMirrors:
     - mirrors:
       - example.io/example/ubi-minimal 1
       source: registry.access.redhat.com/ubi8/ubi-minimal 2
     - mirrors:
       - example.com/example/ubi-minimal
       source: registry.access.redhat.com/ubi8/ubi-minimal
     - mirrors:
       - mirror.example.com/redhat
       source: registry.redhat.io/openshift4 3

   1

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

   2

   ミラーリングされているコンテンツが含まれるレジストリーおよびリポジトリーを示します。

   3

   レジストリー内の namespace を、その namespace の任意のイメージを使用するように設定できます。レジストリードメインをソースとして使用する場合、ImageContentSourcePolicy リソースはレジストリーからすべてのリポジトリーに適用されます。

4. 新しい ImageContentSourcePolicy オブジェクトを作成します。

   $ oc create -f registryrepomirror.yaml

   ImageContentSourcePolicy オブジェクトが作成されると、新しい設定が各ノードにデプロイされ、クラスターはソースリポジトリーへの要求のためにミラーリングされたリポジトリーの使用を開始します。

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

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

      $ oc get node

      出力例

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

      変更が適用されているため、各ワーカーノードのスケジューリングが無効にされていることを確認できます。

   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. ノードのファイルにアクセスします。

      sh-4.2# chroot /host

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

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

      出力例

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
      [[registry]]
        location = "registry.access.redhat.com/ubi8/"
        insecure = false
        blocked = false
        mirror-by-digest-only = true
        prefix = ""
      
        [[registry.mirror]]
          location = "example.io/example/ubi8-minimal"
          insecure = false
      
        [[registry.mirror]]
          location = "example.com/example/ubi8-minimal"
          insecure = false

   5. ソースからノードにイメージダイジェストをプルし、ミラーによって解決されているかどうかを確認します。ImageContentSourcePolicy オブジェクトはイメージダイジェストのみをサポートし、イメージタグはサポートしません。

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

手順

1. <local_registry>, <pull_spec>, and <pull_secret_file> の値を指定して、以下のコマンドを実行します。

   $ oc adm catalog mirror <local_registry>/<pull_spec> <local_registry> -a <pull_secret_file> --icsp-scope=registry

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

   <local_registry>

   非接続クラスター (例: local.registry:5000) 用に設定したローカルレジストリーです。

   <pull_spec>

   非接続レジストリーで設定されるプル仕様です (例: redhat/redhat-operator-index:v4.7)。

   <pull_secret_file>

   .json ファイル形式の registry.redhat.io プルシークレットです。プルシークレットは、Red Hat Open Shift Cluster Manager から ダウンロードできます。

   oc adm catalog mirror コマンドは、/redhat-operator-index-manifests ディレクトリーを作成し、imageContentSourcePolicy.yaml、catalogSource.yaml、および mapping.txt ファイルを生成します。

2. 新しい ImageContentSourcePolicy リソースをクラスターに適用します。

   $ oc apply -f imageContentSourcePolicy.yaml