MicroShift is Technology Preview software only.
For more information about the support scope of Red Hat Technology Preview software, see Technology Preview Support Scope.アプリケーションの実行
MicroShift でのアプリケーションの実行
概要
第1章 Red Hat build of MicroShift を使用したアプリケーションデプロイメント
kustomize
設定管理ツールを使用して、アプリケーションをデプロイできます。このツールが Red Hat build of MicroShift でどのように機能するかについての例は、次の手順をお読みください。
1.1. マニフェストの kustomize の使用方法
kustomize
設定管理ツールは、Red Hat build of MicroShift に統合されます。起動時に、Red Hat build of MicroShift は /etc/microshift/manifests
および /usr/lib/microshift/
マニフェストディレクトリーで kustomization.yaml
ファイルを検索します。これが見つかると、Red Hat build of MicroShift は kubectl apply -k
コマンドと同等のコマンドを自動的に実行して、特定されたマニフェストをクラスターに適用します。
場所 | 目的 |
---|---|
| 設定管理システムまたは開発用の読み取り/書き込みの場所。 |
| OSTree ベースのシステムに設定マニフェストを埋め込むための読み取り専用の場所。 |
1.2. マニフェストの使用例
この例では、/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-deployment spec: selector: matchLabels: app: busybox template: metadata: labels: app: busybox spec: containers: - name: busybox image: BUSYBOX_IMAGE command: - sleep - "3600" 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: registry.k8s.io/busybox EOF
次のコマンドを実行して Red Hat build of MicroShift を再起動し、マニフェストを適用します。
$ sudo systemctl restart microshift
次のコマンドを実行して、マニフェストを適用し、
busybox
Pod を起動します。$ oc get pods -n busybox
第2章 Operator が Red Hat build of MicroShift を使用する方法
Red Hat build of MicroShift で Operator を使用して、クラスター内で実行中のサービスを監視するアプリケーションを作成できます。Operator は、データベースやメッセージバスのデプロイなど、アプリケーションとそのリソースを管理できます。クラスター内で実行するカスタマイズされたソフトウェアとして、Operator を使用して一般的な操作を実装し、自動化できます。
Operator はよりローカライズされた設定エクスペリエンスを提供し、kubectl
や oc
などの Kubernetes API および CLI ツールと統合します。Operator は、アプリケーション専用に設計されています。Operator を使用すると、グローバル設定ファイルを変更する代わりにコンポーネントを設定できます。
Red Hat build of MicroShift アプリケーションは通常、静的環境にデプロイされることが想定されています。ただし、Operator はユースケースで役立つ場合に利用できます。Operator と Red Hat build of MicroShift の互換性を判断するには、Operator のドキュメントを確認してください。
2.1. Red Hat build of MicroShift での Operator のインストール方法
Red Hat build of MicroShift のフットプリントを最小限に抑えるために、Operator は Operator Lifecycle Manager (OLM) を使用する代わりにマニフェストを使用して直接インストールされます。以下の例は、Red Hat build of MicroShift で kustomize
設定管理ツールを使用してアプリケーションをデプロイする方法を説明します。マニフェストを使用して Operator をインストールするには、同じ手順を使用します。
2.1.1. マニフェストの kustomize の使用方法
kustomize
設定管理ツールは、Red Hat build of MicroShift に統合されます。起動時に、Red Hat build of MicroShift は /etc/microshift/manifests
および /usr/lib/microshift/
マニフェストディレクトリーで kustomization.yaml
ファイルを検索します。これが見つかると、Red Hat build of MicroShift は kubectl apply -k
コマンドと同等のコマンドを自動的に実行して、特定されたマニフェストをクラスターに適用します。
場所 | 目的 |
---|---|
| 設定管理システムまたは開発用の読み取り/書き込みの場所。 |
| OSTree ベースのシステムに設定マニフェストを埋め込むための読み取り専用の場所。 |
2.1.2. マニフェストの使用例
この例では、/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-deployment spec: selector: matchLabels: app: busybox template: metadata: labels: app: busybox spec: containers: - name: busybox image: BUSYBOX_IMAGE command: - sleep - "3600" 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: registry.k8s.io/busybox EOF
次のコマンドを実行して Red Hat build of MicroShift を再起動し、マニフェストを適用します。
$ sudo systemctl restart microshift
次のコマンドを実行して、マニフェストを適用し、
busybox
Pod を起動します。$ oc get pods -n busybox
第3章 greenboot ワークロードヘルスチェックスクリプト
Greenboot ヘルスチェックスクリプトは、エッジデバイスを使用していて、直接サービスを利用できないか、限りがある場合に役立ちます。microshift-greenboot
RPM パッケージをインストールした場合は、ワークロードとアプリケーションの正常性を評価するヘルスチェックスクリプトを作成することもできます。これらの追加のヘルスチェックスクリプトは、ソフトウェアの問題チェックと自動システムロールバックの有用なコンポーネントです。
Red Hat build of MicroShift ヘルスチェックスクリプトは、microshift-greenboot
RPM に含まれています。実行中のワークロードに基づいて、独自のヘルスチェックスクリプトを作成することもできます。たとえば、サービスの起動を確認するスクリプトを作成するなどが可能です。
3.1. ワークロードヘルスチェックスクリプトの仕組み
本チュートリアルで説明されているワークロードまたはアプリケーションのヘルスチェックスクリプトは、/usr/share/microshift/functions/greenboot.sh
ファイルで利用可能な Red Hat build of MicroShift ヘルスチェック機能を使用します。これにより、Red Hat build of MicroShift コアサービスにすでに実装されている手順を再利用できます。
このスクリプトは、ワークロードの基本機能が期待どおりに動作しているかどうかのチェックを実行することから始まります。スクリプトを正常に実行するには、以下を実行します。
- root ユーザーアカウントからスクリプトを実行します。
- Red Hat build of MicroShift サービスの有効化
ヘルスチェックは以下のアクションを実行します。
-
wait_for
関数における現在のブートサイクルの待機時間でのタイムアウトを取得します。 -
namespace_images_downloaded
関数を呼び出して、Pod イメージが利用可能になるまで待機します。 -
namespace_pods_ready
関数を呼び出して、Pod が準備状態になるまで待機します。 -
namespace_pods_not_restarting
関数を呼び出して、Pod が再起動していないことを確認します。
Pod を再起動すると、クラッシュループを示している可能性があります。
3.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
変数値を変更して設定できます。
3.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
ディレクトリーに配置できます。
3.3.1. ワークロードヘルスチェックスクリプトの例
次の例では、Red Hat build of MicroShift ヘルスチェックスクリプトをテンプレートとして使用します。この例は、アプリケーションの基本的なヘルスチェックスクリプトを作成するためのガイドとして、提供されたライブラリーで使用できます。
3.3.1.1. ヘルスチェックスクリプト作成の基本要件
- ワークロードがインストールされている。
- root アクセスがある。
3.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
3.4. ワークロードヘルスチェックスクリプトのテスト
前提条件
- root アクセスがある。
- ワークロードがインストールされている。
- ワークロードのヘルスチェックスクリプトを作成している。
- Red Hat build of MicroShift サービスが有効である。
手順
greenboot がヘルスチェックスクリプトファイルを実行していることをテストするには、次のコマンドを実行してホストを再起動します。
$ sudo reboot
次のコマンドを実行して、greenboot ヘルスチェックの出力を調べます。
$ sudo journalctl -o cat -u greenboot-healthcheck.service
注記ワークロードヘルスチェックの前に、Red Hat build of 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.