アプリケーションの実行
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>manifests: kustomizePaths: - <location>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
"/opt/alternative/path"を使用して各位置エントリーを正確なパスに設定するか、"/opt/alternative/path.d/*"を使用して glob パターンを設定します。
-
単一パスの設定ファイルで
マニフェストの読み込みを無効にするには、設定オプションを空のリストに設定します。
manifests: kustomizePaths: []manifests: kustomizePaths: []Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記設定ファイルはデフォルトを完全にオーバーライドします。
kustomizePaths値が設定されている場合は、設定ファイル内の値のみが使用されます。値を空のリストに設定すると、マニフェストの読み込みが無効になります。
1.3. マニフェストの使用例 リンクのコピーリンクがクリップボードにコピーされました!
この例では、/etc/microshift/manifests ディレクトリー内の kustomize マニフェストを使用した BusyBox コンテナーの自動デプロイを示します。
手順
次のコマンドを実行して、BusyBox マニフェストファイルを作成します。
ディレクトリーの場所を定義します。
MANIFEST_DIR=/etc/microshift/manifests
$ MANIFEST_DIR=/etc/microshift/manifestsCopy to Clipboard Copied! Toggle word wrap Toggle overflow ディレクトリーを作成します。
sudo mkdir -p ${MANIFEST_DIR}$ sudo mkdir -p ${MANIFEST_DIR}Copy to Clipboard Copied! Toggle word wrap Toggle overflow YAML ファイルをディレクトリーに配置します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次に、以下のコマンドを実行して
kustomizeマニフェストファイルを作成します。YAML ファイルをディレクトリーに配置します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して MicroShift を再起動し、マニフェストを適用します。
sudo systemctl restart microshift
$ sudo systemctl restart microshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、マニフェストを適用し、
busyboxPod を起動します。oc get pods -n busybox
$ oc get pods -n busyboxCopy to Clipboard Copied! Toggle word wrap Toggle overflow
第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. オフラインで使用するためのアプリケーションの埋め込み リンクのコピーリンクがクリップボードにコピーされました!
アプリケーションに複数のファイルが含まれている場合は、オフラインで使用できるようにアプリケーションを埋め込むことができます。以下の手順を参照してください。
第3章 オフラインで使用するためのアプリケーションの埋め込み リンクのコピーリンクがクリップボードにコピーされました!
マイクロサービスベースのワークロードとアプリケーションを Red Hat Enterprise Linux for Edge (RHEL for Edge) イメージに埋め込むことができます。埋め込みを行うと、エアギャップ環境、非接続環境、またはオフライン環境で Red Hat build of MicroShift クラスターを実行できます。
3.1. オフラインで使用するためのワークロードコンテナーイメージの埋め込み リンクのコピーリンクがクリップボードにコピーされました!
ネットワーク接続がないエッジのデバイスにコンテナーイメージを埋め込むには、新しいコンテナーを作成し、ISO をマウントして、コンテンツをファイルシステムにコピーする必要があります。
前提条件
- ホストへの root アクセス権限がある。
- アプリケーション RPM がブループリントに追加されている。
手順
次のコマンドを実行して、マニフェストをレンダリングし、すべてのコンテナーイメージ参照を抽出し、アプリケーションイメージをブループリントコンテナーソースに変換します。
oc kustomize ~/manifests | grep "image:" | grep -oE '[^ ]+$' | while read line; do echo -e "[[containers]]\nsource = \"${line}\"\n"; done >><my_blueprint>.toml$ oc kustomize ~/manifests | grep "image:" | grep -oE '[^ ]+$' | while read line; do echo -e "[[containers]]\nsource = \"${line}\"\n"; done >><my_blueprint>.tomlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、更新されたブループリントを Image Builder にプッシュします。
sudo composer-cli blueprints push <my_blueprint>.toml
$ sudo composer-cli blueprints push <my_blueprint>.tomlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ワークロードコンテナーがプライベートリポジトリーにある場合は、Image Builder に必要なプルシークレットを提供する必要があります。
-
/etc/osbuild-worker/osbuild-worker.tomlファイル内のosbuilder worker設定の[containers]セクションにあるauth_file_pathを、プルシークレットを指すように設定します。 必要に応じて以下のように、プルシークレットのディレクトリーおよびファイルを作成します。
ディレクトリーとファイルの例
[containers] auth_file_path = "/<path>/pull-secret.json"
[containers] auth_file_path = "/<path>/pull-secret.json"1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- イメージのコピーおよび取得には、以前に設定したカスタムの場所を使用します。
-
以下のコマンドを実行し、コンテナーイメージをビルドします。
sudo composer-cli compose start-ostree <my_blueprint> edge-commit
$ sudo composer-cli compose start-ostree <my_blueprint> edge-commitCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
ビルドの完了待ち、イメージのエクスポート、
rpm-ostreeリポジトリーへの統合、ブータブル ISO の作成など、任意のrpm-ostreeイメージフローに進みます。
第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.2 ビルドホストを設定している。
- ホストへの root アクセス権限がある。
手順
rpmbuildツールをインストールし、以下のコマンドを実行してその yum リポジトリーを作成します。sudo dnf install rpmdevtools rpmlint yum-utils createrepo
$ sudo dnf install rpmdevtools rpmlint yum-utils createrepoCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、RPM パッケージの構築に必要なファイルツリーを作成します。
rpmdev-setuptree
$ rpmdev-setuptreeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、ディレクトリーを一覧表示して作成を確認します。
ls ~/rpmbuild/
$ ls ~/rpmbuild/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
BUILD RPMS SOURCES SPECS SRPMS
BUILD RPMS SOURCES SPECS SRPMSCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.4. アプリケーションマニフェストの RPM パッケージの構築 リンクのコピーリンクがクリップボードにコピーされました!
独自の RPM を構築するには、アプリケーションマニフェストを RPM パッケージに追加する仕様ファイルを作成する必要があります。以下に手順の例を示します。イメージ構築に必要なアプリケーション RPM およびその他の要素が Image Builder にアクセスできる限り、任意の方法を使用できます。
前提条件
- Image Builder のシステム要件を満たす Red Hat Enterprise Linux for Edge (RHEL for Edge) 9.2 ビルドホストを設定している。
- ホストへの root アクセス権限がある。
- RPM パッケージの構築に必要なファイルツリーが作成されている。
手順
~/rpmbuild/SPECSディレクトリーに、次のテンプレートを使用して<application_workload_manifests.spec>などのファイルを作成します。仕様ファイルの例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
%installセクションは、RPM パッケージ内にターゲットディレクトリー/usr/lib/microshift/manifests/を作成し、ソースホームディレクトリー~/manifestsからマニフェストをコピーします。
重要必要な YAML ファイルはすべて、ソースホームディレクトリー
~/manifestsに置かれている必要があります (kustomize を使用している場合はkustomize.yamlファイルも含まれます)。以下のコマンドを実行して、
~/rpmbuild/RPMSディレクトリーに RPM パッケージをビルドします。rpmbuild -bb ~/rpmbuild/SPECS/<application_workload_manifests.spec>
$ rpmbuild -bb ~/rpmbuild/SPECS/<application_workload_manifests.spec>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.5. ブループリントへのアプリケーション RPM の追加 リンクのコピーリンクがクリップボードにコピーされました!
アプリケーション RPM をブループリントに追加するには、Image Builder が ISO の作成に使用できるローカルリポジトリーを作成する必要があります。この手順では、ワークロードに必要なコンテナーイメージをネットワーク経由でプルできます。
前提条件
- ホストへの root アクセス権限がある。
-
ワークロードまたはアプリケーション RPM が
~/rpmbuild/RPMSディレクトリーにある。
手順
次のコマンドを実行して、ローカル RPM リポジトリーを作成します。
createrepo ~/rpmbuild/RPMS/
$ createrepo ~/rpmbuild/RPMS/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Image Builder に RPM リポジトリーへのアクセス権限を付与します。
sudo chmod a+rx ~
$ sudo chmod a+rx ~Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記イメージ構築に必要なファイル全てにアクセスする必須のパーミッションが Image Builder に割り当てられている必要があります。そうでないと、ビルドを続行できません。
次のテンプレートを使用して、ブループリントファイル
repo-local-rpmbuild.tomlを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 選択したロケーションを作成するパスの一部を指定します。後のコマンドでこのパスを使用して、リポジトリーを設定し、RPM をコピーします。
次のコマンドを実行して、Image Builder のソースとしてリポジトリーを追加します。
sudo composer-cli sources add repo-local-rpmbuild.toml
$ sudo composer-cli sources add repo-local-rpmbuild.tomlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の行を追加して、RPM をブループリントに追加します。
… [[packages]] name = "<application_workload_manifests>" version = "*" …
… [[packages]] name = "<application_workload_manifests>"1 version = "*" …Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ワークロードの名前をここに追加します。
次のコマンドを実行して、更新されたブループリントを Image Builder にプッシュします。
sudo composer-cli blueprints push repo-local-rpmbuild.toml
$ sudo composer-cli blueprints push repo-local-rpmbuild.tomlCopy to Clipboard Copied! Toggle word wrap Toggle overflow この時点で、Image Builder を実行して ISO を作成するか、オフラインで使用するためにコンテナーイメージを埋め込むことができます。
ISO を作成するには、次のコマンドを実行して Image Builder を起動します。
sudo composer-cli compose start-ostree repo-local-rpmbuild edge-commit
$ sudo composer-cli compose start-ostree repo-local-rpmbuild edge-commitCopy to Clipboard Copied! Toggle word wrap Toggle overflow
このシナリオでは、起動時にエッジデバイスによってネットワーク経由でコンテナーイメージがプルされます。
第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 ヘルスチェックの手順を実装します。
ワークロードヘルスチェックスクリプトの例
5.4. ワークロードヘルスチェックスクリプトのテスト リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- root アクセスがある。
- ワークロードがインストールされている。
- ワークロードのヘルスチェックスクリプトを作成している。
- Red Hat build of MicroShift サービスが有効である。
手順
Greenboot がヘルスチェックスクリプトファイルを実行していることをテストするには、次のコマンドを実行してホストを再起動します。
sudo reboot
$ sudo rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、Greenboot ヘルスチェックの出力を調べます。
sudo journalctl -o cat -u greenboot-healthcheck.service
$ sudo journalctl -o cat -u greenboot-healthcheck.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記MicroShift コアサービスのヘルスチェックは、ワークロードのヘルスチェックの前に実行されます。
出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第6章 Pod のセキュリティー認証と認可 リンクのコピーリンクがクリップボードにコピーされました!
6.1. Pod セキュリティーアドミッションの理解と管理 リンクのコピーリンクがクリップボードにコピーされました!
Pod セキュリティーアドミッションは、Kubernetes Pod セキュリティー標準 の実装です。Pod のセキュリティーアドミッションを使用して、Pod の動作を制限します。
6.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 権限が使用される場合があります。ただし、自動ラベル付けではユーザー権限は考慮されません。
6.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>
oc get --show-labels namespace <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.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
$ oc label namespace <namespace> security.openshift.io/scc.podSecurityLabelSync=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
--overwrite フラグを使用すると、namespace での Pod セキュリティーラベルの同期の影響を元に戻すことができます。
第7章 Operator が MicroShift と連携する方法 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift で Operator を使用して、クラスター内で実行中のサービスを監視するアプリケーションを作成できます。Operator は、データベースやメッセージバスのデプロイなど、アプリケーションとそのリソースを管理できます。クラスター内で実行するカスタマイズされたソフトウェアとして、Operator を使用して一般的な操作を実装し、自動化できます。
Operator はよりローカライズされた設定エクスペリエンスを提供し、kubectl や oc などの Kubernetes API および CLI ツールと統合します。Operator は、アプリケーション専用に設計されています。Operator を使用すると、グローバル設定ファイルを変更する代わりにコンポーネントを設定できます。
MicroShift アプリケーションは通常、静的環境にデプロイされることが想定されています。ただし、Operator はユースケースで役立つ場合に利用できます。Operator と MicroShift の互換性を判断するには、Operator のドキュメントを確認してください。
7.1. MicroShift での Operator のインストール方法 リンクのコピーリンクがクリップボードにコピーされました!
MicroShift のフットプリントを最小限に抑えるために、Operator は Operator Lifecycle Manager (OLM) を使用する代わりにマニフェストを使用して直接インストールされます。MicroShift で kustomize 設定管理ツールを使用して、アプリケーションをデプロイできます。マニフェストを使用して Operator をインストールするには、同じ手順を使用します。マニフェストの詳細は、Kustomize マニフェストを使用したアプリケーションのデプロイ を参照してください。