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

アプリケーションの実行

Red Hat build of MicroShift 4.17

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 クラスターにデプロイできます。

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
      Copy to Clipboard Toggle word wrap
      1
      "/opt/alternative/path" を使用して各位置エントリーを正確なパスに設定するか、"/opt/alternative/path.d/*" を使用して glob パターンを設定します。

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

    manifests:
    kustomizePaths: []
    Copy to Clipboard Toggle word wrap
    注記

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

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

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

手順

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

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

      $ MANIFEST_DIR=/etc/microshift/manifests
      Copy to Clipboard Toggle word wrap

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

      $ sudo mkdir -p ${MANIFEST_DIR}
      Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap

  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
      Copy to Clipboard Toggle word wrap

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

    $ sudo systemctl restart microshift
    Copy to Clipboard Toggle word wrap

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

    $ oc get pods -n busybox
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.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
    Copy to Clipboard Toggle word wrap

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

    $ sudo composer-cli blueprints push <my_blueprint>.toml
    Copy to Clipboard Toggle word wrap

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

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

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

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

      [containers]
auth_file_path = "/<path>/pull-secret.json"
      1
      Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

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

4.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 をダウンロードし、使用できるように準備し、プロビジョニングして、エッジデバイスにインストールしました。

4.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 に埋め込まれます。

4.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
    Copy to Clipboard Toggle word wrap

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

    $ rpmdev-setuptree
    Copy to Clipboard Toggle word wrap

検証

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

    $ ls ~/rpmbuild/
    Copy to Clipboard Toggle word wrap

    出力例

    BUILD RPMS SOURCES SPECS SRPMS
    Copy to Clipboard Toggle word wrap

4.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>
    Copy to Clipboard Toggle word wrap

    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>
    Copy to Clipboard Toggle word wrap

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

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

前提条件

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

手順

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

    $ createrepo ~/rpmbuild/RPMS/
    Copy to Clipboard Toggle word wrap

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

    $ sudo chmod a+rx ~
    Copy to Clipboard Toggle word wrap
    注記

    イメージ構築に必要なすべてのファイルにアクセスするために必要なパーミッションが 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
    Copy to Clipboard Toggle word wrap
    1
    選択したロケーションを作成するパスの一部を指定します。後のコマンドでこのパスを使用して、リポジトリーを設定し、RPM をコピーします。

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

    $ sudo composer-cli sources add repo-local-rpmbuild.toml
    Copy to Clipboard Toggle word wrap

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

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

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

    $ sudo composer-cli blueprints push repo-local-rpmbuild.toml
    Copy to Clipboard Toggle word wrap

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

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

      $ sudo composer-cli compose start-ostree repo-local-rpmbuild edge-commit
      Copy to Clipboard Toggle word wrap

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

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

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

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

5.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 を再起動すると、クラッシュループを示している可能性があります。

5.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 変数値を変更して設定できます。

5.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 ディレクトリーに配置できます。

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

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

5.3.1.1. ヘルスチェックスクリプト作成の基本要件
リンクのコピー
  • ワークロードがインストールされている。
  • root アクセスがある。
5.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
Copy to Clipboard Toggle word wrap

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

前提条件

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

手順

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

    $ sudo reboot
    Copy to Clipboard Toggle word wrap

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

    $ sudo journalctl -o cat -u greenboot-healthcheck.service
    Copy to Clipboard Toggle word wrap
    注記

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

    出力例

    GRUB boot variables:
boot_success=0
boot_indeterminate=0
Greenboot variables:
GREENBOOT_WATCHDOG_CHECK_ENABLED=true
...
...
FINISHED
Script '40_microshift_running_check.sh' SUCCESS
Running Wanted Health Check Scripts...
Finished greenboot Health Checks Runner.
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

6.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
    Copy to Clipboard Toggle word wrap

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

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

検証

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

    $ oc get applications -A
    Copy to Clipboard Toggle word wrap

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

    出力例

    NAMESPACE          NAME               SYNC STATUS   HEALTH STATUS
openshift-gitops   spring-petclinic   Synced        Healthy
    Copy to Clipboard Toggle word wrap

6.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 では使用できません。

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

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

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

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

前提条件

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

手順

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

    $ oc adm inspect ns/openshift-gitops
    Copy to Clipboard Toggle word wrap

    出力例

    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.
    Copy to Clipboard Toggle word wrap

次のステップ

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

第7章 Pod のセキュリティー認証と認可
リンクのコピー

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

7.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 権限が使用される場合があります。ただし、自動ラベル付けではユーザー権限は考慮されません。

7.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>
    Copy to Clipboard Toggle word wrap

7.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
    Copy to Clipboard Toggle word wrap
注記

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

第8章 Operator
リンクのコピー

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

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

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

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

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

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

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

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

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

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

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

Operator Lifecycle Manager (OLM) パッケージマネージャーは、MicroShift でオプションの アドオン Operator をインストールおよび実行するために使用されます。

8.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 でサポートされていることをプロバイダーに確認してください。

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

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

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

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

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

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

Expand
表8.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 監視スコープが必要です。

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

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

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

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

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

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

重要

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

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

重要

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

8.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
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                            READY   STATUS    RESTARTS   AGE
olm-operator-85b5c6786-n6kbc    1/1     Running   0          2m24s
    Copy to Clipboard Toggle word wrap

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

    $ oc -n openshift-operator-lifecycle-manager get pod -l app=catalog-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                READY   STATUS    RESTARTS   AGE
catalog-operator-5fc7f857b6-tj8cf   1/1     Running   0          2m33s
    Copy to Clipboard Toggle word wrap

注記

次の手順では、グローバル 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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap
    1
    <catalog-source.yaml> をカタログソース設定ファイル名に置き換えます。この例では、catalogsource.yaml が使用されます。

    出力例

    catalogsource.operators.coreos.com/operatorhubio-catalog created
    Copy to Clipboard Toggle word wrap

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

    $ oc describe catalogsources.operators.coreos.com -n openshift-marketplace operatorhubio-catalog
    Copy to Clipboard Toggle word wrap

    出力例

    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>
    Copy to Clipboard Toggle word wrap

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

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

    $ oc get pods -n openshift-marketplace -l olm.catalogSource=operatorhubio-catalog
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                          READY   STATUS    RESTARTS   AGE
operatorhubio-catalog-x24nh   1/1     Running   0          59s
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

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

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

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

    出力例

    subscription.operators.coreos.com/my-cert-manager created
    Copy to Clipboard Toggle word wrap

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

検証

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

    $ oc get pods -n openshift-operators
    1
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

8.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
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                           READY   STATUS    RESTARTS   AGE
olm-operator-85b5c6786-n6kbc   1/1     Running   0          16m
    Copy to Clipboard Toggle word wrap

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

    $ oc -n openshift-operator-lifecycle-manager get pod -l app=catalog-operator
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                READY   STATUS    RESTARTS   AGE
catalog-operator-5fc7f857b6-tj8cf   1/1     Running   0          16m
    Copy to Clipboard Toggle word wrap

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

    namespace YAML の例

    apiVersion: v1
kind: Namespace
metadata:
  name: olm-microshift
    Copy to Clipboard Toggle word wrap

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

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

    出力例

    namespace/olm-microshift created
    Copy to Clipboard Toggle word wrap

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

    Operator グループ YAML の例

    kind: OperatorGroup
apiVersion: operators.coreos.com/v1
metadata:
  name: og
  namespace: olm-microshift
spec:
    1 
    
  targetNamespaces:
  - olm-microshift
    Copy to Clipboard Toggle word wrap

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

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

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

    出力例

    operatorgroup.operators.coreos.com/og created
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap
    1
    <catalog_source.yaml> をカタログソース設定ファイル名に置き換えます。

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

    $ oc describe catalogsources.operators.coreos.com -n openshift-marketplace operatorhubio-catalog
    Copy to Clipboard Toggle word wrap

    出力例

    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>
    Copy to Clipboard Toggle word wrap

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

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

    $ oc get pods -n openshift-marketplace -l olm.catalogSource=operatorhubio-catalog
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                          READY   STATUS    RESTARTS   AGE
operatorhubio-catalog-j7sc8   1/1     Running   0          43s
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap
    1
    <subscription_cr.yaml> を Subscription CR 設定ファイルの名前に置き換えます。

    出力例

    subscription.operators.coreos.com/my-gitlab-operator-kubernetes
    Copy to Clipboard Toggle word wrap

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

検証

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

    $ oc get pods -n olm-microshift
    1
    Copy to Clipboard Toggle word wrap
    1
    Subscription CR の namespace が使用されます。
    注記

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

    出力例

    NAME                                         READY   STATUS    RESTARTS   AGE
gitlab-controller-manager-69bb6df7d6-g7ntx   2/2     Running   0          3m24s
    Copy to Clipboard Toggle word wrap

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

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

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

oc-mirror OpenShift CLI (oc) プラグインを使用して、カタログをフィルタリングおよびプルーニングし、特定の Operators を取得して、それらをミラーリングできます。Operator は、非接続設定で使用したり、Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージに組み込んで使用することもできます。システムをミラーリング用に設定する方法の詳細は、以下の「関連情報」セクションのリンクを参照してください。Red Hat が提供する Operator カタログから Operator をデプロイし、それらをミラーリングするか、または RHEL for Edge イメージに埋め込む準備ができている場合は、以下の "oc-mirror プラグインを使用したカタログ内容の検査" セクションから始めてください。

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

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

注記

MicroShift は、oc-mirror プラグインの一般公開バージョン (1) を使用します。oc-mirror プラグインのテクニカルプレビューバージョン (2) では、以下の手順を使用しないでください。

目的の Operators に必要なコンテナーイメージをローカルにミラーリングすることも、Red Hat Quay などの Docker v2-2 をサポートするコンテナーミラーレジストリーにミラーリングすることもできます。インターネットに接続された Red Hat がホストするレジストリーから、非接続イメージレジストリーにコンテンツをミラーリングする手順は、選択したレジストリーに関係なく同じです。カタログの内容をミラーリングした後、ミラーレジストリーからこのコンテンツを取得するように各クラスターを設定します。

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

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

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

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

重要

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

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

  • ミラーレジストリーを高可用性の方法で実行します。
  • ミラーレジストリーが少なくともクラスターの製品可用性と一致していることを確認します。
8.3.2.2. oc-mirror プラグインを使用したカタログ内容の検査
リンクのコピー

次の例の手順を使用して、カタログを選択し、利用可能な OpenShift Container Platform コンテンツから Operators をリストして、oc-mirror プラグインイメージセット設定ファイルに追加します。

注記

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

前提条件

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

手順

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

    $ oc mirror list operators --version 4.17 --catalogs
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、Red Hat Operators カタログ内の Operators のリストを取得します。 

    $ oc mirror list operators <--catalog=<catalog_source>>
    1
    Copy to Clipboard Toggle word wrap
    1
    registry.redhat.io/redhat/redhat-operator-index:v4.17 または quay.io/operatorhubio/catalog:latest などのカタログソースを指定します。
  3. Operator を選択します。この例では、amq-broker-rhel8 が選択されています。

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

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

      $ oc mirror list operators --catalog=registry.redhat.io/redhat/redhat-operator-index:v4.17 --package=amq-broker-rhel8
      Copy to Clipboard Toggle word wrap

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

      $ oc mirror list operators --catalog=registry.redhat.io/redhat/redhat-operator-index:v4.17 --package=amq-broker-rhel8 --channel=7.11.x
      Copy to Clipboard Toggle word wrap

次のステップ

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

oc-mirror プラグインを使用してカタログの内容をミラーリングするには、イメージセット設定ファイルを作成する必要があります。イメージセット設定ファイルは、oc-mirror プラグインのその他の設定とともに、ミラーリングする Operator を定義します。デフォルトのイメージセットファイルを生成した後、残りのエントリーが MicroShift と使用予定の Operator の両方と互換性を持つように内容を編集する必要があります。

イメージセット設定ファイルでストレージバックエンドを指定する必要があります。このストレージバックエンドは、Docker v2-2 をサポートするローカルディレクトリーまたはレジストリーにすることができます。oc-mirror プラグインは、イメージセットの作成中にこのストレージバックエンドにメタデータを保存します。

重要

oc-mirror プラグインによって生成されたメタデータを削除または変更しないでください。同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、同じストレージバックエンドを使用する必要があります。

前提条件

手順

  1. oc mirror init コマンドを使用して、イメージセット設定のテンプレートを作成し、それを imageset-config.yaml というファイルに保存します。 

    $ oc mirror init --registry <storage_backend> > imageset-config.yaml
    1
    Copy to Clipboard Toggle word wrap
    1
    ストレージバックエンドのロケーションを指定します (例: example.com/mirror/oc-mirror-metadata)。

    デフォルトのイメージセット設定ファイルの例

    kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
  registry:
    imageURL: registry.example.com/oc-mirror
    skipTLS: false
mirror:
  platform:
    1 
    
    channels:
    - name: stable-4.17
      type: ocp
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17
    packages:
    - name: serverless-operator
      channels:
      - name: stable
  additionalImages:
    2 
    
  - name: registry.redhat.io/ubi8/ubi:latest
  helm: {}
    3
    Copy to Clipboard Toggle word wrap

    1
    platform フィールドと関連フィールドは MicroShift ではサポートされていないため、削除する必要があります。
    2
    イメージセットに含める追加のイメージを指定します。追加のイメージを指定する必要がない場合は、このフィールドを削除してください。
    3
    Helm は MicroShift ではサポートされていないため、削除する必要があります。

  2. 次の例のように、MicroShift とミラーリングする Operator の両方の要件を満たすようにイメージセット設定ファイルの値を編集します。

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

    kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
    1 
    
  registry:
    imageURL: <storage_backend>
    2 
    
    skipTLS: false
mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17
    3 
    
    packages:
    - name: amq-broker-rhel8
    4 
    
      channels:
      - name: 7.11.x
    5
    Copy to Clipboard Toggle word wrap

    1
    イメージセットのメタデータが保存されるバックエンドのロケーションを設定します。この場所は、レジストリーまたはローカルディレクトリーにすることができます。storageConfig値を指定する必要があります。
    2
    ストレージバックエンドのレジストリー URL (例: <example.com/mirror/oc-mirror-metadata) を設定します。
    3
    イメージを取得する Operator カタログを設定します。
    4
    イメージセットに含める Operator パッケージを指定します。カタログ内のすべてのパッケージを取得するには、このフィールドを削除してください。
    5
    イメージセットに含める Operator パッケージの特定のチャネルのみを指定します。そのチャネルでバンドルを使用しない場合も、常に Operator パッケージのデフォルトチャネルを含める必要があります。oc mirror list operators --catalog=<catalog_name> --package=<package_name> コマンドを実行すると、デフォルトチャネルを見つけることができます。
  3. 更新したファイルを保存します。

次のステップ

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

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

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

apiVersion

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

String。例: mirror.openshift.io/v1alpha2

mirror

イメージセットの設定。

オブジェクト

mirror.additionalImages

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

オブジェクトの配列。以下に例を示します。 

additionalImages:
  - name: registry.redhat.io/ubi8/ubi:latest
Copy to Clipboard Toggle word wrap

mirror.additionalImages.name

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

String。例: registry.redhat.io/ubi8/ubi:latest

mirror.blockedImages

ミラーリングからブロックするイメージの完全なタグ、ダイジェスト、またはパターン。

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

mirror.operators

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

オブジェクトの配列。以下に例を示します。 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17
    packages:
      - name: elasticsearch-operator
        minVersion: '2.4.0'
Copy to Clipboard Toggle word wrap

mirror.operators.catalog

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

String。たとえば、registry.redhat.io/redhat/redhat-operator-index:v4.17 です。

mirror.operators.full

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

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

mirror.operators.packages

Operator パッケージ設定

オブジェクトの配列。以下に例を示します。 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17
    packages:
      - name: elasticsearch-operator
        minVersion: '5.2.3-31'
Copy to Clipboard Toggle word wrap

mirror.operators.packages.name

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

String。例: elasticsearch-operator

mirror.operators.packages.channels

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

オブジェクト

mirror.operators.packages.channels.name

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

String。たとえば、fast または stable-v4.17 です。

mirror.operators.packages.channels.maxVersion

Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。詳細は、以下の注記を参照してください。

String。例: 5.2.3-31

mirror.operators.packages.channels.minBundle

含める最小バンドルの名前と、チャネルヘッドへの更新グラフ内のすべてのバンドル。名前付きバンドルにセマンティックバージョンメタデータがない場合にのみ、このフィールドを設定します。

String。例： bundleName

mirror.operators.packages.channels.minVersion

存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。詳細は、以下の注記を参照してください。

String。例: 5.2.3-31

mirror.operators.packages.maxVersion

Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。詳細は、以下の注記を参照してください。

String。例: 5.2.3-31。

mirror.operators.packages.minVersion

存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。詳細は、以下の注記を参照してください。

String。例: 5.2.3-31。

mirror.operators.skipDependencies

true の場合、バンドルの依存関係は含まれません。

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

mirror.operators.targetCatalog

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

String。例: my-namespace/my-operator-catalog

mirror.operators.targetName

参照されたカタログをミラーリングするための代替名。

targetName パラメーターは非推奨になりました。代わりに targetCatalog パラメーターを使用してください。

String。例： my-operator-catalog

mirror.operators.targetTag

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

String。例: v1

storageConfig

イメージセットのバックエンド設定。

オブジェクト

storageConfig.local

イメージセットのローカルバックエンド設定。

オブジェクト

storageConfig.local.path

イメージセットのメタデータを含むディレクトリーのパス。

String。例: ./path/to/dir/

storageConfig.registry

イメージセットのレジストリーバックエンド設定。

オブジェクト

storageConfig.registry.imageURL

バックエンドレジストリー URI。オプションで、URI に namespace 参照を含めることができます。

String。例: quay.io/myuser/imageset:metadata

storageConfig.registry.skipTLS

オプションで、参照されるバックエンドレジストリーの TLS 検証をスキップします。

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

注記

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

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

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

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

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

イメージセット設定ファイルでストレージバックエンドを指定する必要があります。このストレージバックエンドは、ローカルディレクトリーまたは Dockerv2 レジストリーにすることができます。oc-mirror プラグインは、イメージセットの作成中にこのストレージバックエンドにメタデータを保存します。

重要

oc-mirror プラグインによって生成されたメタデータを削除または変更しないでください。同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、同じストレージバックエンドを使用する必要があります。

前提条件

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

手順

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

    $ oc mirror --config=./<imageset-config.yaml> \
    1 
    
  docker://registry.example:5000
    2
    Copy to Clipboard Toggle word wrap
    1
    作成したイメージセット設定ファイルを指定します。たとえば、imageset-config.yaml です。
    2
    イメージセットファイルをミラーリングするレジストリーを指定します。レジストリーは docker:// で始まる必要があります。ミラーレジストリーに最上位の namespace を指定する場合は、これ以降の実行でもこれと同じ namespace を使用する必要があります。

出力例

Rendering catalog image "registry.example.com/redhat/redhat-operator-index:v{ocp-version}" with file-based catalog
Copy to Clipboard Toggle word wrap

検証

  1. 生成された oc-mirror-workspace/ ディレクトリーに移動します。
  2. results ディレクトリーに移動します (例: results-1639608409/。
  3. ImageContentSourcePolicy および CatalogSource リソースに YAML ファイルが存在することを確認します。
重要

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

次のステップ

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

トラブルシューティング

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

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

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • Operator Lifecycle Manager (OLM) がインストールされている。
  • oc-mirror OpenShift CLI (oc) プラグインがインストールされている。
  • yq バイナリーがインストールされている。
  • ImageContentSourcePolicy および CatalogSource YAML ファイルは、oc-mirror-workspace/results-* ディレクトリーにあります。

手順

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

    $ cat oc-mirror-workspace/<results-directory>/imageContentSourcePolicy.yaml
    1
    Copy to Clipboard Toggle word wrap
    1
    <results-1707148826> などの results ディレクトリー名を指定します。

    出力例

    apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  labels:
    operators.openshift.org/catalog: "true"
  name: operator-0
spec:
  repositoryDigestMirrors:
  - mirrors:
    - registry.<example.com>/amq7
    source: registry.redhat.io/amq7
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、imageContentSourcePolicy.yaml を CRI-O 設定に適した形式に変換します。 

    yq '.spec.repositoryDigestMirrors[] as $item ireduce([]; . + [{"mirror": $item.mirrors[], "source": ($item | .source)}]) | .[] |
  "[[registry]]
      prefix = \"" + .source + "\"
      location = \"" + .mirror + "\"
      mirror-by-digest-only = true
      insecure = true
      "' ./icsp.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    [[registry]]
      prefix = "registry.redhat.io/amq7"
      location = "registry.example.com/amq7"
      mirror-by-digest-only = true
      insecure = true
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    1
    ミラーレジストリーサーバーのホスト名とポートを指定します (例: microshift-quay:8443)。

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

    $ sudo systemctl restart crio
    Copy to Clipboard Toggle word wrap
8.3.2.6. oc-mirror プラグインで作成されたカスタムカタログのインストール
リンクのコピー

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

前提条件

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

手順

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

    $ oc apply -f ./oc-mirror-workspace/results-1708508014/catalogSource-cs-redhat-operator-index.yaml
    Copy to Clipboard Toggle word wrap

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

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: redhat-catalog
  namespace: openshift-marketplace
    1 
    
spec:
  sourceType: grpc
  image: registry.example.com/redhat/redhat-operator-index:v4.17
  updateStrategy:
    registryPoll:
      interval: 60m
    Copy to Clipboard Toggle word wrap

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

    出力例

    catalogsource.operators.coreos.com/cs-redhat-operator-index created
    Copy to Clipboard Toggle word wrap

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

    $ oc get catalogsource --all-namespaces
    Copy to Clipboard Toggle word wrap

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

    $ oc get pods -n openshift-marketplace
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             READY   STATUS    RESTARTS   AGE
cs-redhat-operator-index-4227b   2/2     Running   0          2m5s
    Copy to Clipboard Toggle word wrap

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

    Subscription CR の例

    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
    Copy to Clipboard Toggle word wrap

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

    $ oc apply -f ./<my-subscription-cr.yaml>
    1
    Copy to Clipboard Toggle word wrap
    1
    サブスクリプションの名前 (my-subscription-cr.yaml など) を指定します。

    出力例

    subscription.operators.coreos.com/amq-broker created
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

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

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

実際にイメージをミラーリングせずに、oc-mirror を使用してドライランを実行できます。これにより、ミラーリングされるイメージのリストと、ミラーレジストリーからプルーニングされるイメージを確認できます。ドライランを使用すると、イメージセット設定のエラーを早期に検出したり、生成されたイメージリストを他のツールで使用してミラーリング操作を実行したりすることもできます。

前提条件

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

手順

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

    $ oc mirror --config=./imageset-config.yaml \
    1 
    
  docker://registry.example:5000            \
    2 
    
  --dry-run
    3
    Copy to Clipboard Toggle word wrap
    1
    作成されたイメージセット設定ファイルを渡します。この手順では、imageset-config.yaml という名前であることを前提としています。
    2
    ミラーレジストリーを指定します。--dry-run フラグを使用している限り、このレジストリーには何もミラーリングされません。
    3
    --dry-run フラグを使用して、実際のイメージセットファイルではなく、ドライランアーティファクトを生成します。

    出力例

    Checking push permissions for registry.example:5000
Creating directory: oc-mirror-workspace/src/publish
Creating directory: oc-mirror-workspace/src/v2
Creating directory: oc-mirror-workspace/src/charts
Creating directory: oc-mirror-workspace/src/release-signatures
No metadata detected, creating new workspace
wrote mirroring manifests to oc-mirror-workspace/operators.1658342351/manifests-redhat-operator-index

...

info: Planning completed in 31.48s
info: Dry run complete
Writing image mapping to oc-mirror-workspace/mapping.txt
    Copy to Clipboard Toggle word wrap

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

    $ cd oc-mirror-workspace/
    Copy to Clipboard Toggle word wrap

  3. 生成された mapping.txt ファイルを確認します。

    このファイルには、ミラーリングされるすべてのイメージのリストが含まれています。

  4. 生成された pruning-plan.json ファイルを確認します。

    このファイルには、イメージセットの公開時にミラーレジストリーからプルーニングされるすべてのイメージのリストが含まれています。

    注記

    pruning-plan.json ファイルは、oc-mirror コマンドがミラーレジストリーを指し、プルーニングするイメージがある場合にのみ生成されます。

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

注記

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

前提条件

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

手順

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

    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.17/index/index.json
      Copy to Clipboard Toggle word wrap

    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.17/index/index.json
      Copy to Clipboard Toggle word wrap
      注記

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

      イメージ参照出力の例

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

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

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

[[containers]]
source = "registry.redhat.io/amq7/amq-broker-rhel8@sha256:ff6fefad518a6c997d4c5a6e475ba89640260167f0bc27715daf3cc30116fad1"
…
EOF
      Copy to Clipboard Toggle word wrap

      重要

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

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

    $ cat imageset-config.yaml
    Copy to Clipboard Toggle word wrap

    出力例

    kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
  registry:
    imageURL: registry.example.com/microshift-mirror
mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17
    1 
    
    packages:
    - name: amq-broker-rhel8
      channels:
      - name: 7.11.x
    Copy to Clipboard Toggle word wrap

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

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

    $ skopeo inspect docker://<registry.redhat.io/redhat/redhat-operator-index:v4.17> | jq `.Digest`
    1
    Copy to Clipboard Toggle word wrap
    1
    イメージダイジェストを取得するには、jq コマンドの mirror.catalog カタログイメージ参照の値を使用します。この例では、<registry.redhat.io/redhat/redhat-operator-index:v4.17> になります。

    出力例

    "sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6"
    Copy to Clipboard Toggle word wrap

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

    [[containers]]
source = "registry.redhat.io/redhat/redhat-operator-index@sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6"
    Copy to Clipboard Toggle word wrap

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

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

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

[[packages]]
    1 
    
name = "microshift"
version = "4.17.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/amq7/amq-broker-init-rhel8@sha256:0dde839c2dce7cb684094bf26523c8e16677de03149a0fff468b8c3f106e1f4f"
...
...

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

[[containers]]
source = "registry.redhat.io/amq7/amq-broker-rhel8@sha256:ff6fefad518a6c997d4c5a6e475ba89640260167f0bc27715daf3cc30116fad1"
…
EOF
    Copy to Clipboard Toggle word wrap

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

    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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

    出力例

    catalogsource.operators.coreos.com/cs-redhat-operator-index created
    Copy to Clipboard Toggle word wrap

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

    $ oc get catalogsource --all-namespaces
    Copy to Clipboard Toggle word wrap

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

    $ oc get pods -n openshift-marketplace
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             READY   STATUS    RESTARTS   AGE
cs-redhat-operator-index-4227b   2/2     Running   0          2m5s
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

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

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

    出力例

    subscription.operators.coreos.com/amq-broker created
    Copy to Clipboard Toggle word wrap

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

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

© 2025 Red Hat