25.0.0.6 での mpHealth-4.0 の Java EE 7 と EE 8 環境へのバックポートとファイルベースのヘルスチェック

Navaneeth S Nair and 馬場剛 (翻訳) 2025年6月17日

発表 , microprofile , java-se , リリース , モニタリング ,

他言語版へのリンク: English ,

このリリースでは MicroProfile Health 4.0 機能が、Jakarta EE 9 以降に加えて Java EE 7 および EE 8 環境でサポートされるようになりました。さらに、ファイルベースのヘルスチェックメカニズムが導入されました。この機能は、サーバーにデプロイされたアプリケーションのヘルスチェックを実行し、自動化されたサービスが実行時に可用性と応答性をチェックできるようにします。

Open Liberty 25.0.0.6 では以下の対応がされました。

Java EE 7 および EE 8 環境向けの mpHealth-4.0 のバックポートとファイルベースのヘルスチェックの導入
主なバグ修正

ランタイムに追加された新しい機能についてのガイドを作成しました。ガイドの更新情報

修正されたバグのリストについては、25.0.0.6 をご覧ください。

以前の Open Liberty GA リリース・ブログを参照して下さい。

25.0.0.6 を使用してアプリを開発および実行する

Maven を使用している場合, pom.xml ファイルに次の内容を含めます。

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.11.4</version>
</plugin>

Gradle の場合は build.gradle ファイルに次の内容を含めます。

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.9.4'
    }
}
apply plugin: 'liberty'

コンテナイメージの場合は以下です。

FROM icr.io/appcafe/open-liberty

Downloads ページも参照して下さい。

IntelliJ IDEA, Visual Studio Code または Eclipse IDE を使用している場合、オープンソースの Liberty 開発者ツールを使用して効率的な開発、テスト、デバッグとアプリケーション管理のすべてを IDE 内から行えます。

Java EE 7 および EE 8 環境向けの mpHealth-4.0 のバックポートとファイルベースのヘルスチェックの導入

MicroProfile Health 4.0 フィーチャー (mpHealth-4.0) は、以前は Jakarta EE 9 以降でのみサポートされていました。25.0.0.6 では mpHealth-4.0 は Java EE 7 と EE 8 環境でもサポートされるようになりました。また、/health/* REST エンドポイントを使用する代替としてファイルベースのヘルスチェックが導入されました。

MicroProfile Health テクノロジーは、'Liveness', 'Readiness' と 'Startup' プローブが利用可能な Kubernetes ベースの環境にアプリケーションがデプロイされている場合に最も効果的です。このようなデプロイメント・シナリオでは、デプロイされるアプリケーションは、異なる Java レベルと Jakarta EE レベルにある可能性があります。この構成により、異なるサーバーおよび異なる Kubernetes プローブ構成にわたって mpHealth-x.x フィーチャーが混在する可能性があります。 mpHealth-4.0 フィーチャーは、既存の Jakarta EE 9 および Jakarta EE 10 環境のサポートに加えて、Java EE 7 および Java EE 8 でも使用できるようになりました。このフィーチャーにより、Open Liberty サーバー構成と Kubernetes ヘルスチェック・プローブ構成が統合されます。

/health/live, /health/ready, /health/started REST エンドポイントへのクエリを行う既存の戦略に加えて、このリリースでは代替となるファイルベースのヘルスチェック機能が導入されています。この機能が有効化されると、${server.output.dir}/health ディレクトリ下に live, ready と started ファイルが作成されます。${server.output.dir} は wlp/usr/servers/<server> がデフォルトです。詳しくは Directory locations and properties を参照して下さい。

アプリケーションが startup, liveness と readiness の 3つすべてのチェックに UP ステータスを返すとき、この 3つのヘルスチェック・ファイルが作成されます。特に構成されていない場合、Open Liberty ランタイムはこれらのヘルスチェックへ 100ms ごとに問い合わせます。これは startup フェーズの一部です。これらのファイルが作成されると、ランタイムは update フェーズへ進みます。そしてランタイムはユーザー定義の間隔で liveness と readiness ヘルスチェックのクエリを続行します。ステータスが UP を返すとき、そのファイルの最終変更時刻が更新されます。ファイルが更新されていなければ、DOWN ステータスが返されたことを示します。

このファイルベースの機能は、ユーザーが mpHealth 構成要素の checkInterval 構成属性または MP_HEALTH_CHECK_INTERVAL environment variable を構成した場合にのみ有効になります。 check interval 構成は update フェーズ中に使用される値です。環境変数と`checkInterval`属性の両方が設定されている場合, 実行時には server.xml が優先されます。構成では、時間単位を示すために、数値の後にオプションで ms または s が続きます。時間単位が指定されていない場合, デフォルトは秒です。無効な値の場合、間隔はデフォルトで 10 秒に設定されます。

startup フェーズ中に使用されるクエリ間隔は、構成属性 startupCheckInterval で定義されます。 MP_HEALTH_STARTUP_CHECK_INTERVAL には付随する環境変数があります。この値はオプションであり、構成が定義されていない場合はデフォルトの 100ms が使用されることに注意してください。同様に、server.xml と環境変数の設定が両方定義されている場合、server.xml の値が優先されます。構成では、時間単位を示すために、数値の後にオプションで ms または s が続きます。時間単位が指定されていない場合、デフォルトはミリ秒です。無効な値の場合、間隔はデフォルトで 100 ミリ秒に設定されます。

次の例は、server.xml 構成を示しています。

<server>
  <features>
    <feature>mphealth-4.0</feature>
  </features>
  <mpHealth startupCheckInterval="150ms" checkInterval="10s"/>
</server>

ファイルベースのチェックでは Kubernetes ヘルスチェック・プローブを構成するときに、httpGet または gRPC 戦略の代わりに exec コマンド戦略を使用できます。このリリースでは, これらのファイルベースのヘルスチェックのために、Open Liberty イメージにスクリプトが導入されています。

スクリプトは startupHealthCheck.sh、livenessHealthCheck.sh と readinessHealthCheck.sh です。startupHealthCheck.sh スクリプトの場合、startup プローブの timeoutSeconds 構成と一致する値を持つオプション -t または --timeout-seconds を渡すことが重要です。

同様に、livenessHealthCheck.sh および readinessHealthCheck.sh の場合、-p または --period-seconds オプションには、liveness および readiness プローブそれぞれの periodSeconds 構成に使用される値を渡す必要があります。 liveness および readiness のヘルスチェック・スクリプトは、live ファイルと ready ファイルそれぞれが過去 periodSeconds 以内に更新されたかどうかを確認します。

最良の結果を得るには, liveness プローブと readiness プローブを checkInterval 構成の少なくとも 1.5 倍に設定します。

例えば, Open Liberty アプリケーション・イメージが構成され、デプロイされ、`checkInterval`属性が 10秒に設定されている場合、次の例のような Kubernetes 構成を使用できます。

  probes:
    startup:
      exec:
        command:
          - /bin/sh
          - '-c'
          - startupHealthCheck.sh -t 1
      failureThreshold: 8
      initialDelaySeconds: 0
      periodSeconds: 1
      timeoutSeconds: 1
    liveness:
      exec:
        command:
          - /bin/sh
          - '-c'
          - livenessHealthCheck.sh -p 15
      failureThreshold: 3
      initialDelaySeconds: 0
      periodSeconds: 15
      timeoutSeconds: 5
    readiness:
      exec:
        command:
          - /bin/sh
          - '-c'
          - readinessHealthCheck.sh -p 15
      failureThreshold: 3
      initialDelaySeconds: 0
      periodSeconds: 15
      timeoutSeconds: 5

liveness と readiness プローブで、periodSeconds が 15、即ち checkInterval の 1.5倍に設定されていることに留意して下さい。

このリリースで修正された主なバグ

以下のセクションではこのリリースで修正されたいくつかの問題について記述しています。修正された問題の完全なリストはこちらです。 25.0.0.6 で修正されたバグの完全なリスト。

前回のリリース以降の新規および更新されたガイド

Open Liberty の機能が拡張するのに伴い、それらへの対応を可能な限り容易にするため、openliberty.io の新しいガイドを追加し続けています。Build カテゴリー下に発行された Gradle によるマルチモジュール・アプリケーションの作成も参照して下さい。また、非推奨のガイドと Gradle のガイドを除くすべてのガイドが、Maven ラッパーを使用するように更新されました。

今すぐ Open Liberty 25.0.0.6 を入手する

Maven, Gradle, Docker とダウンロード可能なアーカイブとして入手できます。

すべてのブログ投稿を表示