アプリケーションの実行
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 ワークロードを管理できるようになります。
場所 | 目的 |
---|---|
| 設定管理システムまたは開発用の読み取り/書き込みの場所。 |
| 設定管理システムまたは開発用の読み取り/書き込みの場所。 |
| OSTree ベースのシステムに設定マニフェストを埋め込むための読み取り専用の場所。 |
| OSTree ベースのシステムに設定マニフェストを埋め込むための読み取り専用の場所。 |
1.2. マニフェストパスリストのオーバーライド
新しい単一パスを使用するか、複数のファイルに新しい glob パターンを使用することで、デフォルトのマニフェストパスのリストをオーバーライドできます。マニフェストパスをカスタマイズするには、次の手順を使用します。
手順
独自の値を挿入し、以下のコマンドのいずれかを実行して、デフォルトパスのリストを上書きします。
-
単一パスの設定ファイルで
manifests.kustomizePaths
を<"/opt/alternate/path">
に設定します。 glob パターンの設定ファイルで
kustomizePaths
を,"/opt/alternative/path.d/*".
に設定します。manifests: kustomizePaths: - <location> 1
- 1
"/opt/alternative/path"
を使用して各位置エントリーを正確なパスに設定するか、"/opt/alternative/path.d/*"
を使用して glob パターンを設定します。
-
単一パスの設定ファイルで
マニフェストの読み込みを無効にするには、設定オプションを空のリストに設定します。
manifests: kustomizePaths: []
注記設定ファイルはデフォルトを完全にオーバーライドします。
kustomizePaths
値が設定されている場合は、設定ファイル内の値のみが使用されます。値を空のリストに設定すると、マニフェストの読み込みが無効になります。
1.3. マニフェストの使用例
この例では、/etc/microshift/manifests
ディレクトリー内の kustomize
マニフェストを使用した BusyBox コンテナーの自動デプロイを示します。
手順
次のコマンドを実行して、BusyBox マニフェストファイルを作成します。
ディレクトリーの場所を定義します。
$ MANIFEST_DIR=/etc/microshift/manifests
ディレクトリーを作成します。
$ sudo mkdir -p ${MANIFEST_DIR}
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
次に、以下のコマンドを実行して
kustomize
マニフェストファイルを作成します。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
次のコマンドを実行して MicroShift を再起動し、マニフェストを適用します。
$ sudo systemctl restart microshift
次のコマンドを実行して、マニフェストを適用し、
busybox
Pod を起動します。$ oc get pods -n busybox
第2章 RHEL for Edge イメージに MicroShift アプリケーションを埋め込む方法
マイクロサービスベースのワークロードとアプリケーションを 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. オフラインで使用するためのアプリケーションの埋め込み
アプリケーションに複数のファイルが含まれている場合は、オフラインで使用できるようにアプリケーションを埋め込むことができます。以下の手順を参照してください。
2.4. 関連情報
第3章 オフラインで使用するためのアプリケーションの埋め込み
マイクロサービスベースのワークロードとアプリケーションを Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージに埋め込むことができます。埋め込みを行うと、エアギャップ環境、非接続環境、またはオフライン環境で Red Hat build of MicroShift クラスターを実行できます。
3.1. オフラインで使用するためのワークロードコンテナーイメージの埋め込み
ネットワーク接続がないエッジのデバイスにコンテナーイメージを埋め込むには、新しいコンテナーを作成し、ISO をマウントして、コンテンツをファイルシステムにコピーする必要があります。
前提条件
- ホストへの root アクセス権限がある。
- アプリケーション RPM がブループリントに追加されている。
-
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、マニフェストをレンダリングし、すべてのコンテナーイメージ参照を抽出し、アプリケーションイメージをブループリントコンテナーソースに変換します。
$ oc kustomize ~/manifests | grep "image:" | grep -oE '[^ ]+$' | while read line; do echo -e "[[containers]]\nsource = \"${line}\"\n"; done >><my_blueprint>.toml
次のコマンドを実行して、更新されたブループリントを Image Builder にプッシュします。
$ sudo composer-cli blueprints push <my_blueprint>.toml
ワークロードコンテナーがプライベートリポジトリーにある場合は、Image Builder に必要なプルシークレットを提供する必要があります。
-
/etc/osbuild-worker/osbuild-worker.toml
ファイル内のosbuilder worker
設定の[containers]
セクションにあるauth_file_path
を、プルシークレットを指すように設定します。 必要に応じて以下のように、プルシークレットのディレクトリーおよびファイルを作成します。
ディレクトリーとファイルの例
[containers] auth_file_path = "/<path>/pull-secret.json" 1
- 1
- イメージのコピーおよび取得には、以前に設定したカスタムの場所を使用します。
-
以下のコマンドを実行し、コンテナーイメージをビルドします。
$ sudo composer-cli compose start-ostree <my_blueprint> edge-commit
-
ビルドの完了待ち、イメージのエクスポート、
rpm-ostree
リポジトリーへの統合、ブータブル ISO の作成など、任意のrpm-ostree
イメージフローに進みます。
3.2. 関連情報
第4章 Red Hat build of 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 の埋め込みワークフロー
次の手順を再確認すると、アプリケーションの埋め込みに必要な手順を理解するのに役立ちます。
- MicroShift を RHEL for Edge に埋め込むために、MicroShift リポジトリーを Image Builder に追加しました。
- MicroShift の追加など、必要なすべての RPM、コンテナーイメージ、ファイル、およびカスタマイズを宣言するブループリントを作成しました。
-
ブループリントを Image Builder に追加し、Image Builder CLI ツール (
composer-cli
) を使用してビルドを実行しました。この手順では、コンテナーイメージの作成に使用されるrpm-ostree
コミットを作成しました。このイメージには RHEL for Edge が含まれていました。 -
インストーラーブループリントを Image Builder に追加して、起動元の
rpm-ostree
イメージ (ISO) を作成しました。このビルドには、RHEL for Edge と MicroShift の両方が含まれていました。 - MicroShift が埋め込まれた ISO をダウンロードし、使用できるように準備し、プロビジョニングして、エッジデバイスにインストールしました。
4.1.2. アプリケーション RPM の埋め込みワークフロー
Image Builder の要件を満たすビルドホストを設定したら、マニフェストのディレクトリーの形式でアプリケーションをイメージに追加できます。これらの手順の後、アプリケーションまたはワークロードを新しい ISO に埋め込む最も簡単な方法は、マニフェストを含む独自の RPM を作成します。アプリケーションの RPM には、デプロイメントを記述するすべての設定ファイルが含まれています。
次の「アプリケーションの埋め込みワークフロー」の画像は、Kubernetes アプリケーションマニフェストと RPM 仕様ファイルが単一のアプリケーション RPM ビルドにどのように組み合わされるかを示しています。このビルドは、MicroShift を ostree コミットに埋め込むワークフローで使用する RPM アーティファクトになります。
アプリケーションの埋め込みワークフロー
以下の手順では、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 アクセス権限がある。
手順
rpmbuild
ツールをインストールし、以下のコマンドを実行してその yum リポジトリーを作成します。$ sudo dnf install rpmdevtools rpmlint yum-utils createrepo
次のコマンドを実行して、RPM パッケージの構築に必要なファイルツリーを作成します。
$ rpmdev-setuptree
検証
次のコマンドを実行して、ディレクトリーを一覧表示して作成を確認します。
$ ls ~/rpmbuild/
出力例
BUILD RPMS SOURCES SPECS SRPMS
4.1.4. アプリケーションマニフェストの RPM パッケージの構築
独自の RPM を構築するには、アプリケーションマニフェストを RPM パッケージに追加する仕様ファイルを作成する必要があります。以下に手順の例を示します。イメージ構築に必要なアプリケーション RPM およびその他の要素が Image Builder にアクセスできる限り、任意の方法を使用できます。
前提条件
- Image Builder のシステム要件を満たす Red Hat Enterprise Linux for Edge (RHEL for Edge) 9.4 ビルドホストを設定している。
- ホストへの root アクセス権限がある。
- RPM パッケージの構築に必要なファイルツリーが作成されている。
手順
~/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
ファイルも含まれます)。以下のコマンドを実行して、
~/rpmbuild/RPMS
ディレクトリーに RPM パッケージをビルドします。$ rpmbuild -bb ~/rpmbuild/SPECS/<application_workload_manifests.spec>
4.1.5. ブループリントへのアプリケーション RPM の追加
アプリケーション RPM をブループリントに追加するには、Image Builder が ISO の作成に使用できるローカルリポジトリーを作成する必要があります。この手順では、ワークロードに必要なコンテナーイメージをネットワーク経由でプルできます。
前提条件
- ホストへの root アクセス権限がある。
-
ワークロードまたはアプリケーション RPM が
~/rpmbuild/RPMS
ディレクトリーにある。
手順
次のコマンドを実行して、ローカル RPM リポジトリーを作成します。
$ createrepo ~/rpmbuild/RPMS/
次のコマンドを実行して、Image Builder に RPM リポジトリーへのアクセス権限を付与します。
$ sudo chmod a+rx ~
注記イメージ構築に必要なファイル全てにアクセスする必須のパーミッションが Image Builder に割り当てられている必要があります。そうでないと、ビルドを続行できません。
次のテンプレートを使用して、ブループリントファイル
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 をコピーします。
次のコマンドを実行して、Image Builder のソースとしてリポジトリーを追加します。
$ sudo composer-cli sources add repo-local-rpmbuild.toml
以下の行を追加して、RPM をブループリントに追加します。
… [[packages]] name = "<application_workload_manifests>" 1 version = "*" …
- 1
- ワークロードの名前をここに追加します。
次のコマンドを実行して、更新されたブループリントを Image Builder にプッシュします。
$ sudo composer-cli blueprints push repo-local-rpmbuild.toml
この時点で、Image Builder を実行して ISO を作成するか、オフラインで使用するためにコンテナーイメージを埋め込むことができます。
ISO を作成するには、次のコマンドを実行して Image Builder を起動します。
$ sudo composer-cli compose start-ostree repo-local-rpmbuild edge-commit
このシナリオでは、起動時にエッジデバイスによってネットワーク経由でコンテナーイメージがプルされます。
4.2. 関連情報
第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
5.4. ワークロードヘルスチェックスクリプトのテスト
前提条件
- root アクセスがある。
- ワークロードがインストールされている。
- ワークロードのヘルスチェックスクリプトを作成している。
- Red Hat build of MicroShift サービスが有効である。
手順
Greenboot がヘルスチェックスクリプトファイルを実行していることをテストするには、次のコマンドを実行してホストを再起動します。
$ sudo reboot
次のコマンドを実行して、Greenboot ヘルスチェックの出力を調べます。
$ sudo journalctl -o cat -u greenboot-healthcheck.service
注記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.
5.5. 関連情報
第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 で実行されている。
手順
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
YAML ファイルで定義されたアプリケーションをデプロイするには、次のコマンドを実行します。
$ oc apply -f <my-app>.yaml 1
- 1
- <my-app> はアプリケーション YAML の名前に置き換えます。
検証
アプリケーションがデプロイされ、同期されていることを確認するには、次のコマンドを実行します。
$ oc get applications -A
アプリケーションが
Healthy
ステータスを表示するまで数分かかる場合があります。出力例
NAMESPACE NAME SYNC STATUS HEALTH STATUS openshift-gitops spring-petclinic Synced Healthy
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
コマンドラインツールがインストールされている。
手順
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 レポートを実行できます。
6.5. 関連情報
- RPM パッケージからの GitOps Argo CD マニフェストのインストール
- sos レポートの使用
- Red Hat OpenShift GitOps
- テクニカルサポート用の SOS レポートの生成 (Red Hat Enterprise Linux)
第7章 Pod のセキュリティー認証と認可
7.1. Pod セキュリティーアドミッションの理解と管理
Pod セキュリティーアドミッションは、Kubernetes Pod セキュリティー標準 の実装です。Pod のセキュリティーアドミッションを使用して、Pod の動作を制限します。
7.2. 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.2.1. namespace での Security Context Constraints の表示
特定の namespace の Security Context Constraints (SCC) 権限を表示できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。
手順
namespace の SCC (Security Context Constraints) を表示するには、以下のコマンドを実行します。
oc get --show-labels namespace <namespace>
7.3. 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 セキュリティーラベルの同期の影響を元に戻すことができます。
第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 をインストールするには、同じ手順を使用します。
- 詳細は、Kustomize マニフェストを使用したアプリケーションのデプロイ および マニフェスト例の使用 を参照してください。
8.1.1.2. Operator 向けの Operator Lifecycle Manager
Operator Lifecycle Manager (OLM) を使用して、アドオン Operator を MicroShift クラスターにインストールすることもできます。OLM を使用すると、カスタム Operator と広く利用可能な Operator の両方を管理できます。MicroShift で OLM を使用するには、カタログをビルドする必要があります。
- 詳細は、MicroShift での Operator Lifecycle Manager の使用 を参照してください。
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
がクラスターに追加されている必要があります。
-
OLM カタログ Operator がカタログをコンテンツに使用できるように、各カタログにはアクセス可能な
MicroShift で OLM アクティビティーを実行するには、CLI を使用する必要があります。コンソールと OperatorHub GUI は使用できません。
-
Operator Package Manager
opm
CLI は、ネットワーク接続されたクラスターで使用するか、内部レジストリーを使用するカスタム Operator のカタログをビルドするために使用します。 - 非接続クラスターまたはオフラインのクラスターのカタログと Operator をミラーリングするには、oc-mirror OpenShift CLI プラグイン をインストールします。
-
Operator Package Manager
Operator を使用する前に、Operator が Red Hat build of MicroShift でサポートされていることをプロバイダーに確認してください。
8.2.2. OLM インストールタイプの決定
OLM パッケージマネージャーをインストールして、MicroShift 4.15 以降のバージョンで使用できます。MicroShift クラスター用の OLM をインストールするには、ユースケースに応じてさまざまな方法があります。
-
Red Hat Enterprise Linux (RHEL) に MicroShift RPM をインストールするときに、
microshift-olm
RPM を同時にインストールできます。 -
microshift-olm
は既存の MicroShift 4.16 にインストールできます。変更を適用するには、OLM をインストールした後、MicroShift サービスを再起動します。RPM パッケージからの Operator Lifecycle Manager (OLM) のインストール を参照してください。 - OLM を Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージに埋め込むことができます。Operator Lifecycle Manager (OLM) サービスのブループリントへの追加 を参照してください。
8.2.3. MicroShift での namespace の使用
microshift-olm
RPM は 3 つのデフォルトの namespace を作成します。1 つは OLM の実行用で、2 つはカタログと Operator のインストール用です。ユースケースでの必要性に応じて、追加の namespace を作成できます。
8.2.3.1. デフォルトの namespace
次の表に、デフォルトの namespace と、各 namespace の動作の簡単な説明が示されています。
デフォルトの namespace | 詳細 |
| OLM パッケージマネージャーは、この namespace で実行されます。 |
|
グローバル namespace。デフォルトでは空です。カタログソースをすべての namespace のユーザーがグローバルに利用できるようにするには、カタログソース YAML で |
|
MicroShift で Operator が実行されるデフォルトの namespace。 |
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 を実行するには、ファイルベースのカタログ構造を使用してカタログを作成します。
- 詳細は、カスタムカタログの管理 および サンプルカタログ を参照してください。
-
opm
CLI 参照 も参照してください。
-
カタログソースをクラスターに追加する ときは、
catalogSource.yaml
ファイルでsecurityContextConfig
値をrestricted
に設定します。カタログがrestricted
権限で実行できることを確認してください。
関連情報
-
opm
CLI リファレンス - Operator カタログについて
-
opm
CLI を使用してファイルベースのカタログを作成するには、カスタムカタログの管理 を参照してください。
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
ブループリントに埋め込む必要があります。
関連情報
8.2.5.2. グローバル namespace を使用したネットワーククラスターへの OLM ベースの Operator の追加
異なる 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 にカスタムカタログを作成している。
手順
次のコマンドを使用して、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
次のコマンドを使用して、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 モードをサポートする必要があります。
次のサンプル 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
に設定する必要があります。
次のコマンドを実行して、
CatalogSource
設定を適用します。$ oc apply -f <my-catalog-source.yaml> 1
- 1
<my-catalog-source.yaml>
をカタログソース設定ファイル名に置き換えます。この例では、catalogsource.yaml
が使用されます。
出力例
catalogsource.operators.coreos.com/operatorhubio-catalog created
カタログソースが適用されていることを確認するには、次のコマンドを使用して
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
と報告されます。
次のコマンドを使用して、カタログソースが実行されていることを確認します。
$ oc get pods -n openshift-marketplace -l olm.catalogSource=operatorhubio-catalog
出力例
NAME READY STATUS RESTARTS AGE operatorhubio-catalog-x24nh 1/1 Running 0 59s
次の 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 で実行できるようになります。
次のコマンドを実行して、Subscription CR 設定を適用します。
$ oc apply -f <my-subscription-cr.yaml> 1
- 1
<my-subscription-cr.yaml>
を Subscription CR ファイル名に置き換えます。この例では、sub.yaml
が使用されます。
出力例
subscription.operators.coreos.com/my-cert-manager created
- 使用する特定のオペランドの設定ファイルを作成し、今すぐ適用できます。
検証
次のコマンドを使用して、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
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 で実行中のカスタムカタログが作成されている。
手順
次のコマンドを使用して、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
次のコマンドを使用して、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
次の YAML 例を使用して、namespace を作成します。
namespace YAML の例
apiVersion: v1 kind: Namespace metadata: name: olm-microshift
次のコマンドを使用して、namespace 設定を適用します。
$ oc apply -f _<ns.yaml>_ 1
- 1
- <ns.yaml> を namespace 設定ファイルの名前に置き換えます。この例では、
olm-microshift
が使用されます。
出力例
namespace/olm-microshift created
次の 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
フィールドと値を省略します。
次のコマンドを実行して、Operator グループ設定を適用します。
$ oc apply -f _<og.yaml>_ 1
- 1
- <og.yaml> を Operator グループ設定ファイルの名前に置き換えます。
出力例
operatorgroup.operators.coreos.com/og created
次のサンプル 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
に設定する必要があります。
次のコマンドを実行して、
CatalogSource
設定を適用します。$ oc apply -f _<my-catalog-source.yaml>_ 1
- 1
- <my-catalog-source.yaml> をカタログソース設定ファイル名に置き換えます。
カタログソースが適用されていることを確認するには、次のコマンドを使用して
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
と報告されます。
次のコマンドを使用して、カタログソースが実行されていることを確認します。
$ oc get pods -n openshift-marketplace -l olm.catalogSource=operatorhubio-catalog
出力例
NAME READY STATUS RESTARTS AGE operatorhubio-catalog-j7sc8 1/1 Running 0 43s
次の 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
次のコマンドを実行して、Subscription CR 設定を適用します。
$ oc apply -f _<my-subscription-cr.yaml>_
出力例
subscription.operators.coreos.com/my-gitlab-operator-kubernetes
- 使用する特定のオペランドの設定ファイルを作成し、今すぐ適用できます。
検証
次のコマンドを使用して、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
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) プラグインがインストールされている。
手順
次のコマンドを実行して、フィルタリング可能な Red Hat 提供の Operator カタログのリストを取得します。
$ oc mirror list operators --version 4.16 --catalogs
次のコマンドを実行して、Red Hat Operators カタログ内の Operators のリストを取得します。
$ oc mirror list operators <--catalog=<catalog_source>> 1
- 1
registry.redhat.io/redhat/redhat-operator-index:v4.16
やquay.io/operatorhubio/catalog:latest
などのカタログソースを指定します。
-
Operator を選択します。この例では、
amq-broker-rhel8
が選択されています。 オプション: フィルタリングする Operator のチャネルとバージョンを検査するには、次のコマンドを入力します。
次のコマンドを実行して、チャネルのリストを取得します。
$ oc mirror list operators --catalog=registry.redhat.io/redhat/redhat-operator-index:v4.16 --package=amq-broker-rhel8
次のコマンドを実行して、チャネル内のバージョンのリストを取得します。
$ oc mirror list operators --catalog=registry.redhat.io/redhat/redhat-operator-index:v4.16 --package=amq-broker-rhel8 --channel=7.11.x
次のステップ
- この手順で収集した情報を使用して、イメージセット設定ファイルを作成および編集します。
- 変換されたイメージセット設定ファイルからのイメージをミラーレジストリーまたはディスクにミラーリングします。
8.3.2.3. イメージセット設定ファイルの作成
oc-mirror プラグインを使用してカタログの内容をミラーリングするには、イメージセット設定ファイルを作成する必要があります。イメージセット設定ファイルは、oc-mirror プラグインのその他の設定とともに、ミラーリングする Operator を定義します。デフォルトのイメージセットファイルを生成した後、残りのエントリーが MicroShift と使用予定の Operator の両方と互換性を持つように内容を編集する必要があります。
イメージセット設定ファイルでストレージバックエンドを指定する必要があります。このストレージバックエンドは、Docker v2-2 をサポートするローカルディレクトリーまたはレジストリーにすることができます。oc-mirror プラグインは、イメージセットの作成中にこのストレージバックエンドにメタデータを保存します。
oc-mirror プラグインによって生成されたメタデータを削除または変更しないでください。同じミラーレジストリーに対して oc-mirror プラグインを実行するたびに、同じストレージバックエンドを使用する必要があります。
前提条件
- コンテナーイメージレジストリーの認証情報ファイルを作成している。イメージのミラーリングを可能にする認証情報の設定 を参照してください。
手順
oc mirror init
コマンドを使用して、イメージセット設定のテンプレートを作成し、それをimageset-config.yaml
というファイルに保存します。$ oc mirror init <--registry <storage_backend> > imageset-config.yaml 1
- 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.16 type: ocp operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.16 packages: - name: serverless-operator channels: - name: stable additionalImages: 2 - name: registry.redhat.io/ubi8/ubi:latest helm: {} 3
次の例のように、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.16 3 packages: - name: amq-broker-rhel8 4 channels: - name: 7.11.x 5
- 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>
コマンドを実行すると、デフォルトチャネルを見つけることができます。
- 更新したファイルを保存します。
次のステップ
- oc-mirror プラグインを使用して、イメージセットをターゲットミラーレジストリーに直接ミラーリングします。
- CRI-O を設定します。
- カタログソースをクラスターに適用します。
8.3.2.3.1. Image set configuration parameters
oc-mirror プラグインには、ミラーリングするイメージを定義するイメージセット設定ファイルが必要です。次の表に、ImageSetConfiguration
リソースで使用可能なパラメーターを示します。
パラメーター | 説明 | 値 |
---|---|---|
|
|
String。例: |
| イメージセットの設定。 | オブジェクト |
| イメージセットの追加のイメージ設定。 | オブジェクトの配列。以下に例を示します。 additionalImages: - name: registry.redhat.io/ubi8/ubi:latest |
| ミラーリングするイメージのタグまたはダイジェスト。 |
String。例: |
| ミラーリングからブロックするイメージの完全なタグ、ダイジェスト、またはパターン。 |
文字列の配列例: |
| イメージセットの Operators 設定。 | オブジェクトの配列。以下に例を示します。 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.16 packages: - name: elasticsearch-operator minVersion: '2.4.0' |
| イメージセットに含める Operator カタログ。 |
String。たとえば、 |
|
|
ブール値。デフォルト値は |
| Operator パッケージ設定 | オブジェクトの配列。以下に例を示します。 operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.16 packages: - name: elasticsearch-operator minVersion: '5.2.3-31' |
| イメージセットに含める Operator パッケージ名 |
String。例: |
| Operator パッケージのチャネル設定。 | オブジェクト |
| イメージセットに含める、パッケージ内で一意の Operator チャネル名。 |
String。たとえば、 |
| Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。詳細は、以下の注記を参照してください。 |
String。例: |
| 含める最小バンドルの名前と、チャネルヘッドへの更新グラフ内のすべてのバンドル。名前付きバンドルにセマンティックバージョンメタデータがない場合にのみ、このフィールドを設定します。 |
String。例: |
| 存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。詳細は、以下の注記を参照してください。 |
String。例: |
| Operator が存在するすべてのチャネルでミラーリングする最上位バージョンの Operator。詳細は、以下の注記を参照してください。 |
String。例: |
| 存在するすべてのチャネル間でミラーリングする Operator の最低バージョン。詳細は、以下の注記を参照してください。 |
String。例: |
|
|
ブール値。デフォルト値は |
| 参照されるカタログをミラーリングするための代替名とオプションの namespace 階層。 |
String。例: |
| 参照されたカタログをミラーリングするための代替名。
|
String。例: |
|
|
String。例: |
| イメージセットのバックエンド設定。 | オブジェクト |
| イメージセットのローカルバックエンド設定。 | オブジェクト |
| イメージセットのメタデータを含むディレクトリーのパス。 |
String。例: |
| イメージセットのレジストリーバックエンド設定。 | オブジェクト |
| バックエンドレジストリー URI。オプションで、URI に namespace 参照を含めることができます。 |
String。例: |
| オプションで、参照されるバックエンドレジストリーの TLS 検証をスキップします。 |
ブール値。デフォルト値は |
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
出力例
Rendering catalog image "registry.example.com/redhat/redhat-operator-index:v{ocp-version}" with file-based catalog
検証
-
生成された
oc-mirror-workspace/
ディレクトリーに移動します。 -
results ディレクトリーに移動します (例:
results-1639608409/
。 -
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-*
ディレクトリーにあります。
手順
次のコマンドを実行して、
imageContentSourcePolicy.yaml
ファイルの内容を確認します。$ cat oc-mirror-workspace/<results-directory>/imageContentSourcePolicy.yaml 1
- 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
次のコマンドを実行して、
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
出力例
[[registry]] prefix = "registry.redhat.io/amq7" location = "registry.example.com/amq7" mirror-by-digest-only = true insecure = true
/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)
。
次のコマンドで MicroShift を再起動して、CRI-O 設定の変更を適用します。
$ sudo systemctl restart crio
8.3.2.6. oc-mirror プラグインで作成されたカスタムカタログのインストール
イメージセットをミラーレジストリーにミラーリングした後、生成された CatalogSource
カスタムリソース (CR) をクラスターに適用する必要があります。CatalogSource
CR は、Operator Lifecycle Manager (OLM) によって、ミラーレジストリー内の利用可能な Operators に関する情報を取得するために使用されます。次に、カスタムカタログをサブスクライブするためのサブスクリプション CR を作成して適用する必要があります。
前提条件
- イメージセットをレジストリーミラーにミラーリングしている。
- CRI-O コンテナーのランタイム設定に、イメージ参照情報を追加している。
手順
次のコマンドを実行して、results ディレクトリーからカタログソース設定ファイルを適用し、カタログソースオブジェクトを作成します。
$ oc apply -f ./oc-mirror-workspace/results-1708508014/catalogSource-cs-redhat-operator-index.yaml
カタログソース設定ファイルの例
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.16 updateStrategy: registryPoll: interval: 60m
- 1
- グローバル namespace を指定します。
metadata.namespace
をopenshift-marketplace
に設定すると、カタログはすべての namespace 内のカタログを参照できるようになります。どの namespace のサブスクリプションでも、openshift-marketplace
namespace で作成されたカタログを参照できます。
出力例
catalogsource.operators.coreos.com/cs-redhat-operator-index created
以下のコマンドを実行して、
CatalogSource
リソースが正常にインストールされたことを確認します。$ oc get catalogsource --all-namespaces
次のコマンドを使用して、カタログソースが実行されていることを確認します。
$ oc get pods -n openshift-marketplace
出力例
NAME READY STATUS RESTARTS AGE cs-redhat-operator-index-4227b 2/2 Running 0 2m5s
次の例のような
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
次のコマンドを実行して、Subscription CR 設定を適用します。
$ oc apply -f ./<my-subscription-cr.yaml> 1
- 1
- サブスクリプションの名前 (
my-subscription-cr.yaml
など) を指定します。
出力例
subscription.operators.coreos.com/amq-broker created
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 プラグインをインストールしている。 - イメージセット設定ファイルを作成している。
手順
--dry-run
フラグを指定してoc mirror
コマンドを実行し、ドライランを実行します。$ oc mirror --config=./imageset-config.yaml \1 docker://registry.example:5000 \2 --dry-run 3
出力例
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
生成されたワークスペースディレクトリーに移動します。
$ cd oc-mirror-workspace/
生成された
mapping.txt
ファイルを確認します。このファイルには、ミラーリングされるすべてのイメージのリストが含まれています。
生成された
pruning-plan.json
ファイルを確認します。このファイルには、イメージセットの公開時にミラーレジストリーからプルーニングされるすべてのイメージのリストが含まれています。
注記pruning-plan.json
ファイルは、oc-mirror コマンドがミラーレジストリーを指し、プルーニングするイメージがある場合にのみ生成されます。
8.4.1.2. 非接続環境で RHEL for Edge で使用するカタログと Operator コンテナーイメージ参照を取得する
oc-mirror プラグインを使用してドライランを実行し、ミラーリングするイメージのリストを確認した後、すべてのコンテナーイメージ参照を取得し、Image Builder ブループリントに追加するために出力をフォーマットする必要があります。
独自の Operator 用に作成されたカタログの場合は、次の手順を使用せずに、Image Builder ブループリントのイメージ参照をフォーマットできます。
前提条件
- 使用する Operator のカタログインデックスがある。
-
jq
CLI ツールがインストールされている。 - Image Builder のブループリントファイルに精通している。
- Image Builder ブループリント TOML ファイルがある。
手順
カタログの
index.json
ファイルを解析して、Image Builder ブループリントに含める必要があるイメージ参照を取得します。フィルタリングされていないカタログを使用することも、ミラーリングできないイメージを除外することもできます。次のコマンドを実行して、フィルタリングされていないカタログの
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.16/index/index.json
ミラーリングできないイメージを除外する場合は、次のコマンドを実行して、カタログの
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.16/index/index.json
注記この手順では、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
重要ミラーリングされたユースケースと非接続ユースケースでは、カタログの
index.json
ファイルからフィルタリングされたすべてのソースがダイジェストであることを確認します。いずれかのソースがダイジェストではなくタグを使用している場合、Operator のインストールは失敗します。タグにはインターネット接続が必要です。
次のコマンドを実行して、
imageset-config.yaml
を表示し、CatalogSource
カスタムリソース (CR) のカタログイメージ参照を取得します。$ cat imageset-config.yaml
出力例
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.16 1 packages: - name: amq-broker-rhel8 channels: - name: 7.11.x
- 1
- イメージダイジェストを取得するには、次の
jq
コマンドのmirror.catalog
カタログイメージ参照の値を使用します。この例では、<registry.redhat.io/redhat/redhat-operator-index:v4.16> になります。
次のコマンドを実行して、カタログインデックスイメージの SHA を取得します。
$ skopeo inspect docker://<registry.redhat.io/redhat/redhat-operator-index:v4.16> | jq `.Digest` 1
- 1
- イメージダイジェストを取得するには、
jq
コマンドのmirror.catalog
カタログイメージ参照の値を使用します。この例では、<registry.redhat.io/redhat/redhat-operator-index:v4.16> になります。
出力例
"sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6"
Image Builder ブループリントファイルにイメージ参照を追加する準備をするには、次の例を使用して、カタログイメージ参照をフォーマットします。
[[containers]] source = "registry.redhat.io/redhat/redhat-operator-index@sha256:7a76c0880a839035eb6e896d54ebd63668bb37b82040692141ba39ab4c539bc6"
これまでのすべての手順からのイメージ参照を Image Builder ブループリントに追加します。
生成された Image Builder ブループリントのサンプルスニペット
name = "microshift_blueprint" description = "MicroShift 4.16.1 on x86_64 platform" version = "0.0.1" modules = [] groups = [] [[packages]] 1 name = "microshift" version = "4.16.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
8.4.1.3. 非接続デプロイメントの RHEL for Edge イメージにカタログと Operator を適用する
非接続環境用の RHEL for Edge イメージを作成し、非接続で使用するように MicroShift ネットワークを設定したら、namespace を設定し、Operator を実行するためのカタログと Operator カスタムリソース (CR) を作成できます。
前提条件
- RHEL for Edge イメージがある。
- ネットワークは非接続環境で使用するように設定されている。
- oc-mirror プラグインのドライラン手順が完了している。
手順
次の例のように、
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.16 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
値を設定できます。次の例のように、カタログインデックスコミットの 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 の起動に失敗します。
次のコマンドを実行して、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
以下のコマンドを実行して、
CatalogSource
リソースが正常にインストールされたことを確認します。$ oc get catalogsource --all-namespaces
次のコマンドを使用して、カタログソースが実行されていることを確認します。
$ oc get pods -n openshift-marketplace
出力例
NAME READY STATUS RESTARTS AGE cs-redhat-operator-index-4227b 2/2 Running 0 2m5s
次の例のような
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
次のコマンドを実行して、
Subscription
CR を適用します。$ oc apply -f ./<my-subscription-cr.yaml> 1
- 1
my-subscription-cr.yaml
など、Subscription
CR の名前を指定します。
出力例
subscription.operators.coreos.com/amq-broker created