アプリケーションの実行


Red Hat build of MicroShift 4.13

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

Red Hat OpenShift Documentation Team

概要

このドキュメントでは、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 コマンドと同等のコマンドを自動的に実行して、特定されたマニフェストをクラスターに適用します。

場所目的

/etc/microshift/manifests

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

/usr/lib/microshift/manifests

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

1.2. マニフェストの使用例

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

手順

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

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

      $ MANIFEST_DIR=/etc/microshift/manifests
    2. ディレクトリーを作成します。

      $ sudo mkdir -p ${MANIFEST_DIR}
    3. yaml ファイルをディレクトリーに配置します。

      $ sudo tee ${MANIFEST_DIR}/busybox.yaml &>/dev/null <<EOF
      
      apiVersion: v1
      kind: Namespace
      metadata:
        name: busybox
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: busybox-deployment
      spec:
        selector:
          matchLabels:
            app: busybox
        template:
          metadata:
            labels:
              app: busybox
          spec:
            containers:
            - name: busybox
              image: BUSYBOX_IMAGE
              command:
                - sleep
                - "3600"
      EOF
  2. 次に、以下のコマンドを実行して kustomize マニフェストファイルを作成します。

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

      $ sudo tee ${MANIFEST_DIR}/kustomization.yaml &>/dev/null <<EOF
      ---
      apiVersion: kustomize.config.k8s.io/v1beta1
      kind: Kustomization
      namespace: busybox
      resources:
        - busybox.yaml
      images:
        - name: BUSYBOX_IMAGE
          newName: registry.k8s.io/busybox
      EOF
  3. 次のコマンドを実行して Red Hat build of MicroShift を再起動し、マニフェストを適用します。

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

    $ oc get pods -n busybox

第2章 Operator が Red Hat build of MicroShift を使用する方法

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

Operator はよりローカライズされた設定エクスペリエンスを提供し、kubectloc などの 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 コマンドと同等のコマンドを自動的に実行して、特定されたマニフェストをクラスターに適用します。

場所目的

/etc/microshift/manifests

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

/usr/lib/microshift/manifests

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

2.1.2. マニフェストの使用例

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

手順

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

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

      $ MANIFEST_DIR=/etc/microshift/manifests
    2. ディレクトリーを作成します。

      $ sudo mkdir -p ${MANIFEST_DIR}
    3. yaml ファイルをディレクトリーに配置します。

      $ sudo tee ${MANIFEST_DIR}/busybox.yaml &>/dev/null <<EOF
      
      apiVersion: v1
      kind: Namespace
      metadata:
        name: busybox
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: busybox-deployment
      spec:
        selector:
          matchLabels:
            app: busybox
        template:
          metadata:
            labels:
              app: busybox
          spec:
            containers:
            - name: busybox
              image: BUSYBOX_IMAGE
              command:
                - sleep
                - "3600"
      EOF
  2. 次に、以下のコマンドを実行して kustomize マニフェストファイルを作成します。

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

      $ sudo tee ${MANIFEST_DIR}/kustomization.yaml &>/dev/null <<EOF
      ---
      apiVersion: kustomize.config.k8s.io/v1beta1
      kind: Kustomization
      namespace: busybox
      resources:
        - busybox.yaml
      images:
        - name: BUSYBOX_IMAGE
          newName: registry.k8s.io/busybox
      EOF
  3. 次のコマンドを実行して Red Hat build of MicroShift を再起動し、マニフェストを適用します。

    $ sudo systemctl restart microshift
  4. 次のコマンドを実行して、マニフェストを適用し、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.confGREENBOOT_WATCHDOG_CHECK_ENABLED を false に変更するか、/etc/greenboot/greenboot.confGREENBOOT_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 サービスが有効である。

手順

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

    $ sudo reboot
  2. 次のコマンドを実行して、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.

法律上の通知

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

© 2024 Red Hat, Inc.