従来のバージョン管理では、major.minor.micro スキームの形に従っており、重要な新しい機能はメジャーリリースでのみ提供されます。これらのメジャーリリースには主要な新機能が含まれていますが、アプリケーションの移行と重要なリグレッションテストの採用を必要とする動作の変更も行われます。その結果、常に複数のメジャーバージョンがサポートされます。Open Liberty のモジュラー機能アーキテクチャーは、ゼロマイグレーションと組み合わせて、major.minor.micro バージョン管理スキームに従うことなく新機能を段階的に配信できるようにします。

メジャーリリースではなく、各 Open Liberty リリースはマイクロまたはパッチリリースとみなされます。これらのパッチリリースは、yy.0.0.nn バージョンスキームに従っています。最初の 2 桁の数字はリリース年を示し、最後の 2 桁の数字は、その年内のリリース番号を示します。最初の桁のセットは毎年変更されますが、リリースは同じ状態です。たとえば、20.0.0.1 (2020 の最初のリリース) と 19.0.0.12 (2019 の最後のリリース) の相違点は、19.0.0.10 と 19.0.0.11 の相違点と同じです。

メジャーリリースストリームがないことはサーバーランタイムでは珍しいことですが、デスクトップおよびモバイルアプリケーションでは一般的です。一部の公開システムでは、ソフトウェアにメジャーバージョンが必要です。その結果、メジャーバージョンが必要な場合は、公開年がスタンドアロンとして使用されます。たとえば、2019 の本ガイドに公開されている Open Liberty ドキュメントでは、2019 年がバージョン番号として使用されます。ただし、このドキュメントは、2019 年のリリースとおよび 2020 年のリリースに適用されます。

OpenShift でアプリケーションを実行する利点の 1 つは、それらを Service (IaaS) ソリューションとしてクラウドホストインフラストラクチャーまたは現在のオンプレミス構造にデプロイできることです。OpenShift CLI または OpenShift Do CLI を使用してアプリケーションを開発できます。次に、Open Liberty コンテナーのアプリケーションをコンテナー化し、コンテナー化したアプリケーションを OpenShift クラスターにデプロイします。

マイクロサービスを OpenShift にデプロイするステップバイステップのチュートリアルは、「Deploying microservices to OpenShift guide」を参照してください。Open Liberty のアプリケーションがどのように各種の OpenShift デプロイメントオプションで使用されるかは、OpenShift ドキュメント を参照してください。

オペレーターは、Kubernetes または OpenShift が提供する最初の自動化を超えたタスクを自動化するようにカスタマイズされている Kubernetes の拡張機能 です。Open Liberty Operator の機能レベルは 5 です。つまり、自動スケーリング、サービスバインディング、OpenShift 証明書管理の統合、および Kubernetes Application Navigator (kAppNav) の統合など、最高レベルのエンタープライズ機能を備えています。

Open Liberty Operator を使用すると、水平の自動スケーリングを設定することにより、リソースの可用性と消費に基づいてアプリケーションインスタンスを作成または削除することで、アプリケーションを高可用性にすることができます。Operator はアプリケーションデプロイメントの管理にも役立ちます。たとえば、アプリケーションの新規コンテナータグをアップロードした後に、Operator デプロイメントファイルの applicationImage フィールドを新規コンテナータグで更新します。次に、Operator はアプリケーションをローリングベースで更新します。

このオペレーターは、永続ストレージまたは高度なストレージのシンプルな構成や、シングルサインオン (SSO) を外部プロバイダーに委任する機能 など、他の本番環境レベルの機能も提供します。オペレーターは、アプリケーション間のバインディング情報の更新を自動化します。つまり、アプリケーションを接続し、特定のアプリケーションがサービスを生成または消費するかどうかに関する情報を維持します。

Kubernetes または OpenShift で使用するために、OperatorHub から Open Liberty Operator をインストール できます。Operator は、OpenShift Container Platform (OCP) から Red Hat 認定 Operator としても利用できます。

ガイド: Deploying microservices to Kubernetes

機能は、server.xml ファイル、およびその他の include ファイルであるシステム設定ファイルで指定されます。機能マネージャーは、server.xml ファイルの featureManager 要素を使用して設定されます。必要な各機能は feature 要素を使用して設定されます。以下の例は、servlet-4.0 および jdbc-4.3 の機能を設定します。

<server>
  <featureManager>
    <feature>servlet-4.0</feature>
    <feature>jdbc-4.3</feature>
  </featureManager>
</server>

ランタイムには、指定する必要のある設定が最小限に保持されるようにデフォルト設定が含まれます。server.xml ファイルで、デフォルト設定の追加またはオーバーライドに必要な機能を指定します。サーバー設定の詳細は「Server configuration overview」を参照してください。

Open Liberty のゼロマイグレーションアーキテクチャーでは、現在のアプリケーションや設定への影響を最小限に抑えて、最新バージョンの Open Liberty に移行できます。ゼロマイグレーションアーキテクチャーでは、動作が必要ない、または予期しない変更は行わずに既存の設定ファイルや変更されていない設定ファイルを Open Liberty ランタイム環境の更新バージョンで使用できることを意味します。

Open Liberty ランタイム環境でプラグ可能な機能を使用すると、既存の API および動作が新規製品バージョンでサポートされ、新しい API および動作が新機能に追加されます。たとえば、Servlet 3.1 および 4.0 仕様の両方がサポートされます。API の動作の変更は新機能のバージョンでのみ行われるため、アプリケーションに適切な機能バージョンを選択することができます。これらのバージョン付けされた機能は、Open Liberty の更新後もサポートされます。

同じ機能バージョンを引き続き使用する場合は、アプリケーションを移行する必要はありません。たとえば、アプリケーションが Servlet 3.1 を使用する場合は、アプリケーションを実行する Open Liberty サーバーには servlet-3.1 機能が必要です。Open Liberty を更新し、他の Servlet 仕様レベルがどの程度サポートされるかに関わらず、servlet-3.1 機能を無限に使用できます。代わりに servlet-4.0 機能を使用する場合のみアプリケーションを移行する必要があります。

サーバーを異なるバージョンの機能を持つように設定しようとすると、Open Liberty は同じ機能のバージョンを組み合わせていないため、エラーが報告されます。つまり、ほとんどの Open Liberty 機能はシングルトン機能です。シングルトン機能は、サーバーで使用できるバージョンを 1 つだけ設定できる機能です。

異なるバージョンのシングルトン機能を必要とするアプリケーションがある場合は、それらを異なるサーバーにデプロイする必要があります。サーバー構成にシングルトン機能の複数のバージョンが含まれている場合は、server.xml ファイルの直接構成または機能の依存関係により、その構成にエラーがあり、その機能のどちらのバージョンも読み込まれません。この問題を解決するには、設定された機能がすべて、そのシングルトン機能の同じバージョンを指定または許容していることを確認してください。両方の機能バージョンにハード要件がある場合は、一部のアプリケーションを別のサーバーに移動する必要があります。

Liberty は、Java EE 7と Java EE 8 仕様がコンポーネント仕様バージョンを共有する場合を除いて、Java EE 7 と Java EE 8 の両方の機能の組み合わせをサポートしていません。サーバー設定で Java EE 7 および Java EE 8 機能を組み合わせると、サーバーは起動時にエラーを報告します。

以下の機能は、Java EE 7 および Java EE 8 の両方に含まれています。

Java EE 7 をサポートする機能の完全リストは、javaee-7.0 機能を参照してください。Java EE 8 をサポートする機能の完全リストは、javaee-8.0 機能を参照してください。

機能が置き換えられた場合は、新しい機能、または機能の組み合わせが、代替機能よりも優れている場合があります。新しい機能は、代替機能の機能を完全には置き換えない可能性があるため、構成を変更するかどうかを決定する前に、シナリオを検討する必要があります。代替機能はサポートされ、設定で使用するために有効ですが、新機能を使用することで設定を改善することができる可能性があります。

他の機能を含む機能は、これらすべての機能が含まれていない新しいバージョンの機能によって置き換えられることがあります。新しいバージョンに含まれない機能は、分離されていると見なされます。アプリケーションが分離された機能の機能に依存する場合は、分離された機能を設定に明示的に追加する必要があります。

以下の表は、置き換えられた Open Liberty 機能を示しています。

サーバー設定ファイルは以下の順序で処理されます。

JAVA_HOME=/opt/ibm/java
WLP_USER_DIR=/opt/wlp-usr

-Xmx512m
-Dmy.system.prop=This is the value.

変数を使用してサーバー設定をパラメーター化することができます。値への変数参照を解決するために、以下のソースを順番に参照します。

変数は ${variableName} 構文を使用して参照されます。

以下の例のように、サーバー設定に変数を指定します。

<variable name="variableName" value="some.value" />

server.xml ファイルに指定されたデフォルト値は、他の値が指定されていない場合にのみ使用されます。

<variable name="variableName" defaultValue="some.default.value" />

コマンドラインから起動時に変数を指定することもできます。これを行うと、コマンドラインで指定された変数は、他のすべての変数ソースをオーバーライドし、サーバーの起動時に変更できません。

環境変数には、変数としてアクセスできます。バージョン 19.0.0.3 の時点で、環境変数名を直接参照することができます。変数を指定したとおりに解決できない場合、server.xml ファイルは環境変数名で以下の差異を探します。

たとえば、server.xml ファイルに ${my.env.var} と入力すると、環境変数が以下の名前で検索されます。

バージョン 19.0.0.3 以前では、以下の例のように env. を環境変数名の開始に追加することで、環境変数にアクセスできます。

<httpEndpoint id="defaultHttpEndpoint"
              host="${env.HOST}"
              httpPort="9080" />

変数の値は、常に単純なタイプ変換を持つ文字列として解釈されます。そのため、ポート一覧 (80,443 など) は、2 つのポート番号ではなく単一の文字列として解釈されることがあります。以下の例のように list 関数を使用すると、, を使用して変数の置換を強制的に分割できます。

<mongo ports="${list(mongoPorts)}" hosts="${list(mongoHosts)}" />

整数値を持つ変数では、単純な算術がサポートされています。演算子の左側および右端には、変数または数字のいずれかを指定できます。以下の例のように、演算子は +、-、*、または / になります。

<variable name="one" value="1" />
<variable name="two" value="${one+1}" />
<variable name="three" value="${one+two}" />
<variable name="six" value="${two*three}" />
<variable name="five" value="${six-one}" />
<variable name="threeagain" value="${six/two}" />

事前定義された変数は複数あります。

設定は複数のファイルで構成できるため、2 つのファイルが同じ構成を提供する可能性があります。このような状況では、サーバー構成は一連の単純なルールに従ってマージされます。Open Liberty では、設定はシングルトンとファクトリー設定に分離され、マージに関する独自のルールがあります。シングルトン設定は単一の要素 (例: ロギング) を設定するのに使用されます。ファクトリー設定は、アプリケーション全体やデータソースなど、複数のエンティティーを設定するために使用されます。

<server>
    <logging a="true" />
    <logging b="false" />
</server>

<server>
    <logging a="true" b="false" />
</server>

<server>
    <logging a="true" b="true" />
    <logging b="false" />
</server>

<server>
    <logging a="true" b="false" />
</server>

<server>
    <featureManager>
        <feature>servlet-4.0</feature>
    </featureManager>
    <featureManager>
        <feature>restConnector-2.0</feature>
    </featureManager>
</server>

<server>
    <featureManager>
        <feature>servlet-4.0</feature>
        <feature>restConnector-2.0</feature>
    </featureManager>
</server>

<server>
    <webApplication id="app1" location="myapp.war" />
    <webApplication location="myapp2.war" />
    <webApplication id="app1" contextRoot="/myawesomeapp" />
</server>

デフォルトの場所に加えて、include 要素を使用すると追加の設定ファイルを組み込むことができます。サーバー設定ファイルに別のファイルへの包含参照が含まれると、サーバーは参照されたファイルの内容を include 要素の代わりにインラインとして処理します。

以下の例では、other2.xml ファイルの内容を処理する前に、サーバーは other.xml ファイルの内容を処理します。

<server>
    <include location="other.xml" />
    <include location="other2.xml" />
</server>

デフォルトでは、include ファイルが存在する必要があります。include ファイルが存在しない場合は、以下の例のように optional 属性を true に設定します。

<server>
    <include location="other.xml" optional="true" />
</server>

ファイルを指定する場合は、onConflict 属性を指定して、通常のマージルールを変更できます。onConflict 属性の値を IGNORE または REPLACE に設定できます。

<server>
    <include location="other.xml" onConflict="IGNORE" />
    <include location="other2.xml" onConflict="REPLACE" />
</server>

location 属性は、相対パスまたは絶対ファイルパス、もしくは HTTP URL に設定できます。

Open Liberty のほとんどの構成は自己完結型ですが、設定を共有すると便利なことがよくあります。たとえば、JDBC ドライバー構成は複数のデータソースで共有される場合があります。server 要素の直接の子として定義されるファクトリー設定要素を参照できます。

設定への参照は、常に参照される要素の id 属性を使用します。参照を行う設定要素は、以下の例のように常に Ref で終わる属性を使用します。

<server>
  <dataSource jndiName="jdbc/fred" jdbcDriverRef="myDriver" />
  <jdbcDriver id="myDriver" />
</server>

サーバーは、サーバーの XML 設定で更新の有無を監視し、変更が検出されると動的に再読み込みします。非 XML ファイル (server.env、bootstrap.properties、および jvm.options) への変更は、起動時にのみ読み込まれるため動的ではありません。ローカルディスクのサーバー XML 設定ファイルは、すべて 500ms の更新で監視されます。XML 設定ファイルモニタリングの頻度を設定できます。たとえば、10 分ごとにサーバーを監視するように設定するには、以下を実行します。

<config monitorInterval="10m" />

MBean が通知された場合に限りファイルシステムのポーリングおよび再読み込みを無効にするには、以下を指定します。

<config updateTrigger="mbean" />

サーバーを実行すると、設定を参照するログメッセージが出力される可能性があります。ログの参照では、XPath に似た構造を使用して構成要素を指定します。要素名は、角括弧内の id 属性の値で指定します。サーバー設定に id が指定されていないと、id はが自動的に生成されます。以下のサーバーの XML 設定例に基づいて、dataStore 要素と子 dataSource は、ログで dataStore[myDS] and dataStore[myDS]/dataSource[default-0] として識別されます。

<server>
    <dataStore id="myDS">
        <dataSource />
    </dataStore>
</server>

開発モードで Open Liberty を実行するには、Open Liberty Maven プラグイン または Open Liberty Gradle プラグイン を有効にし、以下のいずれかのコマンドを実行します。

Maven: mvn liberty:dev

Gradle: gradle libertyDev

Open Liberty スレッドプールのセルフチューニングプロセスは 1.5 秒ごとに実行されます。スレッドプールコントローラーは、サーバーの起動時にスレッドプールのパフォーマンスに関する一連のデータを維持します。スループットは、コントローラーが各サイクルで完了するタスクの数によって決まります。コントローラーは、以前に試行したさまざまなプールサイズのスループットを記録します。この履歴スループットデータは、現在のサイクルのスループットと比較され、プールの最適なサイズを決定します。サイクルごとに、プールサイズは徐々に増減したりせず、そのまま残ります。

場合によっては、決定を導くための履歴データがありません。たとえば、プールが各サイクルで拡大し、現在のサイクルがこれまでの最大サイズであれば、大きなプールサイズのスループットに関するデータが存在しません。このような場合、コントローラーはプールのサイズを大きくするかどうかを無作為に決定します。次に、その決定の結果に基づいて次のサイクルに再調整します。このプロセスは、さまざまなサイズのスレッドプールを試してパフォーマンスを確認し、設定とワークロードの最適値を決定するヒューマンスレッドプールチューナーに似ています。

各 1.5 秒のサイクル中に、スレッドプールコントローラーは次の自動調整操作を実行します。

スレッドプールサイズ以外のさまざまな要因は、Open Liberty サーバーのスループットに影響を与える可能性があります。プールサイズと確認されるスループットの関係は、完全にスムーズまたは連続的ではありません。したがって、過去のスループットデータから導出される予測を改善するために、コントローラーは、最も近い大きいプールサイズと小さいプールサイズだけでなく、両方向の増分もいくつか考慮します。

ほとんどの環境、設定、およびワークロードでは、Open Liberty スレッドプールを手動で設定またはチューニングする必要がありません。スレッドプールはセルフチューニングされ、最適なサーバースループットを提供するために必要なスレッドの数を決定します。スレッドプールコントローラーは、coreThreads 属性および maxThreads 属性の定義範囲内のプール内のスレッド数を継続的に調整します。ただし、coreThreads 属性または maxThreads 属性の設定が必要になる場合があります。以下のセクションでは、これらの属性を説明し、手動での調整が必要になる可能性がある条件の例を提供します。

Open Liberty スレッドプールコントローラーは、さまざまなワークロードと設定を処理するように設計されています。場合によっては、coreThreads 属性および maxThreads 属性の調整が必要になる場合があります。ただし、最初にデフォルトの動作を試して、調整を行う必要があることを確認します。

エグゼキューター管理

ロギングコンポーネントはサーバー設定で制御できます。ロギングコンポーネントは、logging 要素を使用すると server.xml に完全に設定できます。ただし、server.xml が処理される前にロギングが初期化されるため、server.xml 経由でロギングを設定すると、ログエントリーは後で別のログ設定を使用することがあります。このため、boostrap.properties を使用し、場合によっては環境変数を使用してロギング設定を行うこともできます。

以下のセクションでは、一般的なロギング設定の例を紹介します。

com.ibm.ws.logging.max.file.size=100
com.ibm.ws.logging.max.files=3
com.ibm.ws.logging.console.log.level=OFF
com.ibm.ws.logging.copy.system.streams=false

WLP_LOGGING_MESSAGE_FORMAT=json
WLP_LOGGING_MESSAGE_SOURCE=
WLP_LOGGING_CONSOLE_FORMAT=json
WLP_LOGGING_CONSOLE_LOGLEVEL=info
WLP_LOGGING_CONSOLE_SOURCE=message,trace,accessLog,ffdc,audit

docker run -e "WLP_LOGGING_CONSOLE_SOURCE=message,trace,accessLog,ffdc"
           -e "WLP_LOGGING_CONSOLE_FORMAT=json"
           -e "WLP_LOGGING_CONSOLE_LOGLEVEL=info"
           -e "WLP_LOGGING_MESSAGE_FORMAT=json"
           -e "WLP_LOGGING_MESSAGE_SOURCE=" open-liberty

websphere.log.provider=binaryLogging-1.0
com.ibm.ws.logging.console.log.level=OFF
com.ibm.ws.logging.copy.system.streams=false

binaryLog view defaultServer

以下の表は、同等の server.xml、bootstrap.properties、および環境変数の設定と簡単な説明を示しています。設定に関するドキュメントは、logging 要素の設定リファレンスに記載されています。

開発および実稼働環境の同等性 は、12 要素のアプリケーション の要素の 1 つです。これは、最新のアプリケーションを構築するための方法論です。開発および実稼働環境の同等性に関する概念は、時間、人員、およびツールについて、開発環境、ステージング環境、実稼働環境を同等に保つことです。開発プロセスを簡素化するために、開発者は多くの場合、実稼働環境とは異なる開発でツールを使用します。たとえば、ローカルの Maven ビルドを使用して開発中のアプリケーションのプロジェクトをビルドすることはできますが、アプリケーションは実稼働環境の Docker コンテナーにデプロイされる可能性があります。開発環境ではテストに合格しますが、環境間の違いにより、本番環境ではテストが失敗する可能性があります。MicroShed テストは、本番環境と同様の環境でアプリケーションをテストすることで、開発および実稼働環境の同等性を実現するのに役立ちます。

コンテナーを使用して、異なる環境にアプリケーションをデプロイすることができます。Testcontainers フレームワークを使用すると、テスト環境でコンテナーを使用できます。Microshed Testing は MicroProfile および Jakarta EE の開発者が実稼働環境と似た環境でアプリケーションをテストするための Java ライブラリーです。Microshed Testing は Testcontainers フレームワークを実装し、テストで開発と実稼働環境の同等性をサポートします。

MicroShed テストでは、以下の例のように統合テストを作成できます。

@MicroShedTest
public class BasicJAXRSServiceTest {

    @Container
    public static ApplicationContainer app = new ApplicationContainer()
                    .withAppContextRoot("/myservice");

    @RESTClient
    public static PersonService personSvc;

    @Test
    public void testGetPerson() {
        Long bobId = personSvc.createPerson("Bob", 24);
        Person bob = personSvc.getPerson(bobId);

        assertEquals("Bob", bob.name);
        assertEquals(24, bob.age);
        assertNotNull(bob.id);
    }

    @Test
    public void testGetUnknownPerson() {
        assertThrows(NotFoundException.class, () -> personSvc.getPerson(-1L));
    }
}

@MicroShedTest アノテーションは、リポジトリーで Dockerfile ドキュメントを検索し、Docker コンテナーでアプリケーションを起動し、テストを開始する前にアプリケーションが準備状態になるのを待ちます。@Container アノテーションは、実行中のアプリケーションコンテナーに、HTTP 要求を送信しやすくする PersonService クラスの REST クライアントプロキシーを挿入します。@RESTClient アノテーションは、HTTP POST リクエストを実行中のコンテナーに送信します。これにより、PersonService#createPerson エンドポイントがトリガーされ、生成された ID を返します。生成された ID を使用すると、HTTP GET リクエストを送信して、作成したレコードを読み込むことができます。JSON 応答は、JSON-B トークンを使用して Person オブジェクトに自動的に変換します。@Test アノテーションは HTTP GET リクエストを送信し、存在しない -1 ID の Person オブジェクトを見つけます。アノテーションは、アプリケーションコンテナーが HTTP 404 例外を返すことをアサートします。

ガイド: Testing a MicroProfile or Jakarta EE application

アプリケーションは、単一のモジュールを使用した単純なアプリケーションであるか、または複数のモジュールで構成される複雑なアプリケーションであっても、ビルドおよびテストできます。

プロジェクトの詳細と依存関係を定義したら、Maven はすべての依存関係を自動的にダウンロードしてインストールします。また、ビルド後にアプリケーションの自動テストを実行します。アプリケーションの更新後にテストに合格しないと、ビルドは失敗します。コードを修正する必要があります。

Maven プラグインに以下のコーディネートが必要です。

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

Maven および Liberty Maven プラグインを使用して簡単な Web サーブレットアプリケーションを設定する方法は、「Building a web application with Maven」を参照してください。

Jakarta EE アプリケーションは、1 つのエンティティーとして連携する複数のモジュールで構成されます。Maven および Open Liberty を使用して複数のモジュールでアプリケーションをビルドする方法は、「Creating a multi-module application」を参照してください。

分散トレースは、分散システムを介して伝播する要求を調べて記録することにより、マイクロサービスのトラブルシューティングに役立ちます。これにより、開発者は、このような要求のデバッグという難しいタスクに取り組むことができます。分散トレースシステムを導入しないと、ワークフローを分析して、いつ誰がリクエストを受信したか、いつ誰がレスポンスを返したかを特定することは困難です。

アプリケーション内のマイクロサービス間でのロギング要求を監視およびトレースする方法は、「Enabling distributed tracing in microservices」を参照してください。

監視可能性をマイクロサービスに組み込むと、システムの内部ステータスが外部化され、オペレーションチームがマイクロサービスシステムをより効果的に監視できるようになります。実稼働環境でマイクロサービスが実行しているときにオペレーションチームが使用できるメトリクスを生成するようにマイクロサービスを作成することが重要になります。

メトリクスは、さまざまな場所から作成されます。アプリケーション、Open Liberty ランタイム、および Java 仮想マシンから取得できます。MicroProfile Metrics は、Open Liberty サーバーおよびデプロイされたアプリケーションが生成したすべてのメトリクスにアクセスできる /metrics エンドポイントを提供します。これらは、Prometheus などのデータベースツールに収集および保存でき、Grafana などのダッシュボードに表示されます。

メトリクスには、カウンター、ゲージ、タイマー、ヒストグラム、メーターなど、さまざまな形式があります。MicroProfile Metrics 機能を使用して Open Liberty アプリケーションでメトリクスを有効にすることができます。

利用可能な Open Liberty メトリクスの一覧は、「metrics reference list」を参照してください。

MicroProfile Metrics を使用してマイクロサービスからメトリクスを有効にして提供する方法は、「Providing metrics from a microservice」を参照してください。

ヘルスチェックは、マイクロサービスおよびその依存関係のステータスを検証するために使用できる特別な REST API です。MicroProfile Health を使用すると、アプリケーション内のサービスがそれぞれのヘルスをセルフチェックし、全体的なヘルスステータスを定義済みのエンドポイントに公開できます。

セルフチェックは、次のようなサービスが必要とするすべてのものを評価するために使用できます。

MicroProfile Health を使用すると、liberty アプリケーションのサービスを有効にして、liveness および readiness をセルフチェックできます。liveness チェックは、サービスでバグまたはデッドロックが発生したかどうかを決定します。このチェックに失敗すると、サービスは実行されず、終了されます。このチェックは Kubernetes liveness プローブに対応し、チェックが失敗すると Pod を自動的に再起動します。readiness チェックは、サービスがリクエストを処理する準備ができているかどうかを判断します。このチェックは、Kubernetes の readiness プローブに対応します。

MicroProfile Health を使用してマイクロサービスヘルスチェックを有効にして報告する方法は、「Adding health reports to microservices」を参照してください。