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

アプリケーションの実行

Red Hat build of MicroShift 4.18

MicroShift でのアプリケーションの実行

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、MicroShift でアプリケーションを実行する方法を詳しく説明します。

第1章 Kustomize マニフェストを使用したアプリケーションのデプロイ
リンクのコピー

kustomize 設定管理ツールをアプリケーションマニフェストとともに使用して、アプリケーションをデプロイできます。以下の手順を読み、Kustomize が MicroShift でどのように機能するかを示す例を確認してください。

1.1. Kustomize とマニフェストによるアプリケーションのデプロイの仕組み
リンクのコピー

kustomize 設定管理ツールは MicroShift と統合されています。Kustomize と OpenShift CLI (oc) を一緒に使用して、アプリケーションマニフェストにカスタマイズを適用し、そのアプリケーションを MicroShift クラスターにデプロイできます。

  • kustomization.yaml ファイルは、リソースとカスタマイズの仕様です。
  • Kustomize は、kustomization.yaml ファイルを使用してアプリケーションなどのリソースをロードします。その後、必要な変更をそのアプリケーションマニフェストに適用し、変更をオーバーレイしたマニフェストのコピーを作成します。
  • オーバーレイを含むマニフェストのコピーを使用すると、アプリケーションの元の設定ファイルがそのまま維持されると同時に、アプリケーションのイテレーションやカスタマイズを効率的にデプロイできるようになります。
  • その後、oc コマンドを使用してアプリケーションを MicroShift クラスターにデプロイできます。
注記

システムの起動ごとに、MicroShift は delete サブディレクトリーにあるマニフェストを削除し、マニフェストディレクトリーにあるマニフェストファイルをクラスターに適用します。

1.1.1. MicroShift によるマニフェストの使用方法
リンクのコピー

MicroShift は起動するたびに、次のマニフェストディレクトリーで Kustomize マニフェストファイルを検索します。

  • /etc/microshift/manifests
  • /etc/microshift/manifests.d/*
  • /usr/lib/microshift/
  • /usr/lib/microshift/manifests.d/*

検索対象のディレクトリーに次のファイルタイプのいずれかが存在する場合、MicroShift は kubectl apply -k コマンドと同等のコマンドを自動的に実行し、マニフェストをクラスターに適用します。

  • kustomization.yaml
  • kustomization.yml
  • Kustomization

この複数のディレクトリーからの自動読み込みにより、異なるワークロードを互いに独立して実行できるという柔軟性を確保しつつ MicroShift ワークロードを管理できるようになります。

Expand
表1.1 MicroShift マニフェストディレクトリー
場所目的

/etc/microshift/manifests

設定管理システムまたは開発用の読み取り/書き込みの場所。

/etc/microshift/manifests.d/*

設定管理システムまたは開発用の読み取り/書き込みの場所。

/usr/lib/microshift/manifests

OSTree ベースのシステムに設定マニフェストを埋め込むための読み取り専用の場所。

/usr/lib/microshift/manifestsd./*

OSTree ベースのシステムに設定マニフェストを埋め込むための読み取り専用の場所。

1.2. マニフェストパスリストのオーバーライド
リンクのコピー

新しい単一パスを使用するか、複数のファイルに新しい glob パターンを使用することで、デフォルトのマニフェストパスのリストをオーバーライドできます。マニフェストパスをカスタマイズするには、次の手順を使用します。

手順

  1. 独自の値を挿入し、以下のコマンドのいずれかを実行して、デフォルトパスのリストを上書きします。

    1. 単一パスの設定ファイルで manifests.kustomizePaths を <"/opt/alternate/path"> に設定します。

    2. glob パターンの設定ファイルで kustomizePaths を ,"/opt/alternative/path.d/*". に設定します。 

      manifests:
    kustomizePaths:
        - <location>
      1
      1
      "/opt/alternative/path" を使用して各位置エントリーを正確なパスに設定するか、"/opt/alternative/path.d/*" を使用して glob パターンを設定します。

  2. マニフェストの読み込みを無効にするには、設定オプションを空のリストに設定します。 

    manifests:
    kustomizePaths: []
    注記

    設定ファイルはデフォルトを完全にオーバーライドします。kustomizePaths 値が設定されている場合は、設定ファイル内の値のみが使用されます。値を空のリストに設定すると、マニフェストの読み込みが無効になります。

1.3. マニフェストの使用例
リンクのコピー

この例では、/etc/microshift/manifests ディレクトリー内の kustomize マニフェストを使用した BusyBox コンテナーの自動デプロイを示します。

手順

  1. 次のコマンドを実行して、BusyBox マニフェストファイルを作成します。

    1. ディレクトリーの場所を定義します。 

      $ MANIFEST_DIR=/etc/microshift/manifests

    2. ディレクトリーを作成します。 

      $ sudo mkdir -p ${MANIFEST_DIR}

    3. YAML ファイルをディレクトリーに配置します。 

      sudo tee ${MANIFEST_DIR}/busybox.yaml &>/dev/null <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: busybox
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: busybox-deployment
spec:
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - name: busybox
        image: BUSYBOX_IMAGE
        command: [ "/bin/sh", "-c", "while true ; do date; sleep 3600; done;" ]
EOF

  2. 次に、以下のコマンドを実行して kustomize マニフェストファイルを作成します。

    1. YAML ファイルをディレクトリーに配置します。 

      sudo tee ${MANIFEST_DIR}/kustomization.yaml &>/dev/null <<EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: busybox
resources:
  - busybox.yaml
images:
  - name: BUSYBOX_IMAGE
    newName: busybox:1.35
EOF

  3. 次のコマンドを実行して MicroShift を再起動し、マニフェストを適用します。 

    $ sudo systemctl restart microshift

  4. 次のコマンドを実行して、マニフェストを適用し、busybox Pod を起動します。 

    $ oc get pods -n busybox

第2章 Kustomize マニフェストリソースの削除または更新
リンクのコピー

MicroShift は、次の状況でのマニフェストリソースの削除をサポートします。

  • マニフェストの削除: クラスターからリソースを完全に削除する必要がある場合は、マニフェストを削除できます。
  • マニフェストのアップグレード: アプリケーションのアップグレード中に、一部のリソースを削除し、データの保存用に他のリソースは保持する必要がある場合があります。

新しいマニフェストを作成するときに、マニフェストリソースの削除を使用して古いオブジェクトを削除または更新し、競合や問題が発生しないようにできます。

重要

delete サブディレクトリーに配置されたマニフェストファイルは自動的に削除されないため、手動で削除する必要があります。delete サブディレクトリーに配置されたマニフェストファイルにリストされているリソースのみが削除されます。

2.1. マニフェストの削除の仕組み
リンクのコピー

デフォルトでは、MicroShift はマニフェストパス内の delete サブディレクトリーで削除マニフェストを検索します。ユーザーがこれらのサブディレクトリーにマニフェストを配置すると、システムの起動時に MicroShift によりマニフェストが削除されます。MicroShift でマニフェストの削除がどのように機能するかを理解するには、以下を参照してください。

  1. システムが起動するたびに、マニフェストを適用する前に、MicroShift は設定されたマニフェストディレクトリー内の次の delete サブディレクトリーをスキャンして、削除する必要があるマニフェストを識別します。

    • /usr/lib/microshift/manifests/delete
    • /usr/lib/microshift/manifests.d/delete/*
    • /etc/microshift/manifests/delete
    • /etc/microshift/manifests.d/delete/*
  2. MicroShift は、kubectl delete --ignore-not-found -k コマンドと同等の機能を実行して、delete ディレクトリーにあるマニフェストで定義されているリソースを削除します。

2.2. マニフェストリソースの削除のユースケース
リンクのコピー

次のセクションでは、マニフェストリソースの削除が使用されるユースケースを説明します。

2.2.1. RPM システムのマニフェストの削除
リンクのコピー

RPM システムのデータ削除シナリオで次の手順を使用して、マニフェストで定義されたリソースを完全に削除します。

手順

  1. delete サブディレクトリーに配置する必要があるマニフェストを特定します。

  2. 次のコマンドを実行して、マニフェストを配置する delete サブディレクトリーを作成します。 

    $ sudo mkdir -p <path_of_delete_directory>
    1
    1
    <path_of_delete_directory> は、有効なディレクトリーパスのいずれか (/etc/microshift/manifests.d/delete、/etc/microshift/manifests/delete/、/usr/lib/microshift/manifests.d/delete、または /usr/lib/microshift/manifests/delete) に置き換えます。

  3. 次のコマンドを実行して、マニフェストファイルを、設定されたマニフェストディレクトリーの下の delete サブディレクトリーの 1 つに移動します。 

    $ [sudo] mv <path_of_manifests> <path_of_delete_directory>

    ここで、<path_of_manifests> は削除するマニフェストのパスを指定します (例: /etc/microshift/manifests.d/010-SOME-MANIFEST)。<path_of_delete_directory> は有効なディレクトリーパスのいずれか (/etc/microshift/manifests.d/delete、/etc/microshift/manifests/delete、/usr/lib/microshift/manifests.d/delete、または /usr/lib/microshift/manifests/delete) を指定します。

  4. 次のコマンドを実行して MicroShift を再起動します。 

    $ sudo systemctl restart microshift
  5. MicroShift は、マニフェストファイルが delete サブディレクトリーに配置された後、リソースを検出して削除します。

2.2.2. OSTree システムのマニフェストの削除
リンクのコピー

マニフェストで定義されたリソースを完全に削除するには、次の手順に従います。

重要

OSTree インストールの場合、delete サブディレクトリーは読み取り専用になります。

手順

  1. delete サブディレクトリーに配置する必要があるマニフェストを特定します。
  2. マニフェストを RPM にパッケージ化します。マニフェストを RPM にパッケージ化する手順は、アプリケーションの RPM パッケージの構築 を参照してください。
  3. パッケージ化された RPM をブループリントファイルに追加して、正しい場所にインストールします。ブループリントに RPM を追加する手順は、ブループリントへのアプリケーション RPM の追加 を参照してください。

2.2.3. RPM システムのマニフェストのアップグレード
リンクのコピー

データの保存に他のリソースを保持しながら一部のリソースを削除するには、次の手順に従います。

手順

  1. 更新が必要なマニフェストを特定します。
  2. マニフェストディレクトリーに適用する新しいマニフェストを作成します。
  3. リソース削除用の新しいマニフェストを作成します。これらのマニフェストに spec を含める必要はありません。例を使用して新しいマニフェストを作成するには、マニフェストの使用例 を参照してください。
  4. 「RPM システムのマニフェストの削除」の手順に従って、delete サブディレクトリーを作成し、リソース削除用に作成されたマニフェストをこのパスに配置します。

2.2.4. OSTree システムのマニフェストのアップグレード
リンクのコピー

データの保存に他のリソースを保持しながら一部のリソースを削除するには、次の手順に従います。

重要

OSTree システムの場合、削除 サブディレクトリーは読み取り専用です。

手順

  1. 更新が必要なマニフェストを特定します。
  2. マニフェストディレクトリーに適用する新しいマニフェストを作成します。例を使用して新しいマニフェストを作成するには、マニフェストの使用例 を参照してください。
  3. delete サブディレクトリーに配置するリソース削除用の新しいマニフェストを作成します。
  4. マニフェストを削除するには、「OSTree システムのマニフェストの削除」の手順を使用します。

第3章 RHEL for Edge イメージにアプリケーションを埋め込むオプション
リンクのコピー

マイクロサービスベースのワークロードとアプリケーションを Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージに埋め込んで、MicroShift クラスターで実行できます。埋め込みアプリケーションをエッジデバイスに直接インストールして、切断された環境またはオフライン環境で実行できます。

3.1. アプリケーション RPM の rpm-ostree イメージへの追加
リンクのコピー

API、コンテナーイメージ、マニフェストなどのデプロイメント用の設定ファイルを含むアプリケーションがある場合は、アプリケーション RPM を構築できます。その後、RPM を RHEL for Edge システムイメージに追加できます。

以下は、完全に自己完結型のオペレーティングシステムイメージにアプリケーションまたはワークロードを埋め込む手順の概要です。

  • アプリケーションマニフェストを含む独自の RPM をビルドします。
  • Red Hat build of MicroShift のインストールに使用したブループリントに RPM を追加します。
  • ワークロードコンテナーイメージを同じブループリントに追加します。
  • 起動可能な ISO を作成します。

RHEL for Edge イメージへのアプリケーションの準備および埋め込みに関する段階的なチュートリアルでは、以下のチュートリアルを使用します。

3.2. オフラインで使用するためにイメージへのアプリケーションマニフェストの追加
リンクのコピー

マニフェストなどのデプロイメント用のファイルがいくつか含まれる単純なアプリケーションがある場合は、それらのマニフェストを RHEL for Edge システムイメージに直接追加できます。

例は、次の RHEL for Edge ドキュメントの「カスタムファイルブループリントのカスタマイズの作成」セクションを参照してください。

3.3. オフラインで使用するためのアプリケーションの埋め込み
リンクのコピー

アプリケーションに複数のファイルが含まれている場合は、オフラインで使用できるようにアプリケーションを埋め込むことができます。以下の手順を参照してください。

第4章 オフラインで使用するためのアプリケーションの埋め込み
リンクのコピー

マイクロサービスベースのワークロードとアプリケーションを Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージに埋め込むことができます。埋め込みを行うと、エアギャップ環境、非接続環境、またはオフライン環境で Red Hat build of MicroShift クラスターを実行できます。

4.1. オフラインで使用するためのワークロードコンテナーイメージの埋め込み
リンクのコピー

ネットワーク接続がないエッジのデバイスにコンテナーイメージを埋め込むには、新しいコンテナーを作成し、ISO をマウントして、コンテンツをファイルシステムにコピーする必要があります。

前提条件

  • ホストへの root アクセス権限がある。
  • アプリケーション RPM がブループリントに追加されている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、マニフェストをレンダリングし、すべてのコンテナーイメージ参照を抽出し、アプリケーションイメージをブループリントコンテナーソースに変換します。 

    $ oc kustomize ~/manifests | grep "image:" | grep -oE '[^ ]+$' | while read line; do echo -e "[[containers]]\nsource = \"${line}\"\n"; done >><my_blueprint>.toml

  2. 次のコマンドを実行して、更新されたブループリントを Image Builder にプッシュします。 

    $ sudo composer-cli blueprints push <my_blueprint>.toml

  3. ワークロードコンテナーがプライベートリポジトリーにある場合は、Image Builder に必要なプルシークレットを提供する必要があります。

    1. /etc/osbuild-worker/osbuild-worker.toml 設定ファイルの [containers] セクションで auth_file_path を設定して、プルシークレットを指すようにします。

    2. 必要に応じて以下のように、プルシークレットのディレクトリーおよびファイルを作成します。

      ディレクトリーとファイルの例

      [containers]
auth_file_path = "/<path>/pull-secret.json"
      1

      1
      イメージのコピーおよび取得には、以前に設定したカスタムの場所を使用します。

  4. 以下のコマンドを実行し、コンテナーイメージをビルドします。 

    $ sudo composer-cli compose start-ostree <my_blueprint> edge-commit
  5. ビルドの完了待ち、イメージのエクスポート、rpm-ostree リポジトリーへの統合、ブータブル ISO の作成など、任意の rpm-ostree イメージフローに進みます。

第5章 MicroShift アプリケーションの埋め込みのチュートリアル
リンクのコピー

次のチュートリアルでは、さまざまな環境の MicroShift クラスターで使用するために、RHEL for Edge イメージにアプリケーションを埋め込む方法の詳細な例を示します。

5.1. アプリケーション RPM の埋め込みのチュートリアル
リンクのコピー

次のチュートリアルでは、MicroShift のインストール手順を確認し、さらにアプリケーションを埋め込むためのワークフローを説明します。Red Hat Enterprise Linux for Edge (RHEL for Edge) や MicroShift などの rpm-ostree システムにすでに慣れている場合は、そのまま手順に進んでください。

5.1.1. インストールワークフローの再確認
リンクのコピー

アプリケーションを埋め込むには、MicroShift を RHEL for Edge イメージに埋め込む場合と同様のワークフローが必要です。

  • 次の画像は、RPM、コンテナー、ファイルなどのシステムアーティファクトをブループリントに追加し、それらをイメージコンポーザーで使用して ostree コミットを作成する方法を示しています。
  • ostree コミットは、ISO パスまたはリポジトリーパスのいずれかを使用してエッジデバイスに到達できます。
  • ISO パスは非接続環境で使用できます。一方、リポジトリーパスはネットワークが通常接続されている場所でよく使用されます。

MicroShift の埋め込みワークフロー

468 RHbM install workflow 1023 1

次の手順を再確認すると、アプリケーションの埋め込みに必要な手順を理解するのに役立ちます。

  1. MicroShift を RHEL for Edge に埋め込むために、MicroShift リポジトリーを Image builder に追加しました。
  2. MicroShift の追加など、必要なすべての RPM、コンテナーイメージ、ファイル、およびカスタマイズを宣言するブループリントを作成しました。
  3. ブループリントを Image builder に追加し、Image Builder CLI ツール (composer-cli) を使用してビルドを実行しました。この手順では、コンテナーイメージの作成に使用される rpm-ostree コミットを作成しました。このイメージには RHEL for Edge が含まれていました。
  4. インストーラーブループリントを Image builder に追加して、起動元の rpm-ostree イメージ (ISO) を作成しました。このビルドには、RHEL for Edge と MicroShift の両方が含まれていました。
  5. MicroShift が埋め込まれた ISO をダウンロードし、使用できるように準備し、プロビジョニングして、エッジデバイスにインストールしました。

5.1.2. アプリケーション RPM の埋め込みワークフロー
リンクのコピー

Image builder の要件を満たすビルドホストを設定したら、マニフェストのディレクトリーの形式でアプリケーションをイメージに追加できます。これらの手順の後、アプリケーションまたはワークロードを新しい ISO に埋め込む最も簡単な方法は、マニフェストを含む独自の RPM を作成します。アプリケーションの RPM には、デプロイメントを記述するすべての設定ファイルが含まれています。

次の「アプリケーションの埋め込みワークフロー」の画像は、Kubernetes アプリケーションマニフェストと RPM 仕様ファイルが単一のアプリケーション RPM ビルドにどのように組み合わされるかを示しています。このビルドは、MicroShift を ostree コミットに埋め込むワークフローで使用する RPM アーティファクトになります。

アプリケーションの埋め込みワークフロー

468 RHbM install workflow 1023 2

以下の手順では、rpmbuild ツールを使用して、仕様ファイルとローカルリポジトリーを作成します。この仕様ファイルにより、パッケージのビルド方法を定義し、アプリケーションマニフェストを RPM パッケージ内の正しい場所に移動して、MicroShift が取得できるようにします。この RPM パッケージは ISO に埋め込まれます。

5.1.3. アプリケーション RPM の作成準備
リンクのコピー

独自の RPM を構築するには、rpmbuild ツールなどの任意のツールを選択し、ホームディレクトリーで RPM ビルドツリーを初期化します。以下に手順の例を示します。RPM が Image Builder にアクセスできる限り、任意の方法を使用してアプリケーション RPM を構築できます。

前提条件

  • Image Builder のシステム要件を満たす Red Hat Enterprise Linux for Edge (RHEL for Edge) 9.4 ビルドホストをセットアップしている。
  • ホストへの root アクセス権限がある。

手順

  1. rpmbuild ツールをインストールし、以下のコマンドを実行してその yum リポジトリーを作成します。 

    $ sudo dnf install rpmdevtools rpmlint yum-utils createrepo

  2. 次のコマンドを実行して、RPM パッケージの構築に必要なファイルツリーを作成します。 

    $ rpmdev-setuptree

検証

  • 次のコマンドを実行して、ディレクトリーを一覧表示して作成を確認します。 

    $ ls ~/rpmbuild/

    出力例

    BUILD RPMS SOURCES SPECS SRPMS

5.1.4. アプリケーションマニフェストの RPM パッケージの構築
リンクのコピー

独自の RPM を構築するには、アプリケーションマニフェストを RPM パッケージに追加する仕様ファイルを作成する必要があります。以下に手順の例を示します。イメージ構築に必要なアプリケーション RPM およびその他の要素が Image Builder にアクセスできる限り、任意の方法を使用できます。

前提条件

  • Image Builder のシステム要件を満たす Red Hat Enterprise Linux for Edge (RHEL for Edge) 9.4 ビルドホストをセットアップしている。
  • ホストへの root アクセス権限がある。
  • RPM パッケージの構築に必要なファイルツリーが作成されている。

手順

  1. ~/rpmbuild/SPECS ディレクトリーに、次のテンプレートを使用して <application_workload_manifests.spec> などのファイルを作成します。

    仕様ファイルの例

    Name: <application_workload_manifests>
Version: 0.0.1
Release: 1%{?dist}
Summary: Adds workload manifests to microshift
BuildArch: noarch
License: GPL
Source0: %{name}-%{version}.tar.gz
#Requires: microshift
%description
Adds workload manifests to microshift
%prep
%autosetup
%install
    1 
    
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/%{_prefix}/lib/microshift/manifests
cp -pr ~/manifests $RPM_BUILD_ROOT/%{_prefix}/lib/microshift/
%clean
rm -rf $RPM_BUILD_ROOT

%files
%{_prefix}/lib/microshift/manifests/**
%changelog
* <DDD MM DD YYYY username@domain - V major.minor.patch>
- <your_change_log_comment>

    1
    %install セクションは、RPM パッケージ内にターゲットディレクトリー /usr/lib/microshift/manifests/ を作成し、ソースホームディレクトリー ~/manifests からマニフェストをコピーします。
    重要

    必要な YAML ファイルはすべて、ソースホームディレクトリー ~/manifests に置かれている必要があります (kustomize を使用している場合は kustomize.yaml ファイルも含まれます)。

  2. 以下のコマンドを実行して、~/rpmbuild/RPMS ディレクトリーに RPM パッケージをビルドします。 

    $ rpmbuild -bb ~/rpmbuild/SPECS/<application_workload_manifests.spec>

5.1.5. ブループリントへのアプリケーション RPM の追加
リンクのコピー

アプリケーション RPM をブループリントに追加するには、Image builder が ISO の作成に使用できるローカルリポジトリーを作成する必要があります。この手順では、ワークロードに必要なコンテナーイメージをネットワーク経由でプルできます。

前提条件

  • ホストへの root アクセス権限がある。
  • ワークロードまたはアプリケーション RPM が ~/rpmbuild/RPMS ディレクトリーにある。

手順

  1. 次のコマンドを実行して、ローカル RPM リポジトリーを作成します。 

    $ createrepo ~/rpmbuild/RPMS/

  2. 次のコマンドを実行して、Image Builder に RPM リポジトリーへのアクセス権限を付与します。 

    $ sudo chmod a+rx ~
    注記

    イメージ構築に必要なすべてのファイルにアクセスするために必要なパーミッションが Image Builder に割り当てられている必要があります。そうでないと、構築を続行できません。

  3. 次のテンプレートを使用して、ブループリントファイル repo-local-rpmbuild.toml を作成します。 

    id = "local-rpm-build"
name = "RPMs build locally"
type = "yum-baseurl"
url = "file://<path>/rpmbuild/RPMS"
    1 
    
check_gpg = false
check_ssl = false
system = false
    1
    選択したロケーションを作成するパスの一部を指定します。後のコマンドでこのパスを使用して、リポジトリーを設定し、RPM をコピーします。

  4. 次のコマンドを実行して、Image Builder のソースとしてリポジトリーを追加します。 

    $ sudo composer-cli sources add repo-local-rpmbuild.toml

  5. 以下の行を追加して、RPM をブループリントに追加します。 

    …
[[packages]]
name = "<application_workload_manifests>"
    1 
    
version = "*"
…
    1
    ワークロードの名前をここに追加します。

  6. 次のコマンドを実行して、更新されたブループリントを Image Builder にプッシュします。 

    $ sudo composer-cli blueprints push repo-local-rpmbuild.toml

  7. この時点で、Image Builder を実行して ISO を作成するか、オフラインで使用するためにコンテナーイメージを埋め込むことができます。

    1. ISO を作成するには、次のコマンドを実行して Image Builder を起動します。 

      $ sudo composer-cli compose start-ostree repo-local-rpmbuild edge-commit

このシナリオでは、起動時にエッジデバイスによってネットワーク経由でコンテナーイメージがプルされます。

第6章 Greenboot ワークロードヘルスチェックスクリプト
リンクのコピー

Greenboot ヘルスチェックスクリプトは、エッジデバイスを使用していて、直接サービスを利用できないか、限りがある場合に役立ちます。ヘルスチェックスクリプトを作成して、ワークロードとアプリケーションの正常性を評価できます。これらの追加のヘルスチェックスクリプトは、ソフトウェアの問題チェックと自動システムロールバックの有用なコンポーネントです。

MicroShift ヘルスチェックスクリプトは、microshift-greenboot RPM に含まれています。実行中のワークロードに基づいて、独自のヘルスチェックスクリプトを作成することもできます。たとえば、サービスの起動を確認するスクリプトを作成するなどが可能です。

6.1. ワークロードヘルスチェックスクリプトの仕組み
リンクのコピー

このチュートリアルで説明するワークロードまたはアプリケーションのヘルスチェックスクリプトは、/usr/share/microshift/functions/greenboot.sh ファイルで利用可能な MicroShift ヘルスチェック機能を使用します。これにより、MicroShift コアサービスにすでに実装されている手順を再利用できます。

このスクリプトは、ワークロードの基本機能が期待どおりに動作しているかどうかのチェックを実行することから始まります。スクリプトを正常に実行するには、以下を実行します。

  • root ユーザーアカウントからスクリプトを実行します。
  • MicroShift サービスを有効にします。

ヘルスチェックは以下のアクションを実行します。

  • wait_for 関数における現在のブートサイクルの待機時間でのタイムアウトを取得します。
  • namespace_images_downloaded 関数を呼び出して、Pod イメージが利用可能になるまで待機します。
  • namespace_pods_ready 関数を呼び出して、Pod が準備状態になるまで待機します。
  • namespace_pods_not_restarting 関数を呼び出して、Pod が再起動していないことを確認します。
注記

Pod を再起動すると、クラッシュループを示している可能性があります。

6.2. 同梱の greenboot ヘルスチェック
リンクのコピー

ヘルスチェックスクリプトは、/usr/lib/greenboot/check (RPM-OSTree システムの読み取り専用ディレクトリー) で利用できます。以下のヘルスチェックは greenboot-default-health-checks フレームワークに含まれています。

  • リポジトリー URL がまだ DNS 解決可能かどうかを確認します。

    このスクリプトは /usr/lib/greenboot/check/required.d/01_repository_dns_check.sh の下にあり、リポジトリー URL への DNS クエリーを引き続き利用できるようにします。

  • 更新プラットフォームにまだ到達可能かどうかを確認します。

    このスクリプトは /usr/lib/greenboot/check/wanted.d/01_update_platform_check.sh の下にあり、/etc/ostree/remotes.d で定義された更新プラットフォームに接続して 2XX または 3XX HTTP コードを取得しようとします。

  • 現在の起動がハードウェアウォッチドッグによってトリガーされたかどうかを確認します。

    このスクリプトは /usr/lib/greenboot/check/required.d/02_watchdog.sh の下にあり、現在の起動が watchdog-triggered かどうかを確認します。

    • ウォッチドッグによってトリガーされた再起動が猶予期間内に発生した場合、現在の起動は赤色でマークされます。Greenboot は、以前のデプロイメントへのロールバックをトリガーしません。
    • ウォッチドッグによってトリガーされた再起動が猶予期間後に発生した場合、現在の起動は赤色でマークされません。Greenboot は、以前のデプロイメントへのロールバックをトリガーしません。
    • デフォルトで 24 時間の猶予期間が有効になっています。この猶予期間を無効にするには、/etc/greenboot/greenboot.conf の Greenboot_WATCHDOG_CHECK_ENABLED を false に変更するか、/etc/greenboot/greenboot.conf の Greenboot_WATCHDOG_GRACE_PERIOD=number_of_hours 変数値を変更して設定できます。

6.3. アプリケーションのヘルスチェックスクリプトの作成方法
リンクのコピー

このドキュメントの例を使用して、選択したテキストエディターでワークロードまたはアプリケーションのヘルスチェックスクリプトを作成できます。スクリプトを /etc/greenboot/check/required.d ディレクトリーに保存します。/etc/greenboot/check/required.d ディレクトリー内のスクリプトがエラーで終了すると、greenboot はシステムを修復するために再起動をトリガーします。

注記

/etc/greenboot/check/required.d ディレクトリー内のスクリプトは、エラーを出して終了すると再起動をトリガーします。

ヘルスチェックロジックでチェック後の手順が必要な場合は、追加のスクリプトを作成して、関連する greenboot ディレクトリーに保存することもできます。以下に例を示します。

  • ブートの成功が宣言された後に実行するシェルスクリプトを /etc/greenboot/green.d に配置することもできます。
  • ブートの失敗が宣言された後に実行するシェルスクリプトを /etc/greenboot/red.d に配置できます。たとえば、再起動する前にシステムを修復する手順がある場合は、ユースケース用のスクリプトを作成し、/etc/greenboot/red.d ディレクトリーに配置できます。

6.3.1. ワークロードヘルスチェックスクリプトの例
リンクのコピー

次の例では、MicroShift ヘルスチェックスクリプトをテンプレートとして使用します。この例は、アプリケーションの基本的なヘルスチェックスクリプトを作成するためのガイドとして、提供されたライブラリーで使用できます。

6.3.1.1. ヘルスチェックスクリプト作成の基本要件
リンクのコピー
  • ワークロードがインストールされている。
  • root アクセスがある。
6.3.1.2. および機能要件の例
リンクのコピー

次のヘルスチェックスクリプトの例から始めることができます。ユースケースに合わせて変更します。ワークロードヘルスチェックスクリプトでは、最低でも、以下の手順を完了する必要があります。

  • 環境変数を設定します。
  • ユーザーワークロード namespace を定義します。
  • 予想される Pod 数を一覧表示します。
重要

アプリケーションの名前接頭辞を選択して、アプリケーションが 40_microshift_running_check.sh スクリプトの後に実行されるようにします。このスクリプトは、コアサービスむけに Red Hat build of MicroShift ヘルスチェックの手順を実装します。

ワークロードヘルスチェックスクリプトの例

# #!/bin/bash
set -e

SCRIPT_NAME=$(basename $0)
PODS_NS_LIST=(<user_workload_namespace1> <user_workload_namespace2>)
PODS_CT_LIST=(<user_workload_namespace1_pod_count> <user_workload_namespace2_pod_count>)
# Update these two lines with at least one namespace and the pod counts that are specific to your workloads. Use the kubernetes <namespace> where your workload is deployed.

# Set greenboot to read and execute the workload health check functions library.
source /usr/share/microshift/functions/greenboot.sh

# Set the exit handler to log the exit status.
trap 'script_exit' EXIT

# Set the script exit handler to log a `FAILURE` or `FINISHED` message depending on the exit status of the last command.
# args: None
# return: None
function script_exit() {
    [ "$?" -ne 0 ] && status=FAILURE || status=FINISHED
    echo $status
}

# Set the system to automatically stop the script if the user running it is not 'root'.
if [ $(id -u) -ne 0 ] ; then
    echo "The '${SCRIPT_NAME}' script must be run with the 'root' user privileges"
    exit 1
fi

echo "STARTED"

# Set the script to stop without reporting an error if the MicroShift service is not running.
if [ $(systemctl is-enabled microshift.service 2>/dev/null) != "enabled" ] ; then
    echo "MicroShift service is not enabled. Exiting..."
    exit 0
fi

# Set the wait timeout for the current check based on the boot counter.
WAIT_TIMEOUT_SECS=$(get_wait_timeout)

# Set the script to wait for the pod images to be downloaded.
for i in ${!PODS_NS_LIST[@]}; do
    CHECK_PODS_NS=${PODS_NS_LIST[$i]}

    echo "Waiting ${WAIT_TIMEOUT_SECS}s for pod image(s) from the ${CHECK_PODS_NS} namespace to be downloaded"
    wait_for ${WAIT_TIMEOUT_SECS} namespace_images_downloaded
done

# Set the script to wait for pods to enter ready state.
for i in ${!PODS_NS_LIST[@]}; do
    CHECK_PODS_NS=${PODS_NS_LIST[$i]}
    CHECK_PODS_CT=${PODS_CT_LIST[$i]}

    echo "Waiting ${WAIT_TIMEOUT_SECS}s for ${CHECK_PODS_CT} pod(s) from the ${CHECK_PODS_NS} namespace to be in 'Ready' state"
    wait_for ${WAIT_TIMEOUT_SECS} namespace_pods_ready
done

# Verify that pods are not restarting by running, which could indicate a crash loop.
for i in ${!PODS_NS_LIST[@]}; do
    CHECK_PODS_NS=${PODS_NS_LIST[$i]}

    echo "Checking pod restart count in the ${CHECK_PODS_NS} namespace"
    namespace_pods_not_restarting ${CHECK_PODS_NS}
done

6.4. ワークロードヘルスチェックスクリプトのテスト
リンクのコピー

前提条件

  • root アクセスがある。
  • ワークロードがインストールされている。
  • ワークロードのヘルスチェックスクリプトを作成している。
  • MicroShift サービスが有効である。
注記

greenboot ワークロードヘルスチェックスクリプトの出力は、ホストシステムのタイプによって異なります。参考のために出力例を記載します。

手順

  1. Greenboot がヘルスチェックスクリプトファイルを実行していることをテストするには、次のコマンドを実行してホストを再起動します。 

    $ sudo reboot

  2. 次のコマンドを実行して、Greenboot ヘルスチェックの出力を調べます。 

    $ sudo journalctl -o cat -u greenboot-healthcheck.service
    注記

    MicroShift コアサービスのヘルスチェックは、ワークロードのヘルスチェックの前に実行されます。

    RHEL for Edge システムの出力例

    GRUB boot variables:
boot_success=0
boot_indeterminate=0
Greenboot variables:
GREENBOOT_WATCHDOG_CHECK_ENABLED=true
MICROSHIFT_WAIT_TIMEOUT_SEC=600
System installation type:
ostree
System installation status:
* rhel 19619bd269094510180c845c44d0944fd9aa15925376f249c4d680a3355e51ae.0
    Version: 9.4
    origin refspec: edge:rhel-9.4-microshift-4.18

    Image Mode for RHEL の出力例

    GRUB boot variables:
boot_success=0
Greenboot variables:
GREENBOOT_WATCHDOG_CHECK_ENABLED=true
MICROSHIFT_WAIT_TIMEOUT_SEC=600
System installation type:
bootc
System installation status:
bootcHost

    RPM システムの出力例

    GRUB boot variables:
boot_success=1
boot_indeterminate=0
Greenboot variables:
GREENBOOT_WATCHDOG_CHECK_ENABLED=true
System installation type:
RPM
System installation status:
Not an ostree / bootc system

第7章 GitOps コントローラーによるアプリケーション管理の自動化
リンクのコピー

Argo CD for MicroShift を使用した GitOps は、Red Hat OpenShift GitOps Operator から派生した軽量なオプションで選べるアドオンコントローラーです。GitOps for MicroShift は、Argo CD のコマンドラインインターフェイス (CLI) を使用して、宣言型 GitOps エンジンとして機能する GitOps コントローラーと対話します。クラスターと開発ライフサイクル全体にわたって、Kubernetes ベースのインフラストラクチャーとアプリケーションを一貫して設定およびデプロイできます。

7.1. GitOps エージェントの機能
リンクのコピー

MicroShift で GitOps with Argo CD エージェントを使用すると、次の原則を活用できます。

  • アプリケーションライフサイクル管理を実装します。

    • Git リポジトリーでのソフトウェアの開発およびメンテナンスのコアとなる原則を使用して、クラスターとアプリケーション設定ファイルを作成および管理します。
    • 単一のリポジトリーを更新でき、GitOps によって新しいアプリケーションのデプロイメントまたは既存のアプリケーションへの更新が自動化されます。
    • たとえば、1,000 台のエッジデバイスがあり、それぞれが MicroShift とローカル GitOps エージェントを使用している場合、中央の Git リポジトリーで 1 回変更するだけで、1,000 台すべてのデバイスでアプリケーションを簡単に追加または更新できます。
  • この Git リポジトリーには、指定した環境に必要なインフラストラクチャーの宣言的な説明が含まれ、説明した状態に環境を一致させるための自動プロセスが含まれます。
  • また、Git リポジトリーを変更の監査証跡として使用して、設定変更を実装するプルリクエストのマージのレビューや承認など、Git フローに基づいたプロセスを作成することもできます。

7.2. MicroShift で GitOps アプリケーションの作成
リンクのコピー

MicroShift サービスでアプリケーションをデプロイおよび管理するためのカスタム YAML 設定を作成できます。GitOps アプリケーションを実行するために必要なパッケージをインストールするには、「RPM パッケージからの GitOps Argo CD マニフェストのインストール」に従ってください。

前提条件

  • microshift-gitops パッケージがインストールされている。
  • Argo CD Pod が openshift-gitops namespace で実行されている。

手順

  1. YAML ファイルを作成し、アプリケーションのカスタマイズされた設定を追加します。

    spring-petclinic アプリケーションの YAML の例

    kind: AppProject
apiVersion: argoproj.io/v1alpha1
metadata:
  name: default
  namespace: openshift-gitops
spec:
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'
  destinations:
  - namespace: '*'
    server: '*'
  sourceRepos:
  - '*'
---
kind: Application
apiVersion: argoproj.io/v1alpha1
metadata:
  name: spring-petclinic
  namespace: openshift-gitops
spec:
  destination:
    namespace: spring-petclinic
    server: https://kubernetes.default.svc
  project: default
  source:
    directory:
      recurse: true
    path: app
    repoURL: https://github.com/siamaksade/openshift-gitops-getting-started
  syncPolicy:
    automated: {}
    syncOptions:
    - CreateNamespace=true
    - ServerSideApply=true

  2. YAML ファイルで定義されたアプリケーションをデプロイするには、次のコマンドを実行します。 

    $ oc apply -f <my_app.yaml>
    1
    1
    <my_app.yaml> をアプリケーション YAML の名前に置き換えます。

検証

  • アプリケーションがデプロイされ、同期されていることを確認するには、次のコマンドを実行します。 

    $ oc get applications -A

    アプリケーションが Healthy ステータスを表示するまで数分かかる場合があります。

    出力例

    NAMESPACE          NAME               SYNC STATUS   HEALTH STATUS
openshift-gitops   spring-petclinic   Synced        Healthy

7.3. MicroShift で GitOps エージェントを使用する際の制限
リンクのコピー

Argo CD for MicroShift を使用した GitOps と Red Hat OpenShift GitOps Operator には、以下のような違いがあります。

  • gitops-operator コンポーネントは MicroShift では使用されません。
  • MicroShift のリソース使用量を少なく維持するために、Argo CD Web コンソールは使用できません。Argo CD CLI を使用できます。
  • MicroShift はシングルノードであるため、マルチクラスターはサポートされません。MicroShift の各インスタンスは、ローカル GitOps エージェントとペアになっています。
  • oc adm must-gather コマンドは MicroShift では使用できません。

7.4. GitOps のトラブルシューティング
リンクのコピー

GitOps コントローラーに問題がある場合は、OpenShift CLI (oc) ツールを使用できます。

7.4.1. oc adm inspect を使用した GitOps のデバッグ
リンクのコピー

OpenShift CLI (oc) を使用して GitOps をデバッグできます。

前提条件

  • oc コマンドラインツールがインストールされている。

手順

  1. GitOps 名前空間にいるときに oc adm inspect コマンドを実行します。 

    $ oc adm inspect ns/openshift-gitops

    出力例

    Gathering data for ns/openshift-gitops...
W0501 20:34:35.978508 57625 util.go:118] the server doesn't have a resource type egressfirewalls, skipping the inspection
W0501 20:34:35.980881 57625 util.go:118] the server doesn't have a resource type egressqoses, skipping the inspection
W0501 20:34:36.040664 57625 util.go:118] the server doesn't have a resource type servicemonitors, skipping the inspection
Wrote inspect data to inspect.local.2673575938140296280.

次のステップ

  • oc adm inspect で必要な情報が提供されなかった場合は、sos レポートを実行できます。

第8章 SCC を使用した Pod セキュリティー認証および承認
リンクのコピー

Pod セキュリティーアドミッションは、Kubernetes Pod セキュリティー標準 の実装です。Pod のセキュリティーアドミッションにセキュリティーコンテンツ制約(SCC)を使用して、Pod の動作を制限します。

8.1. Pod セキュリティー標準とのセキュリティーコンテキスト制約の同期
リンクのコピー

MicroShift には、Kubernetes Pod のセキュリティーアドミッション が含まれています。

グローバル Pod セキュリティーアドミッションコントロールの設定に加えて、特定の namespace にあるサービスアカウントの security context constraint (SCC) アクセス許可に従って、Pod セキュリティーアドミッションコントロールの warn ラベルと alert ラベルを namespace に適用するコントローラーが存在します。

重要

クラスターペイロードの一部として定義されている namespace では、Pod セキュリティーアドミッションの同期が完全に無効になっています。必要に応じて、他の namespace で Pod セキュリティーアドミッション同期を有効にできます。Operator がユーザー作成の openshift-* namespace にインストールされている場合、namespace でクラスターサービスバージョン (CSV) が作成された後、デフォルトで同期がオンになります。

コントローラーは ServiceAccount オブジェクトのアクセス許可を確認して、各 namespace で Security Context Constraints を使用します。セキュリティーコンテキスト制約 (SCC) は、フィールド値に基づいて Pod セキュリティープロファイルにマップされます。コントローラーはこれらの変換されたプロファイルを使用します。Pod のセキュリティーアドミッション warn と aleart ラベルは、namespace 内で最も特権が高い Pod セキュリティープロファイルに設定され、Pod の作成時に警告と監査ログが発生しないようにします。

namespace のラベル付けは、namespace ローカルサービスアカウントの権限を考慮して行われます。

Pod を直接適用すると、Pod を実行するユーザーの SCC 権限が使用される場合があります。ただし、自動ラベル付けではユーザー権限は考慮されません。

8.1.1. namespace での Security Context Constraints の表示
リンクのコピー

特定の namespace の Security Context Constraints (SCC) 権限を表示できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  • namespace の SCC (Security Context Constraints) を表示するには、以下のコマンドを実行します。 

    oc get --show-labels namespace <namespace>

8.2. Pod セキュリティーアドミッションの同期制御
リンクのコピー

ほとんどの namespace で、Pod セキュリティーアドミッションの自動同期を有効にできます。

security.openshift.io/scc.podSecurityLabelSync フィールドが空か、false に設定されている場合、システムのデフォルトは適用されません。同期するには、ラベルを true に設定する必要があります。

重要

クラスターペイロードの一部として定義されている namespace では、Pod セキュリティーアドミッションの同期が完全に無効になっています。これらの namespace には以下が含まれます。

  • default
  • kube-node-lease
  • kube-system
  • kube-public
  • openshift
  • openshift-operators を除く、openshift- という接頭辞が付いたシステム作成の namespace。デフォルトでは、接頭辞が openshift- の namespace はすべて同期されません。ユーザーが作成した任意の openshift-* namespace の同期を有効にすることができます。openshift-operators を除き、システムで作成された openshift-* namespace の同期を有効にすることはできません。

Operator がユーザー作成の openshift-* namespace にインストールされている場合、namespace でクラスターサービスバージョン (CSV) が作成された後、デフォルトで同期がオンになります。同期されたラベルは、namespace のサービスアカウントの権限を継承します。

手順

  • namespace で Pod セキュリティーアドミッションラベルの同期を有効にするには、security.openshift.io/scc.podSecurityLabelSync ラベルの値を true に設定します。

    以下のコマンドを実行します。 

    $ oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=true
注記

--overwrite フラグを使用すると、namespace での Pod セキュリティーラベルの同期の影響を元に戻すことができます。

第9章 Operator
リンクのコピー

9.1. MicroShift での Operator の使用
リンクのコピー

MicroShift で Operator を使用して、クラスター内で実行中のサービスを監視するアプリケーションを作成できます。Operator は、データベースやメッセージバスのデプロイなど、アプリケーションとそのリソースを管理できます。クラスター内で実行するカスタマイズされたソフトウェアとして、Operator を使用して一般的な操作を実装し、自動化できます。

Operator はよりローカライズされた設定エクスペリエンスを提供し、kubectl や oc などの Kubernetes API および CLI ツールと統合します。Operator は、アプリケーション専用に設計されています。Operator を使用すると、グローバル設定ファイルを変更する代わりにコンポーネントを設定できます。

MicroShift アプリケーションは通常、静的環境にデプロイされることが想定されています。ただし、Operator はユースケースで役立つ場合に利用できます。Operator と MicroShift との互換性を確認するには、Operator のドキュメントを確認してください。

9.1.1. MicroShift クラスターで Operator を使用する方法
リンクのコピー

MicroShift クラスターで Operator を使用するには 2 つの方法があります。

9.1.1.1. Operator 向けのマニフェスト
リンクのコピー

マニフェストを使用して、Operator を直接インストールおよび管理できます。MicroShift で kustomize 設定管理ツールを使用して、アプリケーションをデプロイできます。マニフェストを使用して Operator をインストールするには、同じ手順を使用します。

9.1.1.2. Operator 向けの Operator Lifecycle Manager
リンクのコピー

Operator Lifecycle Manager (OLM) を使用して、アドオン Operator を MicroShift クラスターにインストールすることもできます。OLM を使用すると、カスタム Operator と広く利用可能な Operator の両方を管理できます。MicroShift で OLM を使用するには、カタログをビルドする必要があります。

9.2. MicroShift での Operator Lifecycle Manager の使用
リンクのコピー

Operator Lifecycle Manager (OLM)は、オプションのアドオン Operator をインストールし、実行するために MicroShift で使用されます。詳細は以下のリンクを参照してください。

9.2.1. MicroShift で OLM を使用する際の考慮事項
リンクのコピー

  • OpenShift Container Platform で適用されるクラスター Operator は、MicroShift では使用されません。

  • アプリケーションで使用するアドオン Operator 用に、独自のカタログを作成する必要があります。カタログはデフォルトでは提供されません。

    • OLM カタログ Operator がカタログをコンテンツに使用できるように、各カタログにはアクセス可能な CatalogSource がクラスターに追加されている必要があります。

  • MicroShift で OLM アクティビティーを実行するには、CLI を使用する必要があります。コンソールと OperatorHub GUI は使用できません。

    • Operator Package Manager opm CLI は、ネットワーク接続されたクラスターで使用するか、内部レジストリーを使用するカスタム Operator のカタログをビルドするために使用します。
    • 非接続クラスターまたはオフラインのクラスターのカタログと Operator をミラーリングするには、oc-mirror OpenShift CLI プラグイン をインストールします。
重要

Operator を使用する前に、Operator が Red Hat build of MicroShift でサポートされていることをプロバイダーに確認してください。

9.2.2. OLM インストールタイプの決定
リンクのコピー

OLM パッケージマネージャーをインストールして、MicroShift 4.15 以降のバージョンで使用できます。MicroShift クラスター用の OLM をインストールするには、ユースケースに応じてさまざまな方法があります。

9.2.3. MicroShift での namespace の使用
リンクのコピー

microshift-olm RPM は 3 つのデフォルトの namespace を作成します。1 つは OLM の実行用で、2 つはカタログと Operator のインストール用です。ユースケースでの必要性に応じて、追加の namespace を作成できます。

9.2.3.1. デフォルトの namespace
リンクのコピー

次の表に、デフォルトの namespace と、各 namespace の動作の簡単な説明が示されています。

Expand
表9.1 OLM によって MicroShift 用に作成されたデフォルトの namespace

デフォルトの namespace

詳細

openshift-operator-lifecycle-manager

OLM パッケージマネージャーは、この namespace で実行されます。

openshift-marketplace

グローバル namespace。デフォルトでは空です。カタログソースをすべての namespace のユーザーがグローバルに利用できるようにするには、カタログソース YAML で openshift-marketplace namespace を設定します。

openshift-operators

MicroShift で Operator が実行されるデフォルトの namespace。openshift-operators namespace 内のカタログを参照する Operator には、AllNamespaces 監視スコープが必要です。

9.2.3.2. カスタム namespace
リンクのコピー

単一の namespace でカタログと Operator を一緒に使用する場合は、カスタム namespace を作成する必要があります。namespace を作成した後、その namespace にカタログを作成する必要があります。カスタム namespace で実行されているすべての Operator は、同じ単一 namespace の監視スコープを持つ必要があります。

9.2.4. Operator カタログのビルドについて
リンクのコピー

MicroShift で Operator Lifecycle Manager (OLM) を使用するには、OLM で管理できるカスタム Operator カタログをビルドする必要があります。OpenShift Container Platform に含まれる標準カタログは、MicroShift には含まれません。

9.2.4.1. ファイルベースの Operator カタログ
リンクのコピー

カスタム Operator のカタログを作成したり、広く利用可能な Operator のカタログをフィルターしたりできます。両方の方法を組み合わせて、特定のユースケースに必要なカタログを作成できます。独自の Operator および OLM で MicroShift を実行するには、ファイルベースのカタログ構造を使用してカタログを作成します。

重要

9.2.5. OLM を使用した Operator のデプロイ方法
リンクのコピー

カスタムカタログを作成してデプロイした後、カタログにアクセスし、選択した Operator をインストールできるサブスクリプションカスタムリソース (CR) を作成する必要があります。Operator が実行される場所は、Subscription CR を作成する namespace によって異なります。

重要

OLM の Operator には監視スコープがあります。たとえば、一部の Operator は独自の namespace の監視のみをサポートしますが、他の Operator はクラスター内のすべての namespace の監視をサポートします。特定の namespace にインストールされているすべての Operator は、同じ監視スコープを持つ必要があります。

9.2.5.1. 接続性と OLM Operator のデプロイメント
リンクのコピー

Operator は、カタログが実行されている場所であればどこにでもデプロイできます。

  • インターネットに接続されているクラスターの場合、イメージのミラーリングは必要ありません。イメージはネットワーク経由で取得できます。
  • MicroShift が内部ネットワークのみにアクセスできる制限されたネットワークの場合、イメージを内部レジストリーにミラーリングする必要があります。
  • MicroShift クラスターが完全にオフラインであるユースケースでは、すべてのイメージを osbuild ブループリントに埋め込む必要があります。

異なる Operator を異なる namespace にデプロイするには、次の手順を使用します。ネットワーク接続のある MicroShift クラスターの場合、Operator Lifecycle Manager (OLM) は、リモートレジストリーでホストされているソースにアクセスできます。次の手順では、設定ファイルを使用して、グローバル namespace を使用する Operator をインストールする基本的な手順を示します。

注記

別の namespace または複数の namespace にインストールされた Operator を使用するには、カタログソースと Operator を参照する Subscription CR が openshift-marketplace namespace で実行されていることを確認してください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • Operator Lifecycle Manager (OLM) がインストールされている。
  • グローバル namespace にカスタムカタログを作成している。

手順

  1. 次のコマンドを使用して、OLM が実行されていることを確認します。 

    $ oc -n openshift-operator-lifecycle-manager get pod -l app=olm-operator

    出力例

    NAME                            READY   STATUS    RESTARTS   AGE
olm-operator-85b5c6786-n6kbc    1/1     Running   0          2m24s

  2. 次のコマンドを使用して、OLM カタログ Operator が実行されていることを確認します。 

    $ oc -n openshift-operator-lifecycle-manager get pod -l app=catalog-operator

    出力例

    NAME                                READY   STATUS    RESTARTS   AGE
catalog-operator-5fc7f857b6-tj8cf   1/1     Running   0          2m33s

注記

次の手順では、グローバル namespace openshift-marketplace を使用していることを前提としています。カタログは Operator と同じ namespace で実行する必要があります。Operator は AllNamespaces モードをサポートする必要があります。

  1. 次のサンプル YAML を使用して、CatalogSource オブジェクトを作成します。

    カタログソース YAML の例

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: operatorhubio-catalog
  namespace: openshift-marketplace
    1 
    
spec:
  sourceType: grpc
  image: quay.io/operatorhubio/catalog:latest
  displayName: Community Operators
    2 
    
  publisher: OperatorHub.io
  grpcPodConfig:
    securityContextConfig: restricted
    3 
    
  updateStrategy:
    registryPoll:
      interval: 60m

    1
    グローバル namespace。metadata.namespace を openshift-marketplace に設定すると、カタログがすべての namespace で実行できるようになります。どの namespace のサブスクリプションでも、openshift-marketplace namespace で作成されたカタログを参照できます。
    2
    コミュニティー Operator は、デフォルトでは MicroShift の OLM とともにインストールされません。ここには一例として記載されています。
    3
    securityContextConfig の値は、MicroShift に対して restricted に設定する必要があります。

  2. 次のコマンドを実行して、CatalogSource 設定を適用します。 

    $ oc apply -f <catalog_source.yaml>
    1
    1
    <catalog-source.yaml> をカタログソース設定ファイル名に置き換えます。この例では、catalogsource.yaml が使用されます。

    出力例

    catalogsource.operators.coreos.com/operatorhubio-catalog created

  3. カタログソースが適用されていることを確認するには、次のコマンドを使用して READY 状態を確認します。 

    $ oc describe catalogsources.operators.coreos.com -n openshift-marketplace operatorhubio-catalog

    出力例

    Name:         operatorhubio-catalog
Namespace:    openshift-marketplace
Labels:       <none>
Annotations:  <none>
API Version:  operators.coreos.com/v1alpha1
Kind:         CatalogSource
Metadata:
  Creation Timestamp:  2024-01-31T09:55:31Z
  Generation:          1
  Resource Version:    1212
  UID:                 4edc1a96-83cd-4de9-ac8c-c269ca895f3e
Spec:
  Display Name:  Community Operators
  Grpc Pod Config:
    Security Context Config:  restricted
  Image:                      quay.io/operatorhubio/catalog:latest
  Publisher:                  OperatorHub.io
  Source Type:                grpc
  Update Strategy:
    Registry Poll:
      Interval:  60m
Status:
  Connection State:
    Address:              operatorhubio-catalog.openshift-marketplace.svc:50051
    Last Connect:         2024-01-31T09:55:57Z
    Last Observed State:  READY
    1 
    
  Registry Service:
    Created At:         2024-01-31T09:55:31Z
    Port:               50051
    Protocol:           grpc
    Service Name:       operatorhubio-catalog
    Service Namespace:  openshift-marketplace
Events:                 <none>

    1
    ステータスは READY と報告されます。

  4. 次のコマンドを使用して、カタログソースが実行されていることを確認します。 

    $ oc get pods -n openshift-marketplace -l olm.catalogSource=operatorhubio-catalog

    出力例

    NAME                          READY   STATUS    RESTARTS   AGE
operatorhubio-catalog-x24nh   1/1     Running   0          59s

  5. 次の YAML 例を使用して、Subscription CR 設定ファイルを作成します。

    サブスクリプションカスタムリソース YAML の例

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: my-cert-manager
  namespace: openshift-operators
spec:
  channel: stable
  name: cert-manager
  source: operatorhubio-catalog
  sourceNamespace: openshift-marketplace
    1

    1
    グローバル namespace。sourceNamespace 値を openshift-marketplace に設定すると、カタログも openshift-marketplace namespace で実行される場合に、Operator を複数の namespace で実行できるようになります。

  6. 次のコマンドを実行して、Subscription CR 設定を適用します。 

    $ oc apply -f <subscription_cr.yaml>
    1
    1
    <subscription_cr.yaml> を Subscription CR ファイル名に置き換えます。

    出力例

    subscription.operators.coreos.com/my-cert-manager created

  7. 使用する特定のオペランドの設定ファイルを作成し、今すぐ適用できます。

検証

  1. 次のコマンドを使用して、Operator が実行されていることを確認します。 

    $ oc get pods -n openshift-operators
    1
    1
    Subscription CR の namespace が使用されます。
    注記

    Operator が開始するまで 1 - 2 分ほどお待ちください。

    出力例

    NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-7df8994ddb-4vrkr              1/1     Running   0          19s
cert-manager-cainjector-5746db8fd7-69442   1/1     Running   0          18s
cert-manager-webhook-f858bf58b-748nt       1/1     Running   0          18s

9.2.5.3. 特定の namespace のネットワーククラスターに OLM ベースの Operator を追加する
リンクのコピー

Operator の namespace (例: olm-microshift) を指定する場合は、この手順を使用します。この例では、カタログのスコープが設定されており、グローバルな openshift-marketplace namespace で使用できます。Operator はグローバル namespace のコンテンツを使用しますが、olm-microshift namespace でのみ実行されます。ネットワーク接続のある MicroShift クラスターの場合、Operator Lifecycle Manager (OLM) は、リモートレジストリーでホストされているソースにアクセスできます。

重要

特定の namespace にインストールされているすべての Operator は、同じ監視スコープを持つ必要があります。この場合、監視スコープは OwnNamespace です。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • Operator Lifecycle Manager (OLM) がインストールされている。
  • グローバル namespace で実行中のカスタムカタログが作成されている。

手順

  1. 次のコマンドを使用して、OLM が実行されていることを確認します。 

    $ oc -n openshift-operator-lifecycle-manager get pod -l app=olm-operator

    出力例

    NAME                           READY   STATUS    RESTARTS   AGE
olm-operator-85b5c6786-n6kbc   1/1     Running   0          16m

  2. 次のコマンドを使用して、OLM カタログ Operator が実行されていることを確認します。 

    $ oc -n openshift-operator-lifecycle-manager get pod -l app=catalog-operator

    出力例

    NAME                                READY   STATUS    RESTARTS   AGE
catalog-operator-5fc7f857b6-tj8cf   1/1     Running   0          16m

  3. 次の YAML 例を使用して、namespace を作成します。

    namespace YAML の例

    apiVersion: v1
kind: Namespace
metadata:
  name: olm-microshift

  4. 次のコマンドを使用して、namespace 設定を適用します。 

    $ oc apply -f <ns.yaml>
    1
    1
    <ns.yaml> を namespace 設定ファイルの名前に置き換えます。この例では、olm-microshift が使用されます。

    出力例

    namespace/olm-microshift created

  5. 次の YAML 例を使用して、Operator グループ YAML を作成します。

    Operator グループ YAML の例

    kind: OperatorGroup
apiVersion: operators.coreos.com/v1
metadata:
  name: og
  namespace: olm-microshift
spec:
    1 
    
  targetNamespaces:
  - olm-microshift

    1
    グローバル namespace を使用する Operator の場合は、spec.targetNamespaces フィールドと値を省略します。

  6. 次のコマンドを実行して、Operator グループ設定を適用します。 

    $ oc apply -f <og.yaml>
    1
    1
    <og.yaml> を Operator グループ設定ファイルの名前に置き換えます。

    出力例

    operatorgroup.operators.coreos.com/og created

  7. 次のサンプル YAML を使用して、CatalogSource オブジェクトを作成します。

    カタログソース YAML の例

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: operatorhubio-catalog
  namespace: openshift-marketplace
    1 
    
spec:
  sourceType: grpc
  image: quay.io/operatorhubio/catalog:latest
  displayName: Community Operators
    2 
    
  publisher: OperatorHub.io
  grpcPodConfig:
    securityContextConfig: restricted
    3 
    
  updateStrategy:
    registryPoll:
      interval: 60m

    1
    グローバル namespace。metadata.namespace を openshift-marketplace に設定すると、カタログがすべての namespace で実行できるようになります。任意の namespace の Subscription CR は、openshift-marketplace namespace で作成されたカタログを参照できます。
    2
    コミュニティー Operator は、デフォルトでは MicroShift の OLM とともにインストールされません。ここには一例として記載されています。
    3
    securityContextConfig の値は、MicroShift に対して restricted に設定する必要があります。

  8. 次のコマンドを実行して、CatalogSource 設定を適用します。 

    $ oc apply -f <catalog_source.yaml>
    1
    1
    <catalog_source.yaml> をカタログソース設定ファイル名に置き換えます。

  9. カタログソースが適用されていることを確認するには、次のコマンドを使用して READY 状態を確認します。 

    $ oc describe catalogsources.operators.coreos.com -n openshift-marketplace operatorhubio-catalog

    出力例

    Name:         operatorhubio-catalog
Namespace:    openshift-marketplace
Labels:       <none>
Annotations:  <none>
API Version:  operators.coreos.com/v1alpha1
Kind:         CatalogSource
Metadata:
  Creation Timestamp:  2024-01-31T10:09:46Z
  Generation:          1
  Resource Version:    2811
  UID:                 60ce4a36-86d3-4921-b9fc-84d67c28df48
Spec:
  Display Name:  Community Operators
  Grpc Pod Config:
    Security Context Config:  restricted
  Image:                      quay.io/operatorhubio/catalog:latest
  Publisher:                  OperatorHub.io
  Source Type:                grpc
  Update Strategy:
    Registry Poll:
      Interval:  60m
Status:
  Connection State:
    Address:              operatorhubio-catalog.openshift-marketplace.svc:50051
    Last Connect:         2024-01-31T10:10:04Z
    Last Observed State:  READY
    1 
    
  Registry Service:
    Created At:         2024-01-31T10:09:46Z
    Port:               50051
    Protocol:           grpc
    Service Name:       operatorhubio-catalog
    Service Namespace:  openshift-marketplace
Events:                 <none>

    1
    ステータスは READY と報告されます。

  10. 次のコマンドを使用して、カタログソースが実行されていることを確認します。 

    $ oc get pods -n openshift-marketplace -l olm.catalogSource=operatorhubio-catalog

    出力例

    NAME                          READY   STATUS    RESTARTS   AGE
operatorhubio-catalog-j7sc8   1/1     Running   0          43s

  11. 次の YAML 例を使用して、Subscription CR 設定ファイルを作成します。

    サブスクリプションカスタムリソース YAML の例

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: my-gitlab-operator-kubernetes
  namespace: olm-microshift
    1 
    
spec:
  channel: stable
  name: gitlab-operator-kubernetes
  source: operatorhubio-catalog
  sourceNamespace: openshift-marketplace
    2

    1
    特定の namespace。Operator はコンテンツのグローバル namespace を参照しますが、olm-microshift namespace で実行されます。
    2
    グローバル namespace。任意の namespace の Subscription CR は、openshift-marketplace namespace で作成されたカタログを参照できます。

  12. 次のコマンドを実行して、Subscription CR 設定を適用します。 

    $ oc apply -f <subscription_cr.yaml>
    1
    1
    <subscription_cr.yaml> を Subscription CR 設定ファイルの名前に置き換えます。

    出力例

    subscription.operators.coreos.com/my-gitlab-operator-kubernetes

  13. 使用する特定のオペランドの設定ファイルを作成し、今すぐ適用できます。

検証

  1. 次のコマンドを使用して、Operator が実行されていることを確認します。 

    $ oc get pods -n olm-microshift
    1
    1
    Subscription CR の namespace が使用されます。
    注記

    Operator が開始するまで 1 - 2 分ほどお待ちください。

    出力例

    NAME                                         READY   STATUS    RESTARTS   AGE
gitlab-controller-manager-69bb6df7d6-g7ntx   2/2     Running   0          3m24s

9.3. oc-mirror プラグインを使用したカスタム Operator カタログの作成
リンクのコピー

幅広い Operator を使用してカスタムカタログを作成し、oc-mirror OpenShift CLI (oc)プラグインを使用してそれらをミラーリングできます。

9.3.1. Red Hat が提供する Operator カタログとミラーレジストリーの使用
リンクのコピー

カタログをフィルタリングし、イメージを削除して、特定の Operator を取得し、oc-mirror OpenShift CLI (oc)プラグインを使用してそれらをミラーリングできます。非接続設定で Operator を使用するか、Red Hat Enterprise Linux (RHEL)イメージに埋め込まれた Operator を使用することもできます。

  • ミラーリング用にシステムを設定する方法は、以下の関連情報セクションのリンクを参照してください。
  • Red Hat が提供する Operator カタログから Operator をデプロイする準備ができている場合は、それらをミラーリングするか、RHEL イメージに組み込むために、oc-mirror プラグインを使用したカタログコンテンツの検査 セクションから始めます。

9.3.2. ミラーレジストリーを作成するための oc-mirror プラグインについて
リンクのコピー

MicroShift で oc-mirror OpenShift CLI (oc)プラグインを使用して、Operator カタログからイメージをフィルタリングおよび削除できます。その後、フィルターされたカタログコンテンツをミラーレジストリーにミラーリングしたり、非接続またはオフラインのデプロイメントでコンテナーイメージを使用したりできます。

インターネットに接続された Red Hat ホストレジストリーから切断されたイメージレジストリーにコンテンツをミラーリングする手順は、選択したレジストリーに関係なく同じです。カタログの内容をミラーリングした後、ミラーレジストリーからこのコンテンツを取得するように各クラスターを設定します。

9.3.2.1. ミラーレジストリーを作成する際の接続に関する考慮事項
リンクのコピー

レジストリーを入力するときは、次のいずれかの接続シナリオを使用できます。

接続ミラーリング
インターネットとミラーレジストリーの両方にアクセスできるホストがあるが、クラスターノードにはアクセスできない場合、そのマシンからコンテンツを直接ミラーリングできます。
非接続ミラーリング

インターネットとミラーレジストリーの両方にアクセスできるホストがない場合は、イメージをファイルシステムにミラーリングしてから、そのホストまたはリムーバブルメディアを非接続環境に持ち込む必要があります。

重要

コンテナーレジストリーは、プロビジョニングするクラスター内のすべてのマシンから到達可能である必要があります。レジストリーに到達できない場合、ワークロードの再配置など、インストール、更新、およびその他の操作は失敗します。

到達不能なレジストリーによって発生する問題を回避するには、次の標準的な方法を使用します。

  • ミラーレジストリーを高可用性の方法で実行します。
  • ミラーレジストリーが少なくともクラスターの製品可用性と一致していることを確認します。

9.3.3. oc-mirror プラグインを使用したカタログ内容の検査
リンクのコピー

次の手順例を使用してカタログを選択し、OpenShift Container Platform Operator を一覧表示し、oc-mirror プラグインイメージセット設定ファイルに追加します。カタログを選択して Operator を一覧表示するには、oc mirror v1 を使用する必要があります。

注記

独自のカタログと Operator を使用する場合は、イメージを内部レジストリーに直接プッシュできます。

前提条件

  • OpenShift CLI (oc)をアンインストールしている。
  • Operator Lifecycle Manager (OLM)をインストールしている。
  • oc-mirror プラグインをインストールしている。

手順

  1. 次のコマンドを実行して、フィルタリング可能な Red Hat 提供の Operator カタログのリストを取得します。 

    $ oc mirror list operators --version 4.18 --catalogs

  2. 次のコマンドを実行して、Red Hat Operators カタログの Operator の一覧を取得します。 

    $ oc mirror list operators <--catalog=<catalog_source>>
    1
    1
    registry.redhat.io/redhat/redhat-operator-index:v4.18 または quay.io/operatorhubio/catalog:latest などのカタログソースを指定します。
  3. Operator を選択します。この例では、amq-broker-rhel9 Operator を使用します。

  4. オプション: フィルタリングする Operator のチャネルとバージョンを検査するには、次のコマンドを入力します。

    1. 次のコマンドを実行して、チャネルのリストを取得します。 

      $ oc mirror list operators --catalog=registry.redhat.io/redhat/redhat-operator-index:v4.18 --package=amq-broker-rhel9

    2. 次のコマンドを実行して、チャネル内のバージョンのリストを取得します。 

      $ oc mirror list operators --catalog=registry.redhat.io/redhat/redhat-operator-index:v4.18 --package=amq-broker-rhel9 --channel=7.13.x

次のステップ

  • この手順で収集した情報を使用して、イメージセット設定ファイルを作成および編集します。
  • 変換されたイメージセット設定ファイルからのイメージをミラーレジストリーまたはディスクにミラーリングします。

9.3.4. イメージセット設定ファイルの作成
リンクのコピー

ImageSetConfiguration YAML ファイルを作成する必要があります。このイメージセット設定ファイルは、ミラーリングする Operator と oc-mirror プラグインの設定の両方を指定します。エントリーが、使用する予定の MicroShift と Operator の両方と互換性を持つように、イメージセット設定ファイルの内容を編集します。

注記

oc mirror v2 は、metadata の代わりにキャッシュシステムを使用します。キャッシュシステムは、1 つのステップが失敗した場合にミラーリングプロセス全体を開始する必要がなくなります。代わりに、失敗したステップのトラブルシューティングを行うと、失敗前に存在していたミラーイメージがプロセスによって再ミラーリングされません。

前提条件

手順

  1. 次の例をガイドとして使用して、MicroShift の ImageSetConfiguration YAML を作成して編集します。

    編集された MicroShift イメージセット設定ファイルの例

    kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v2alpha1
mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.18
    1 
    
    packages:
    - name: amq-broker-rhel9
    2 
    
      channels:
      - name: 7.13.x
    3 
    
  additionalImages:
    4 
    
   - name: quay.io/rh_ee_aguidi/multi-platform-container:latest
   - name: quay.io/rh_ee_aguidi/empty-image:latest

    1
    イメージを取得する Operator カタログを設定します。
    2
    イメージセットに含める Operator パッケージを指定します。カタログ内のすべてのパッケージを取得するには、このフィールドを削除してください。
    3
    イメージセットに含める Operator パッケージの特定のチャネルのみを指定します。そのチャネルでバンドルを使用しない場合も、常に Operator パッケージのデフォルトチャネルを含める必要があります。oc mirror list operators --catalog=<catalog_name> --package=<package_name> コマンドを実行すると、デフォルトチャネルを見つけることができます。
    4
    イメージセットに含める追加のイメージを指定します。追加のイメージを指定する必要がない場合は、このフィールドを削除してください。
    重要

    プラットフォーム フィールド、関連フィールド、および Helm は MicroShift ではサポートされていません。

  2. 更新されたファイルを ImageSetConfiguration.yaml として保存します。

次のステップ

  • oc-mirror プラグインを使用して、イメージセットをターゲットミラーレジストリーに直接ミラーリングします。
  • CRI-O を設定します。
  • カタログソースをクラスターに適用します。
9.3.4.1. oc-mirror プラグイン v2 の ImageSet 設定パラメーター
リンクのコピー

oc-mirror プラグイン v2 には、ミラーリングするイメージを定義するイメージセット設定ファイルが必要です。次の表に、ImageSetConfiguration リソースで使用可能なパラメーターを示します。

注記

minVersion および maxVersion プロパティーを使用して特定の Operator バージョン範囲をフィルターすると、複数のチャネルヘッドエラーが発生する可能性があります。エラーメッセージには、multiple channel heads があることが示されます。これは、フィルターを適用すると、Operator の更新グラフが切り捨てられるためです。

OLM の要件として、すべての Operator チャネルに、1 つのエンドポイント (つまり最新バージョンの Operator) を持つ更新グラフを構成するバージョンが含まれている必要があります。フィルター範囲を適用すると、更新グラフが 2 つ以上の個別のグラフ、または複数のエンドポイントを持つグラフに変換されることがあります。

このエラーを回避するには、最新バージョンの Operator を除外しないでください。それでもエラーが発生する場合は、Operator に応じて、maxVersion プロパティーを増やすか、minVersion プロパティーを減らす必要があります。Operator グラフはそれぞれ異なる可能性があるため、エラーが解決するまでこれらの値を調整する必要がある場合があります。

Expand
表9.2 ImageSetConfiguration パラメーター
パラメーター説明値

apiVersion

ImageSetConfiguration コンテンツの API バージョン。

文字列の例: mirror.openshift.io/v2alpha1

mirror

イメージセットの設定。

オブジェクト

mirror.additionalImages

イメージセットの追加のイメージ設定。

オブジェクトの配列

以下に例を示します。 

additionalImages:
  - name: registry.redhat.io/ubi8/ubi:latest

mirror.additionalImages.name

ミラーリングするイメージのタグまたはダイジェスト。

文字列の例: registry.redhat.io/ubi8/ubi:latest

mirror.blockedImages

ミラーリングをブロックするタグまたはダイジェスト (SHA) を持つイメージのリスト。

文字列配列の例: docker.io/library/alpine

mirror.operators

イメージセットの Operators 設定。

オブジェクトの配列

以下に例を示します。 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:4.18
    packages:
      - name: elasticsearch-operator
        minVersion: '2.4.0'

mirror.operators.catalog

イメージセットに含める Operator カタログ。

文字列の例: registry.redhat.io/redhat/redhat-operator-index:v4.15

mirror.operators.full

true の場合、完全なカタログ、Operator パッケージ、または Operator チャネルをダウンロードします。

ブール値。デフォルト値は false です。

mirror.operators.packages

Operator パッケージ設定

オブジェクトの配列

以下に例を示します。 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:4.18
    packages:
      - name: elasticsearch-operator
        minVersion: '5.2.3-31'

mirror.operators.packages.name

イメージセットに含める Operator パッケージ名

文字列の例: elasticsearch-operator

mirror.operators.packages.channels

Operator パッケージのチャネル設定。

オブジェクト

mirror.operators.packages.channels.name

イメージセットに含める、パッケージ内で一意の Operator チャネル名。

文字列の例: fast または stable-v4.15

mirror.operators.packages.channels.maxVersion

Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。

文字列の例: 5.2.3-31

mirror.operators.packages.channels.minVersion

存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。

文字列の例: 5.2.3-31

mirror.operators.packages.maxVersion

Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。

文字列の例: 5.2.3-31

mirror.operators.packages.minVersion

存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。

文字列の例: 5.2.3-31

mirror.operators.targetCatalog

参照されるカタログをミラーリングするための代替名とオプションの namespace 階層。

文字列の例: my-namespace/my-operator-catalog

mirror.operators.targetCatalogSourceTemplate

oc-mirror プラグイン v2 が生成した catalogSource カスタムリソースを完了するために使用するテンプレートのディスク上のパス。

文字列の例: /tmp/catalog-source_template.yaml テンプレートファイルの例: 

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: discarded
  namespace: openshift-marketplace
spec:
  image: discarded
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 30m0s

mirror.operators.targetTag

targetName または targetCatalog に追加する代替タグ。

文字列の例: v1

9.3.4.1.1. DeleteImageSetConfiguration パラメーター
リンクのコピー

oc-mirror プラグイン v2 でイメージの削除を使用するには、ミラーレジストリーから削除するイメージを定義する DeleteImageSetConfiguration.yaml 設定ファイルを使用する必要があります。次の表は、DeleteImageSetConfiguration リソースで使用可能なパラメーターを示しています。

Expand
表9.3 DeleteImageSetConfiguration パラメーター
パラメーター説明値

apiVersion

DeleteImageSetConfiguration コンテンツの API バージョン。

文字列の例: mirror.openshift.io/v2alpha1

delete

削除するイメージセットの設定。

オブジェクト

delete.additionalImages

削除イメージセットの追加イメージ設定。

オブジェクトの配列の例: 

additionalImages:
  - name: registry.redhat.io/ubi8/ubi:latest

delete.additionalImages.name

削除するイメージのタグまたはダイジェスト。

文字列の例: registry.redhat.io/ubi8/ubi:latest

delete.operators

削除イメージセットの Operator の設定。

オブジェクトの配列の例: 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:{product-version}
    packages:
      - name: elasticsearch-operator
        minVersion: '2.4.0'

delete.operators.catalog

削除イメージセットに含める Operator カタログ。

文字列の例: registry.redhat.io/redhat/redhat-operator-index:v4.15

delete.operators.full

true の場合、完全なカタログ、Operator パッケージ、または Operator チャネルが削除されます。

ブール値。デフォルト値は false です。

delete.operators.packages

Operator パッケージ設定

オブジェクトの配列の例: 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:{product-version}
    packages:
      - name: elasticsearch-operator
        minVersion: '5.2.3-31'

delete.operators.packages.name

削除イメージセットに含める Operator パッケージ名。

文字列の例: elasticsearch-operator

delete.operators.packages.channels

Operator パッケージのチャネル設定。

オブジェクト

delete.operators.packages.channels.name

削除イメージセットに含める、パッケージ内で一意の Operator チャネル名。

文字列の例: fast または stable-v4.15

delete.operators.packages.channels.maxVersion

選択したチャネル内で削除する Operator の最大バージョン。

文字列の例: 5.2.3-31

delete.operators.packages.channels.minVersion

Operator が存在する選択範囲内で削除する Operator の最小バージョン。

文字列の例: 5.2.3-31

delete.operators.packages.maxVersion

Operator が存在するすべてのチャネルで削除する最大バージョンの Operator。

文字列の例: 5.2.3-31

delete.operators.packages.minVersion

Operator が存在するすべてのチャネルで削除する最小バージョンの Operator。

文字列の例: 5.2.3-31

9.3.5. ミラーからミラーへのミラーリング
リンクのコピー

oc-mirror プラグインを使用して、イメージセットの作成中にアクセス可能なターゲットミラーレジストリーにイメージセットを直接ミラーリングできます。

前提条件

  • 必要なコンテナーイメージを取得するためにインターネットにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。
  • oc-mirror CLI プラグインをインストールしている。
  • イメージセット設定ファイルを作成した。

手順

  • 次のコマンドを実行して、指定されたイメージセット設定から指定されたレジストリーにイメージをミラーリングします。 

    $ oc-mirror --config imageset-config.yaml --workspace file://<emphasis><v2_workspace></emphasis> \
    1 
    
  docker://<emphasis><remote_registry></emphasis> --v2
    2
    1
    ミラー間プロセスに the-- workspace フラグを使用する必要があります。&lt ;v2_workspace& gt; は、ミラーリングプロセスのカスタムリソースを格納するために使用するディレクトリーに置き換えます。
    2
    & lt;remote_registry& gt; をイメージセットファイルをミラーリングするレジストリーの名前に置き換えます。レジストリーは docker:// で始まる必要があります。ミラーレジストリーに最上位の namespace を指定する場合は、これ以降の実行でもこれと同じ namespace を使用する必要があります。

    出力例

    Rendering catalog image "registry.example.com/redhat/redhat-operator-index:v{ocp-version}" with file-based catalog

    重要

    MicroShift で CRI-O の手動設定の参照コンテンツとして、ImageDigestMirrorSet YAML ファイルを使用する必要があります。リソースを MicroShift クラスターに直接適用することはできません。

検証

  1. 次のコマンドを実行して、cluster-resources サブディレクトリーの内容を一覧表示します。 

    $ ls <v2_workspace>/working-dir/cluster-resources/
    1
    1
    &lt ;v2_workspace&gt; は、ミラーリングプロセスのカスタムリソースを保存するために使用したディレクトリーに置き換えます。

次のステップ

  • CRI-O を手動で設定するために使用する ImageDigestMirrorSet YAML コンテンツを変換します。
  • 必要に応じて、非接続またはオフラインで使用するために、ミラーからディスクにイメージをミラーリングします。

トラブルシューティング

9.3.6. Operator のレジストリーミラーを使用するための CRI-O の設定
リンクのコピー

oc-mirror プラグインで作成された ImageDigestMirrorSet YAML ファイルを、MicroShift で使用される CRI-O コンテナーランタイム設定と互換性のある形式に変換する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • Operator Lifecycle Manager (OLM)をインストールしている。
  • oc-mirror プラグインをインストールしている。
  • yq バイナリーをインストールしている。
  • ImageDigestMirrorSet および CatalogSource YAML ファイルは、cluster-resources サブディレクトリーで利用できます。

手順

  1. 次のコマンドを実行して、ImageDigestMirrorSet YAML ファイルの内容を確認します。 

    $ cat <v2_workspace>/working-dir/cluster-resources/imagedigestmirrorset.yaml
    1
    1
    &lt ;v2_workspace&gt; を、ミラーリングリソースを生成したときに使用したディレクトリー名に置き換えます。

    出力例

    apiVersion: config.openshift.io/v1
kind: ImageDigestMirrorSet
metadata:
  labels:
    operators.openshift.org/catalog: "true"
  name: operator-0
spec:
  imageDigestMirrors:
  - mirrors:
    - registry.example.com/amq7
    source: registry.redhat.io/amq7

  2. 次のコマンドを実行して、imagedigestmirrorset.yaml を CRI-O 設定の準備が整った形式に変換します。 

    yq '.spec.imageDigestMirrors[] as $item ireduce([]; . + [{"mirror": $item.mirrors[], "source": ($item | .source)}]) | .[] |
  "[[registry]]
      prefix = \"" + .source + "\"
      location = \"" + .mirror + "\"
      mirror-by-digest-only = true
      insecure = true
      "' ./mirror1/working-dir/cluster-resources/imagedigestmirrorset.yaml

    出力例

    [[registry]]
      prefix = "registry.redhat.io/amq7"
      location = "registry.example.com/amq7"
      mirror-by-digest-only = true
      insecure = true

  3. /etc/containers/registries.conf.d/ ディレクトリーの CRI-O 設定ファイルに出力を追加します。

    crio-config.yaml ミラー設定ファイルの例

    [[registry]]
      prefix = "registry.redhat.io/amq7"
      location = "registry.example.com/amq7"
      mirror-by-digest-only = true
      insecure = true

[[registry]]
    prefix = ""
    location = "quay.io"
    mirror-by-digest-only = true
[[registry.mirror]]
    location = "<registry_host>:<port>"
    1 
    
    insecure = false

    1
    ミラーレジストリーサーバーのホスト名およびポートを指定します（例： microshift-quay:8443 ）。

  4. 次のコマンドで MicroShift を再起動して、CRI-O 設定の変更を適用します。 

    $ sudo systemctl restart crio

9.3.7. oc-mirror プラグインで作成されたカスタムカタログのインストール
リンクのコピー

イメージセットをミラーレジストリーにミラーリングした後、生成された CatalogSource カスタムリソース (CR) をクラスターに適用する必要があります。Operator Lifecycle Manager (OLM)は CatalogSource CR を使用して、ミラーレジストリーで使用可能な Operator に関する情報を取得します。次に、カスタムカタログをサブスクライブするためのサブスクリプション CR を作成して適用する必要があります。

前提条件

  • イメージセットをレジストリーミラーにミラーリングしている。
  • CRI-O コンテナーのランタイム設定に、イメージ参照情報を追加している。

手順

  1. 次のコマンドを実行して、results ディレクトリーからカタログソース設定ファイルを適用し、カタログソースオブジェクトを作成します。 

    $ oc apply -f ./<v2_workspace>/working-dir/cluster-resources/catalogSource-cs-redhat-catalog.yaml
    1
    1
    &lt ;v2_workspace&gt; は、ミラーリングプロセスのカスタムリソースを保存するために使用したディレクトリーに置き換えます。

    出力例

    catalogsource.operators.coreos.com/cs-redhat-catalog created

  2. 詳細は、以下のサンプルファイルを参照してください。

    カタログソース設定ファイルの例

    apiVersion: operators.coreos.com/v2alpha1
kind: CatalogSource
metadata:
  name: redhat-catalog
  namespace: openshift-marketplace
    1 
    
spec:
  sourceType: grpc
  image: registry.example.com/redhat/redhat-catalog:v4.18
  updateStrategy:
    registryPoll:
      interval: 60m

    1
    グローバル namespace を指定します。metadata.namespace を openshift-marketplace に設定すると、カタログはすべての namespace 内のカタログを参照できるようになります。どの namespace のサブスクリプションでも、openshift-marketplace namespace で作成されたカタログを参照できます。

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

    $ oc get catalogsource --all-namespaces

    出力例

    NAMESPACE               NAME                  DISPLAY               TYPE   PUBLISHER   AGE
openshift-marketplace   certified-operators   Certified Operators   grpc   Red Hat     37m
openshift-marketplace   community-operators   Community Operators   grpc   Red Hat     37m
openshift-marketplace   redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     37m
openshift-marketplace   redhat-catalog        Red Hat Catalog     grpc   Red Hat     37m

  4. 次のコマンドを使用して、カタログソースが実行されていることを確認します。 

    $ oc get pods -n openshift-marketplace

    出力例

    NAME                             READY   STATUS    RESTARTS   AGE
cs-redhat-catalog-4227b   2/2     Running   0          2m5s

  5. 次の例のような Subscription CR を作成します。

    Subscription CR の例

    apiVersion: operators.coreos.com/v2alpha1
kind: Subscription
metadata:
  name: amq-broker
  namespace: openshift-operators
spec:
  channel: 7.13.x
  name: amq-broker-rhel9
  source: cs-redhat-catalog
  sourceNamespace: openshift-marketplace

  6. 次のコマンドを実行して、Subscription CR 設定を適用します。 

    $ oc apply -f ./<subscription_cr.yaml>
    1
    1
    <subscription _cr.yaml> でサブスクリプションの名前を指定します （例： amq-​broker-subscription-cr.yaml ）。

    出力例

    subscription.operators.coreos.com/amq-broker created

9.4. 非接続クラスターへの OLM ベースの Operators の追加
リンクのコピー

OLM ベースの Operators を Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージに埋め込むことで、非接続状況でも使用できます。

9.4.1. 非接続クラスターへの OLM ベースの Operators の追加について
リンクのコピー

非接続クラスターにインストールされている Operator の場合、リモートソースには完全なインターネット接続が必要であるため、Operator Lifecycle Manager (OLM) はデフォルトで、リモートレジストリーでホストされているソースにアクセスできません。したがって、リモートレジストリーを高可用性のコンテナーレジストリーにミラーリングする必要があります。

非接続状況で OLM ベースの Operators を使用するには、次の手順が必要です。

  • ミラーレジストリーのコンテナーイメージリストに OLM を含めます。
  • CRI-O 設定を直接更新して、ミラーレジストリーを使用するようにシステムを設定します。ImageContentSourcePolicy は MicroShift ではサポートされていません。
  • CatalogSource オブジェクトをクラスターに追加して、OLM カタログ Operator がミラーレジストリー上のローカルカタログを使用できるようにします。
  • MicroShift が非接続状態で実行できるようにインストールされていることを確認します。
  • ネットワーク設定が非接続モードで実行されるように設定されていることを確認します。

非接続クラスターで OLM を有効にした後、インターネットに接続されたワークステーションを引き続き使用して、Operator の新しいバージョンがリリースされた際にローカルカタログソースを最新の状態に保つことができます。

9.4.1.1. ドライランの実行
リンクのコピー

実際にイメージをミラーリングせずに、oc-mirror を使用してドライランを実行できます。ドライランは、ミラーリングするイメージの一覧を確認できることを意味します。ドライランを使用して、イメージセット設定のエラーを早期にキャッチしたり、生成されたイメージを他のツールで使用してミラーリングを実行したりできます。

前提条件

  • 必要なコンテナーイメージを取得するためのインターネットへのアクセスがある。
  • OpenShift CLI (oc) がインストールされている。
  • oc-mirror CLI プラグインがインストールされている。
  • イメージセット設定ファイルを作成した。

手順

  1. --dry-run フラグを指定して oc mirror コマンドを実行し、ドライランを実行します。 

    $ oc-mirror --config <ImageSetConfig.yaml> docker://localhost:5000 --workspace file://<outm2m> --dry-run --v2

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

    ImageSetConfig.yaml
    作成したイメージセット設定ファイルの名前を指定します。
    docker://localhost:5000
    ミラーレジストリーを指定します。ドライラン フラグを使用する場合、このレジストリーには何もミラーリングされません。
    --workspace file:// &lt;outm2m>
    ワークスペースパスのアドレスを挿入します。
    --dry-run
    dry run フラグは、実際のイメージセットファイルではなく、ドライランアーティファクトを生成します。
    --v2

    oc mirror v2 を指定します。

    出力例

    2025/08/25 15:50:44  [INFO]   : 👋 Hello, welcome to oc-mirror
2025/08/25 15:50:44  [INFO]   : ⚙  setting up the environment for you...
2025/08/25 15:50:44  [INFO]   : 🔀 workflow mode: mirrorToMirror
2025/08/25 15:50:44  [INFO]   : 🕵  going to discover the necessary images...
2025/08/25 15:50:44  [INFO]   : 🔍 collecting release images...
2025/08/25 15:50:44  [INFO]   : 🔍 collecting operator images...
 ✓   (1m30s) Collecting catalog registry.redhat.io/redhat/redhat-operator-index:v4.20
2025/08/25 15:52:14  [INFO]   : 🔍 collecting additional images...
2025/08/25 15:52:14  [INFO]   : 📄 list of all images for mirroring in : wspace/working-dir/dry-run/mapping.txt
2025/08/25 15:52:14  [INFO]   : mirror time     : 1m30.399585837s
2025/08/25 15:52:14  [INFO]   : 👋 Goodbye, thank you for using oc-mirror

  2. 以下のコマンドを実行して、生成された mapping.txt ファイルを確認します。 

    $ cat wspace/working-dir/dry-run/mapping.txt

    出力例

    docker://registry.redhat.io/amq8/amq-broker-rhel9@sha256:47fd4ce2533496828aba37bd1f9715e2164d5c90bd0fc6b25e7e0786d723bf01=docker://mirror.com/amq8/amq-broker-rhel9:sha256-47fd4ce2533496828aba37bd1f9715e2164d5c90bd0fc6b25e7e0786d723bf01
docker://registry.redhat.io/amq8/amq-broker-init-rhel9@sha256:9cc48eecf1442ae04b8543fa5d4381a13bc2831390850828834d387006d1342b=docker://mirror.com/amq7/amq-broker-init-rhel9:sha256-9cc48eecf1442ae04b8543fa5d4381a13bc2831390850828834d387006d1342b
docker://registry.redhat.io/amq8/amq-broker-rhel9@sha256:bb6fbd68475a7852b4d99eea6c4ab313f9267da7963162f0d75375d7063409e7=docker://mirror.com/amq8/amq-broker-rhel9:sha256-bb6fbd68475a7852b4d99eea6c4ab313f9267da7963162f0d75375d7063409e7
docker://registry.redhat.io/amq8/amq-broker-rhel9@sha256:d42d713da0ce6806fdc6492b6342586783e6865a82a8647d3c4288439b1751ee=docker://mirror.com/amq8/amq-broker-rhel9:sha256-d42d713da0ce6806fdc6492b6342586783e6865a82a8647d3c4288439b1751ee
docker://registry.redhat.io/amq8/amq-broker-init-rhel9@sha256:ffffa9875f0379e9373f89f05eb06e5a193273bb04bc3aa5f85b044357b79098=docker://mirror.com/amq8/amq-broker-init-rhel9:sha256-ffffa9875f0379e9373f89f05eb06e5a193273bb04bc3aa5f85b044357b79098

9.4.1.2. カタログと Operator コンテナーイメージの参照の取得
リンクのコピー

oc-mirror プラグインでドライランを実行してミラーリングするイメージの一覧を確認した後、すべてのコンテナーイメージ参照を取得してから、Image Builder ブループリントに追加するために出力をフォーマットする必要があります。

注記

プロプライエタリー Operator 用に作成されたカタログの場合、次の手順を使用せずに Image Builder ブループリントのイメージ参照をフォーマットできます。

前提条件

  • 使用する Operator のカタログインデックスがある。
  • jq CLI ツールがインストールされている。
  • Image Builder のブループリントファイルを理解している。
  • Image Builder のブループリント TOML ファイルがある。

手順

  1. カタログ index.json ファイルを解析して、イメージビルダーのブループリントに含める必要があるイメージ参照を取得します。フィルタリングされていないカタログを使用することも、ミラーリングできないイメージを除外することもできます。

    1. 次のコマンドを実行して、フィルタリングされていないカタログの index.json ファイルを解析し、イメージ参照を取得します。 

      jq -r --slurp '.[] | select(.relatedImages != null) | "[[containers]]\nsource = \"" + .relatedImages[].image + "\"\n"'   ./oc-mirror-workspace/src/catalogs/registry.redhat.io/redhat/redhat-operator-index/v4.18/index/index.json

    2. ミラーリングできないイメージを除外する場合は、次のコマンドを実行して、カタログの index.json ファイルをフィルタリングして解析します。 

      $ jq -r --slurp '.[] | select(.relatedImages != null) | .relatedImages[] | select(.name |  contains("ppc") or contains("s390x") | not) | "[[containers]]\\nsource = \\"" + .image + "\\"\\n"' ./oc-mirror-workspace/src/catalogs/registry.redhat.io/redhat/redhat-operator-index/v4.18/index/index.json
      注記

      この手順では、AMQ Broker Operator を例として使用します。ユースケースでの必要性に応じて、jq コマンドに他の条件を追加して、さらにフィルタリングすることができます。

      イメージ参照出力の例

      [[containers]]
source = "registry.redhat.io/amq8/amq-broker-init-rhel9@sha256:0b2126cfb6054fdf428c1f43b69e36e93a09a49ce15350e9273c98cc08c6598b"

[[containers]]
source = "registry.redhat.io/amq8/amq-broker-init-rhel9@sha256:0dde839c2dce7cb684094bf26523c8e16677de03149a0fff468b8c3f106e1f4f"
...
...

[[containers]]
source = "registry.redhat.io/amq8/amq-broker-rhel9@sha256:e8fa2a00e576ecb95561ffbdbf87b1c82d479c8791ab2c6ce741dd0d0b496d15"

[[containers]]
source = "registry.redhat.io/amq8/amq-broker-rhel9@sha256:ff6fefad518a6c997d4c5a6e475ba89640260167f0bc27715daf3cc30116fad1"
…
EOF

      重要

      ミラーリングされたユースケースと非接続ユースケースでは、カタログの index.json ファイルからフィルタリングされたすべてのソースがダイジェストであることを確認します。いずれかのソースがダイジェストではなくタグを使用している場合、Operator のインストールは失敗します。タグにはインターネット接続が必要です。

  2. 次のコマンドを実行して、imageset-config.yaml を表示し、CatalogSource カスタムリソース (CR) のカタログイメージ参照を取得します。 

    $ cat imageset-config.yaml

    出力例

    kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v2alpha1
mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.18
    1 
    
    packages:
    - name: amq-broker-rhel9
      channels:
      - name: 7.13.x

    1
    次の jq コマンドの mirror.catalog カタログイメージ参照の値を使用して、イメージダイジェストを取得します。この例では、<registry.redhat.io/redhat/redhat-operator-index:v4.18> です。

  3. 次のコマンドを実行して、カタログインデックスイメージの SHA を取得します。 

    $ skopeo inspect docker://<registry.redhat.io/redhat/redhat-operator-index:v{product-version}> | jq .Digest
    1
    1
    イメージダイジェストを取得するには、jq コマンドの mirror.catalog カタログイメージ参照の値を使用します。この例では、<registry.redhat.io/redhat/redhat-operator-index:v4.18> です。

    出力例

    "sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6"

  4. Image Builder のブループリントファイルにイメージ参照を追加する準備ができているには、次の例を使用してカタログイメージ参照をフォーマットします。 

    [[containers]]
source = "registry.redhat.io/redhat/redhat-operator-index@sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6"

  5. これまでのすべてのステップからのイメージ参照を Image Builder のブループリントに追加します。

    生成された Image Builder ブループリントのサンプルスニペット

    name = "microshift_blueprint"
description = "MicroShift 4.18.1 on x86_64 platform"
version = "0.0.1"
modules = []
groups = []

[[packages]]
    1 
    
name = "microshift"
version = "4.18.1"
...
...

[customizations.services]
    2 
    
enabled = ["microshift"]

[customizations.firewall]
ports = ["22:tcp", "80:tcp", "443:tcp", "5353:udp", "6443:tcp", "30000-32767:tcp", "30000-32767:udp"]
...
...

[[containers]]
    3 
    
source = "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:f41e79c17e8b41f1b0a5a32c3e2dd7cd15b8274554d3f1ba12b2598a347475f4"

[[containers]]
source = "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:dbc65f1fba7d92b36cf7514cd130fe83a9bd211005ddb23a8dc479e0eea645fd"
...
...

[[containers]]
    4 
    
source = "registry.redhat.io/redhat/redhat-operator-index@sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6"
...
...

[[containers]]
source = "registry.redhat.io/amq8/amq-broker-init-rhel9@sha256:0dde839c2dce7cb684094bf26523c8e16677de03149a0fff468b8c3f106e1f4f"
...
...

[[containers]]
source = "registry.redhat.io/amq8/amq-broker-rhel9@sha256:e8fa2a00e576ecb95561ffbdbf87b1c82d479c8791ab2c6ce741dd0d0b496d15"

[[containers]]
source = "registry.redhat.io/amq8/amq-broker-rhel9@sha256:ff6fefad518a6c997d4c5a6e475ba89640260167f0bc27715daf3cc30116fad1"
…
EOF

    1
    microshift-release-info RPM と互換性のある同じバージョンを使用する、オプション以外のすべての MicroShift RPM パッケージの参照。
    2
    システム起動時に MicroShift を自動的に有効にし、デフォルトのネットワーク設定を適用するための参照。
    3
    非接続デプロイメントに必要な、オプションではないすべての MicroShift コンテナーイメージの参照。
    4
    カタログインデックスの参照。
9.4.1.3. 非接続デプロイメントの RHEL for Edge イメージにカタログと Operator を適用する
リンクのコピー

非接続環境用の RHEL for Edge イメージを作成し、非接続で使用するように MicroShift ネットワークを設定したら、namespace を設定し、Operator を実行するためのカタログと Operator カスタムリソース (CR) を作成できます。

前提条件

  • RHEL for Edge イメージがある。
  • ネットワークは非接続環境で使用するように設定されている。
  • oc-mirror プラグインのドライラン手順が完了している。

手順

  1. 次の例のように、CatalogSource カスタムリソース (CR) を作成します。

    my-catalog-source-cr.yaml ファイルの例

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: cs-redhat-operator-index
  namespace: openshift-marketplace
    1 
    
spec:
  image: registry.example.com/redhat/redhat-operator-index:v4.17
  sourceType: grpc
  displayName:
  publisher:
  updateStrategy:
    registryPoll:
      interval: 60m

    1
    グローバル namespace。metadata.namespace を openshift-marketplace に設定すると、カタログがすべての namespace で実行できるようになります。どの namespace のサブスクリプションでも、openshift-marketplace namespace で作成されたカタログを参照できます。
    注記

    openshift-marketplace のデフォルトの Pod セキュリティーアドミッション定義は baseline であるため、その namespace で作成されたカタログソースカスタムリソース (CR) では、spec.grpcPodConfig.securityContextConfig 値を設定する必要はありません。使用する namespace と Operator に必要な場合は、legacy または restricted 値を設定できます。

  2. 次の例のように、カタログインデックスコミットの SHA をカタログソース (CR) に追加します。

    namespace spec.image 設定の例

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: cs-redhat-operator-index
  namespace: openshift-marketplace
spec:
  image: registry.example.com/redhat/redhat-operator-index@sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6
    1 
    
  sourceType: grpc
  displayName:
  publisher:
  updateStrategy:
    registryPoll:
      interval: 60m

    1
    イメージコミットの SHA。Image Builder ブループリントに追加したものと同じ SHA を使用します。
    重要

    カタログ CR 内のタグの代わりに SHA を使用する必要があります。そうしないと、Pod の起動に失敗します。

  3. 次のコマンドを実行して、oc-mirror プラグインのドライラン results ディレクトリーから YAML ファイルをクラスターに適用します。 

    $ oc apply -f ./oc-mirror-workspace/results-1708508014/catalogSource-cs-redhat-operator-index.yaml

    出力例

    catalogsource.operators.coreos.com/cs-redhat-operator-index created

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

    $ oc get catalogsource --all-namespaces

  5. 次のコマンドを使用して、カタログソースが実行されていることを確認します。 

    $ oc get pods -n openshift-marketplace

    出力例

    NAME                             READY   STATUS    RESTARTS   AGE
cs-redhat-operator-index-4227b   2/2     Running   0          2m5s

  6. 次の例のような Subscription CR を作成します。

    my-subscription-cr.yaml ファイルの例

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: amq-broker
  namespace: openshift-operators
spec:
  channel: 7.11.x
  name: amq-broker-rhel8
  source: cs-redhat-operator-index
  sourceNamespace: openshift-marketplace

  7. 次のコマンドを実行して、Subscription CR を適用します。 

    $ oc apply -f ./<my-subscription-cr.yaml>
    1
    1
    my-subscription-cr.yaml など、Subscription CR の名前を指定します。

    出力例

    subscription.operators.coreos.com/amq-broker created

法律上の通知
リンクのコピー

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hatトップに戻る