将来のセキュリティを強化する：エージェントベースのインストーラーを使用して Red Hat OpenShift をオフラインインストールする方法

デジタル化が進んだ現在では、信頼性とセキュリティコンプライアンスへの要求がこれまでになく高まっています。インターネット接続が制限されているか、または不利な状態にある組織の場合、標準の Red Hat OpenShift インストールだけでなく、非接続 (またはエアギャップ) インストールも選べることは大きな意味を持ちます。非接続インストールでは、分離されたセキュリティ重視の自己完結環境で OpenShift クラスタを構築して維持できるため、複雑さを増す世界で成功するために欠かせない堅牢なインフラストラクチャを得られるからです。

この記事では、この導入と運用に関するパラダイムのメリットおよび重要な考慮事項について説明します。

インストール方法

まず、セルフマネージド型 OpenShift クラスタで使用できるインストール方法を確認しましょう。

図 1：さまざまなインストール方法

インストーラーでプロビジョニングされるインフラストラクチャ (IPI)

IPI は、最も簡単なインストール方法の一つです。ガイド付きの自動インストール手段を望むユーザーに適しています。IPI では、OpenShift が仮想マシンや物理ハードウェアを含むインフラストラクチャをプロビジョニングします。これは、通常はクラウドプロバイダーに対して使用されますが、オンプレミスのインストールにも使用できます。

Assisted Installer (AI)

Assisted Installer は OpenShift をインストールするための、インタラクティブな Web ベースのツールです。これは、インターネットに接続されたネットワークを持つクラスタに理想的なアプローチです。また、自動化や高度な設定シナリオに使える RESTful API も提供します。AI は Red Hat Advanced Cluster Management にも含まれます。

エージェントベースのインストーラー (ABI)

エージェントベースのインストールは、 Assisted Discovery Agent と Assisted Service を含むブート可能な ISO で構成されており、OpenShift インストーラーのサブコマンドです。OpenShift クラスタのデプロイに必要なすべてのアセットを含むブート可能な ISO イメージを生成します。この中には、利用可能な OpenShift リリースのイメージも含まれます。このアプローチは、エアギャップ環境、非接続環境、または制限付きの環境に最適です。

ユーザーによりプロビジョニングされるインフラストラクチャ (UPI)

UPI は、独自のインフラストラクチャを管理したいユーザー向けの柔軟なインストール方法です。オンプレミス、独自のデータセンター、パブリッククラウドプロバイダーのいずれであっても利用可能です。UPI では、仮想マシン、ストレージ、およびロードバランサーなどのネットワーク・コンポーネントのプロビジョニングをユーザーが実行します。インフラストラクチャのプロビジョニングが完了したら、OpenShift のインストーラーを使用して、任意のインフラストラクチャに OpenShift をデプロイできます。

ホスト型コントロールプレーン (HCP)

OpenShift クラスタは、 スタンドアローン型またはホスト型コントロールプレーンという、2 種類のコントロールプレーン構成を使用してデプロイできます。スタンドアローン構成では、専用の仮想マシンまたは物理マシンを使用して、コントロールプレーンをホストします。OpenShift のホスト型コントロールプレーンを使用すると、ホスティングクラスタ上の Pod としてコントロールプレーンを作成できます。各コントロールプレーンに専用の仮想マシンや物理マシンは必要ありません。詳細については、HCP の公式ドキュメントおよびこちらの記事を参照してください。

非接続インストールとは

インストール方法は、さまざまなシナリオに合わせて選べます。大切なのはユースケースに適した方法を選ぶことです。OpenShift の非接続インストールは、セキュリティのコンプライアンス、制御、および信頼性が最優先され、インターネットの直接接続が制限されているか、望まれない組織や環境にとって重要なソリューションです。セキュリティに重点を置いた、自己完結型の分離ネットワークで OpenShift クラスタを維持管理するために必要なインフラストラクチャを得られます。

制限された非接続ン環境

非接続環境で稼働している OpenShift クラスタは、直接かプロキシ経由かを問わず、インターネットに接続されません。環境をサポートするすべての必須コンテンツをローカルにミラーリングする必要があります。oc ツールセットを実行しているマシンは、直接またはプロキシ経由で間接的に、インターネットにアクセスできる必要があります。また、イメージレジストリーおよび OpenShift API にアクセスできる必要もあります。

図 2: 制限された非接続環境

このブログでは、非接続または制限されたネットワークにおけるエージェントベースのインストール方法に焦点を当てます。インターネットには、bastion ホストを介して接続できるものとします。 

制限されたエアギャップ環境

 RFC 4949 によると、「エアギャップ」とは 2 つのシステムが物理的に接続されておらず、論理接続が自動化されていない状態を指します。データは人の介在によって手動で転送されます。

図 3: 制限されたエアギャップ環境

この場合、直接かプロキシ経由かを問わず、OpenShift クラスタにはインターネット接続がありません。環境をサポートするすべての必須コンテンツがローカルにミラーリングされます。インストールを実行するマシンは、ミラーレジストリーと OpenShift API にアクセスできますが、インターネットにはどのような形式でもアクセスできません。すべてのコンテンツは、USB メモリーや光メディアなどのオフライン手段で配布する必要があります。

bastion ホストにインターネット接続がない場合は、公式ドキュメントの該当セクションを参照して、イメージセットをディスクにミラーリングするための追加手順を実行してから、ディスク上のイメージセットファイルをミラー領域にミラーリングします。詳細はここでは割愛します。

非接続インストールの実行に必要なツール

エージェントベースのインストーラーを使用した実際のインストールについて説明する前に、非接続インストールの実行に必要なツールについて説明します。

Red Hat OpenShift のミラーレジストリー

OpenShift のインストールとその後の製品更新をサポートするために必要なイメージを、Docker v2-2 対応のコンテナミラーレジストリー (Red Hat Quay など) にミラーリングできます。大規模なコンテナレジストリーを利用できない場合は、mirror registry for Red Hat OpenShift を使用できます。これは、OpenShift サブスクリプションに含まれる小規模なコンテナレジストリーです。

OpenShift クライアント (oc) ミラープラグイン

oc-mirror コマンドは、イメージのミラーリングに使用できる OpenShift CLI (oc) プラグインです。元のソースから必要なコンテンツをダウンロードするには、インターネット接続のあるシステムで oc-mirror を実行する必要があります。

ミラーレジストリーの前提条件

• OpenShift サブスクリプション
• Podman 3.4.2 以降と OpenSSL がインストールされている Red Hat Enterprise Linux (RHEL) 8 または 9
• Red Hat Quay サービス用の完全修飾ドメイン名 (DNS サーバーを介して解決される必要があります)
• 2 つ以上の vCPU
• 8 GB の RAM
• OpenShift 4.13 リリースイメージの場合は約 17 GB (OpenShift 4.13 Red Hat Operator イメージも加えた場合は約 358 GB)。各ストリームで 1 TB 以上が推奨されます。

インストール作業

ベースとなる RHEL VM をインストールしたら、次のツールを bastion ホストにダウンロードします。

• Podman 3.4.2 以降

$ sudo dnf install -y podman

• OpenShift クライアント (oc CLI) 

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz
$ tar --extract --file openshift-client-linux.tar.gz
$ chmod +x oc
$ sudo mv oc /usr/local/bin/

• ミラーレジストリー

$ wget https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/mirror-registry/latest/mirror-registry.tar.gz
$ tar --extract --file mirror-registry.tar.gz
$ chmod +x mirror-registry

• oc ミラー

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/oc-mirror.tar.gz
$ tar --extract --file oc-mirror.tar.gz
$ chmod +x oc-mirror
$ sudo mv oc-mirror /usr/local/bin/

ミラーレジストリーのインストール

ミラーレジストリーは、次の単一のコマンドでインストールできます。

$ ./mirror-registry install --quayHostname<hostname fqdn> \
--quayRoot /root/ocpmirror

以下に例を示します。

$ sudo mirror-registry install \
--quayHostname bastion.j9287.dynamic.opentlc.com \
--quayRoot /root/ocpmirror

ミラーレジストリーのインストールに成功すると、次のような出力が返されます。

[...]
INFO[2023-10-31 11:17:28] Quay installed successfully, config data is stored in /root/ocpmirror
INFO[2023-10-31 11:17:28] Quay is available at https://bastion.j9287.dynamic.opentlc.com:8443 with credentials (init, 7HFdq385A9EG0ngVWo4cKeDtxRzp621N)

出力された資格情報と URL を使用してミラーレジストリーにアクセスできることを確認します。

$ podman login -u init -p <password generated by installer> \
https://<hostname fqdn>:8443 \
--tls-verify=false

以下に例を示します。

$ podman login -u init \
-p 7HFdq385A9EG0ngVWo4cKeDtxRzp621N \ https://bastion.j9287.dynamic.opentlc.com:8443 \
--tls-verify=false

ミラーレジストリーにはカスタム CA が付属しているため、以下の変数をエクスポートしてレジストリーに安全にアクセスできます。

$ export SSL_CERT_DIR=/root/ocpmirror/quay-rootCA/
$ podman login -u init \
-p 7HFdq385A9EG0ngVWo4cKeDtxRzp621N \
https://bastion.j9287.dynamic.opentlc.com:8443

OpenShift プルシークレットを  https://console.redhat.com/openshift/downloads からダウンロードして、ダウンロードしたファイルを pull-secret として保存します。

ホームディレクトリから次のコマンドを実行して、レジストリー認証を設定します。

$ cat pull-secret | jq . > pull-secret.json
$ mkdir .docker ; cp pull-secret.json ~/.docker/config.json
$ echo -n 'init:7HFdq385A9EG0ngVWo4cKeDtxRzp621N' | \
base64 -w0

前のコマンドの出力に基づき、ファイルを調整して ~/.docker/config.json にローカルミラー認証を含めます。

"auths": {
 "bastion.j9287.dynamic.opentlc.com:8443": {
   "auth": "aW5pdDo3SEZkcTM3NUE5RUcwbmdWV280Y0tlRHR4UnpwNjIxTg==",
   "email": "[email protected]"
 },

この時点でミラーレジストリーがインストールされ、設定されます。詳細については、 公式ドキュメントを参照してください。

イメージのミラーリング

このセクションでは、 oc mirror OpenShift CLI プラグインを使用して、必要なコンテンツをミラーレジストリーにミラーリングします。

非接続環境では、イメージセットをターゲットのミラーレジストリーに直接ミラーリングできます。

エアギャップ環境では、まずイメージセットをディスクにミラーリングしてから、そのイメージセットファイルをミラー領域にミラーリングする必要があります。

最初に、 ImageSetConfiguration 向けの新しいファイルを作成します。

kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
 registry:
   imageURL: bastion.j9287.dynamic.opentlc.com:8443/mirror/oc-mirror-metadata # Local mirror registry URL
   skipTLS: false
mirror:
 platform:
   channels:
   - name: stable-4.13    # Version of OpenShift to be mirrored
     minVersion: 4.13.17  # Minimum version of OpenShift to be mirrored
     maxVersion: 4.13.18  # Maximum version of OpenShift to be mirrored
     shortestPath: true
     type: ocp
   graph: true   # Useful when updating in disconnected setup with OSUS operator
 operators:
 - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.13 # Operators catalog to mirror
 additionalImages:
 - name: registry.redhat.io/ubi8/ubi:latest
 helm: {}

サンプルファイルはこちらのリポジトリに用意されています。このファイルをニーズに合わせて調整するためのオプション一覧は、 公式ドキュメントを参照してください。
 

この例では、 ImageSetConfiguration ファイルでレジストリー・ストレージ・バックエンド (bastion.j9287.dynamic.opentlc.com:8443/mirror/oc-mirror-metadata) を使用しており、最低バージョン 4.13.17 からチャネルの最新バージョン 4.13.18 までの、すべての OpenShift バージョンが含まれています。このイメージセット設定で oc-mirror を呼び出す際は毎回、stable-4.13 チャネルに最新リリースがないか確認されます。このため、 oc-mirror を定期的に実行することで、 OpenShift イメージの最新リリースを自動的に受け取ることができます。

 ImageSetConfiguration ファイルの準備ができたら、次のコマンドを実行してコンテンツをレジストリーにミラーリングします。ミラーリングプロセスに必要な時間は、設定と接続速度によって異なります。

$ oc mirror --config=imageset-config.yaml \
docker://<hostname fqdn>:8443 

以下に例を示します。

$ oc mirror --config=imageset-config.yaml \  docker://bastion.j9287.dynamic.opentlc.com:8443

オプションのパラメーターである --continue-on-error および --skip-missing  は、エラーを無視する必要がある場合に便利です。

前のコマンドを正常に実行すると、次のような出力が表示されます。

[...]
bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images:4.13.17-x86_64
bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images:4.13.18-x86_64
Writing image mapping to oc-mirror-workspace/results-1698872844/mapping.txt
Writing UpdateService manifests to oc-mirror-workspace/results-1698872844
Writing CatalogSource manifests to oc-mirror-workspace/results-1698872844
Writing ICSP manifests to oc-mirror-workspace/results-1698872844

一部のファイルは oc-mirror によって生成されます。これには updateService が含まれます。

apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
 name: update-service-oc-mirror
spec:
 graphDataImage: bastion.j9287.dynamic.opentlc.com:8443/openshift/graph-image@sha256:a8730004abd6a4c1d02f52d8052a69a014a4e3de677135b2dfe50259fb6b63fa
 releases: bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
 replicas: 2

ImageContentSourcePolicy のファイル：

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
 name: release-0
spec:
 repositoryDigestMirrors:
 - mirrors:
   - bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
   source: quay.io/openshift-release-dev/ocp-release
 - mirrors:
   - bastion.j9287.dynamic.opentlc.com:8443/openshift/release
   source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

最後に  CatalogSource：

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
 name: redhat-operator-index
 namespace: openshift-marketplace
spec:
 image: bastion.j9287.dynamic.opentlc.com:8443/redhat/redhat-operator-index:v4.13
 sourceType: grpc

これらのファイルは、後でインストール用にミラーレジストリーを設定し、Operator と Update Service にローカルレジストリーを使用させる際に必要になります。

 https://:8443に動して、ミラーレジストリーのユーザー・インターフェースにログインすることもできます。

エージェントベースのインストール

ローカルミラーレジストリーをインストールし、設定したら、エージェントベースのインストーラーを使用する OpenShift のインストールを確認できます。執筆時点では、エージェントベースのインストーラーは次のプラットフォームをサポートしています。

• baremetal
• vsphere
• none

エージェントベースのインストールでは、Assisted Discovery Agent と Assisted Service を含むブート可能な ISO を使用します。両方ともクラスタのインストールに必要ですが、後者は 1 つのホスト上でのみ実行されます。 openshift-install agent create image サブコマンドは、ユーザーの入力に基づいて一時的な ISO を生成します。

 install-config.yaml  ファイルでは、プルシークレットを含める必要があります。また、ローカルミラーレジストリーと、ローカルミラーを指す ImageContentSources の、追加の証明書信頼バンドルも必要です。

 agent-config.yaml  ファイルには、必ず rendezvousIP パラメーターを含める必要があります。これは、インストール中に一時的なブートストラップノードになるホストの IP アドレスです。この IP アドレスは、いずれかのノードと一致する必要があります。

Agent Based Installer を使用したインストールの準備手順の一覧は、 こちらのリンクを参照してください。 install-config.yaml と agent-config.yaml のサンプルは、このリポジトリにあります。

ISO の作成

 install-config.yaml ファイルと agent-config.yaml ファイルの両方を調整したら、ISO イメージを作成します。

まず、 nmstate パッケージをインストールします。

$ sudo dnf install /usr/bin/nmstatectl

次に、OpenShift インストーラーをダウンロードします。インストールするクラスタに一致するバージョンの OpenShift インストーラーをダウンロードする必要があります。この記事では Openshift 4.13.17 を使用しているので、まずそれをインストールしてから、クラスタを 4.13.18 に更新します。

$ wget https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/4.13.17/openshift-install-linux.tar.gz
$ tar --extract --file openshift-install-linux.tar.gz
$ chmod +x openshift-install
$ sudo mv openshift-install /usr/local/bin/

最後に ISO を作成します。

$ openshift-install agent create image --dir <directory>

次のような出力になります。

INFO Configuration has 3 master replicas and 3 worker replicas
INFO The rendezvous host IP (node0 IP) is 192.168.94.21
INFO Extracting base ISO from release payload    
INFO Base ISO obtained from release and cached at [/root/.cache/agent/image_cache/coreos-x86_64.iso]
INFO Consuming Install Config from target directory
INFO Consuming Agent Config from target directory

プラットフォームに応じて、コントロールプレーンおよびコンピュートノード用のノード (BareMetal または VM) を準備する必要があります。クラスタのすべてのノードについて、生成された ISO イメージからブートしていることを確認します。

DNS レコードの作成

DNS では、2 つの静的 IP アドレスに対して DNS レコードを作成する必要があります。各レコードで、<cluster_name> はクラスタ名を、<base_domain> はクラスタのインストール時に指定したクラスタベースのドメインを表します。完全な DNS レコードは次の形式を取ります。<component>.<cluster_name>.<base_domain>

API VIP - api.<cluster_name>.<base_domain>

Ingress VIP - *.apps.<cluster_name>.<base_domain>

OpenShift クラスタの作成

仮想メディア、ブート可能な USB、DVD を含む、各クラスタホストで ISO イメージをブートします。

作成した ISO イメージからブートするようにノードを設定します。すべてのノードを ISO イメージからブートしたら、次のコマンドを使用してインストールを監視できます。

$ openshift-install agent wait-for bootstrap-complete \
--dir <directory> --log-level=debug
[...]
INFO Cluster is ready for install                
INFO Cluster validation: All hosts in the cluster are ready to install.
INFO Preparing cluster for installation
INFO Cluster installation in progress
INFO Bootstrap configMap status is complete      
INFO cluster bootstrap is complete

ブートストラッププロセスが完了したら、次のコマンドを実行して進行状況を監視できます。

$ openshift-install agent wait-for install-complete \
--dir <directory> --log-level=debug
[...]
INFO Cluster is installed                        
INFO Install complete!                           
INFO To access the cluster as the system:admin user when using 'oc', run
INFO     export KUBECONFIG=/root/auth/kubeconfig 
INFO Access the OpenShift web-console here: https://console-openshift-console.apps.j9287.dynamic.opentlc.com
INFO Login to the console with user: "kubeadmin", and password: "HR377-xxxxx-yyyyy-ynxGC"

インストール完了のメッセージが表示されたら、 oc コマンドを使用してクラスタにログインし、OpenShift クラスタのバージョンを確認できます。

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.17   True        False         11m     Cluster version is 4.13.17

エージェントベースのインストーラーの詳細については、 OpenShift の公式ドキュメントを参照してください。

 ImageContentSourcePolicy を参照して、OpenShift クラスタがローカルのミラーレジストリーからイメージを受信していることを確認できます。

$ oc get imagecontentsourcepolicy
NAME             AGE
image-policy-0   18h
image-policy-1   18h
$ oc describe imagecontentsourcepolicy image-policy-0 |grep -A4 Spec:
Spec:
 Repository Digest Mirrors:
   Mirrors:
     bastion.j9287.dynamic.opentlc.com:8443/openshift/release
   Source:  quay.io/openshift-release-dev/ocp-v4.0-art-dev
$ oc describe imagecontentsourcepolicy image-policy-1 |grep -A4 Spec:
Spec:
 Repository Digest Mirrors:
   Mirrors:
     bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
   Source:  quay.io/openshift-release-dev/ocp-release

クラスタがインターネットに接続されていないため、いくつかの追加設定を実行して、すべてのデフォルトのカタログソースを削除する必要があります。次のコマンドを実行して、OperatorHub リソースにパッチを適用し、デフォルトの CatalogSources を無効にします。

$ oc get catsrc -A
NAMESPACE               NAME                  DISPLAY               TYPE   PUBLISHER   AGE
openshift-marketplace   certified-operators   Certified Operators   grpc   Red Hat     32m
openshift-marketplace   community-operators   Community Operators   grpc   Red Hat     32m
openshift-marketplace   redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     32m
openshift-marketplace   redhat-operators      Red Hat Operators     grpc   Red Hat     32m
$ oc patch OperatorHub cluster --type json \
-p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
operatorhub.config.openshift.io/cluster patched
$ oc get catsrc -A
No resources found

上記の「イメージのミラーリング」セクションの CatalogSource.yaml を適用して、ローカルのミラーレジストリーを指す新しい CatalogSource リソースを作成します。

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
 name: redhat-operator-index
 namespace: openshift-marketplace
spec:
 image: bastion.j9287.dynamic.opentlc.com:8443/redhat/redhat-operator-index:v4.13
 sourceType: grpc
 
$ oc apply -f ./oc-mirror-workspace/results-1698872844/

$ oc apply -f ./oc-mirror-workspace/results-1698872844/release-signatures/

適用後は、先ほど行った検証手順を再実行します。

$ oc get po -n openshift-marketplace
NAME                                    READY   STATUS    RESTARTS   AGE
marketplace-operator-7bc7549555-4ckdm   1/1     Running   0          48m
redhat-operator-index-t4cgd             1/1     Running   0          75s

$ oc get catsrc -A
NAMESPACE               NAME                    DISPLAY   TYPE   PUBLISHER   AGE
openshift-marketplace   redhat-operator-index             grpc               82s

この時点で、以下が完了しています。

• エージェントベースのインストール方法による、新しい OpenShift クラスタのインストール
• インターネットではなくローカルのミラーレジストリーから、インストールイメージをプル
• ローカルのミラーレジストリーを使用するための、Operator Hub の設定

非接続環境における OpenShift の更新

記事の前半では、OpenShift 4.13.17 と 4.13.18 の 2 つのバージョンが格納されているローカルレジストリーをミラーリングしました ( ImageSetConfiguration  ファイルの内容を参照)。インターネットにアクセスできるクラスタの場合、パブリック API の背後にあるホストサービスとして OpenShift Update Service (OSUS) を使用することで、OTA (over-the-air) 更新を利用できますが、この例では非接続モードに焦点を当てています。OSUS については、こちらの「クラスタ管理者向けガイド：OpenShift の更新方法」で詳しく説明しています。

非接続/エアギャップ環境で OpenShift を更新するには、OpenShift Update Service Operator (OSUS) を使用しない方法と、OpenShift Update Service Operator (OSUS) を使用する方法の 2 つがあります。

OpenShift Update Service Operator (OSUS) を使用しない場合

まず、OpenShift クラスタを 4.13.17 から 4.13.18 にアップデートする最も簡単な方法を見てみましょう。利用可能でインターネット接続が有効なノートパソコンまたはシステムから、 oc コマンドを使用して、以下のコマンドを実行します。 

$ export OCP_RELEASE_VERSION=4.13.18
$ export ARCHITECTURE=x86_64
$ oc adm release info -o 'jsonpath={.digest}{"\n"}' quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_VERSION}-${ARCHITECTURE}
sha256:d0fd9d3ab8690605f816c879d74f4e6d6d9f72982f63a3e0ef3e027ecc512e1c

直前のコマンドの出力を使用して、OpenShift クラスタにアクセスできる bastion ノードから OpenShift クラスタをアップグレードします。

$ oc adm upgrade --allow-explicit-upgrade \
--to-image quay.io/openshift-release-dev/ocp-release@sha256:d0fd9d3ab8690605f816c879d74f4e6d6d9f72982f63a3e0ef3e027ecc512e1c
Requested update to 4.13.18

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.17   True        True          78m     Working towards 4.13.18: 106 of 843 done (12% complete), waiting up to 40 minutes on etcd, kube-apiserver

$ oc get clusterversion
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.18   True        False         5m25s   Cluster version is 4.13.18

OpenShift の詳しい更新方法については、 公式ドキュメントを参照してください。

OpenShift Update Service Operator (OSUS) を使用する方法

OpenShift Update Service Operator (OSUS) を使用するには、保護されたレジストリーへのアクセスを設定する必要があります (インストール時に使用されたレジストリーと異なる場合)。今回の例ではローカルのミラーレジストリーを使用しているため、設定は不要です。

また、レジストリーがインストール時に使用されたものと異なる場合は、ミラーレジストリーにアクセスするために、 グローバル・クラスタ・プルシークレットを更新する必要もあります。今回の例ではローカルのミラーレジストリーを使用しているため、設定は不要です。

OSUS を使用するには、まず Operator Hub から OSUS Operator をインストールする必要があります。

次に、OpenShift Update Service 用のグラフデータ・コンテナイメージを作成します。この記事の例では作成は不要です。イメージのミラーリングに oc mirror を使用し、ミラーリング中に ImageSetConfiguration ファイルで graph: true を指定しているからです。

完了したら、OSUS アプリケーションをインストールし、ローカルの OpenShift Update Service を使用するようにクラスタを設定します。 UpdateService.yaml を使用して、必要な設定を適用します。以下に例を示します。

apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
 name: update-service-oc-mirror
spec:
 graphDataImage: bastion.j9287.dynamic.opentlc.com:8443/openshift/graph-image@sha256:a8730004abd6a4c1d02f52d8052a69a014a4e3de677135b2dfe50259fb6b63fa
 releases: bastion.j9287.dynamic.opentlc.com:8443/openshift/release-images
 replicas: 2

OSUS アプリケーションがインストールされたら、次のコマンドを実行して、CVO (Cluster Version Operator) がインターネットではなくローカルにインストールされた OSUS からグラフデータをプルするように設定します。

$ export NAMESPACE=openshift-update-service
$ export NAME=update-service-oc-mirror
$ export POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"
$ export PATCH="{\"spec\":{\"upstream\":\"${POLICY_ENGINE_GRAPH_URI}\"}}"
$ oc patch clusterversion version -p $PATCH --type merge

 oc adm upgrade コマンドの実行中に証明書エラーが返された場合は、クラスタ全体のプロキシが有効になっていること、および更新サーバーを信頼するように CAを設定していることを確認してください。

最後に、前のセクションで説明した更新手順を実行します。OpenShift Update Service Operator の詳細については、 関連ドキュメントを参照してください。

終わりに

この記事では、ミラーレジストリーや oc mirror などのツールを使用して、非接続/エアギャップ・インストール時にローカルリポジトリを設定する方法について詳しく解説しました。この知識があれば、OpenShift 管理者は、ローカルにミラーリングされたイメージを使用して OpenShift クラスタをインストールするだけでなく、アップグレードと更新を行うこともできます。