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

メジャーリリースではなく、Open Liberty の各リリースはマイクロまたはパッチリリースとみなされます。これらのパッチリリースは、yy.0.0.nn バージョンスキームに従います。最初の 2 桁はリリースの年数を示し、最後の 2 桁の数字はこの年内のリリース数を示します。最初の数値セットは毎年変わりますが、リリースは同等です。たとえば、20.0.0.1（20.0.0.1 の最初のリリース）と 19.0.0.12（20.0.0.12 の最後のリリース）の相違点は 19.0.0.10 と 19.0.0.11 の相違点と同じです。

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

設定された機能がすべてインストールされていると、1 つの設定ファイルのセットが、変更なしに複数のバージョンの Open Liberty で動作します。ユーザー設定ファイルには、ランタイムが新規バージョンに更新されると変更する必要はありません。Open Liberty は、ランタイムのアクティブなバージョンに適用しない設定を無視します。

Open Liberty 機能はサーバー設定にエンコードされ、アップグレード中は変更されません。Java 仕様の動作変更を規定するなど、動作の変更が発生すると、その変更は新しいバージョンの機能に導入されます。既存のアプリケーションやそれらの設定は、古い機能バージョンで引き続き使用できますが、新しいアプリケーションは新しい動作で新しい機能バージョンを使用できます。

たとえば、Open Liberty は Servlet 3.1 および Servlet 4.0 の両方の仕様をサポートします。Servlet 4.0 仕様には、アプリケーションの動作の変更を可能にする以前のサーブレットバージョンへの明確化が含まれます。Open Liberty は、このような動作の変更を servlet-4.0 機能に制限し、servlet-3.1 機能の既存の動作を維持します。アプリケーションがサーブレット 3.1 仕様に設定されている場合は、他の サーブレット仕様レベルをサポートするものに関係なく、ランタイム更新全体で servlet-3.1 機能を使用できます。代わりに servlet-4.0 機能を設定しない限り、アプリケーションを変更する必要はありません。詳細は、「機能の 概要 」を参照してください。

Open Liberty はランタイムバージョン間で変更されないように設計されていますが、まれなケースで使用できなくなることがあります。このような例外は、以下のカテゴリーのいずれかに分類されます。

移行中のアーキテクチャーは、既存の設定およびアプリケーションファイルの移行を必要とせずに開発者や企業時間および教育を保存します。開発者はランタイム更新を管理するのではなく、アプリケーションに集中できますが、既存のサーバー設定のパフォーマンスおよび管理性を向上できます。

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

マイクロサービスの OpenShift へのデプロイに関する段階的なチュートリアルについては、『 OpenShift へのマイクロサービスのデプロイ』を参照してください。Open Liberty 上のアプリケーションを異なる OpenShift デプロイメントオプションと共にどのように使用できるかについての詳細は、OpenShift の ドキュメントを参照してください。

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

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

また、この Operator は、永続ストレージの単純な設定や、単一署名(SSO)を外部プロバイダーに委譲する機能など、他の実稼働環境グレードの機能を 提供します。Operator はアプリケーション間のバインディング情報の更新を自動化するため、アプリケーションは接続し、特定のアプリケーションがサービスを生成または消費するかどうかについての情報を維持します。

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

Guide: マイクロサービスの Kubernetes へのデプロイ

機能は、server.xml ファイルおよびその他の含まれるファイルであるシステム設定ファイルに指定されます。機能マネージャーは、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 ファイルのデフォルト設定に追加または上書きする機能と共に、必要な機能を指定し ます。サーバー設定の詳細は、「サーバー設定の 概要」を参照 してください。

Open Liberty zero-migration アーキテクチャーでは、現在のアプリケーションと設定に最低限の影響を最小限に抑えて、最新バージョンの 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-3.1 機能の使用を継続できます。代わりに servlet-4.0 機能の使用を選択している場合に限り、アプリケーションを移行する必要があります。

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

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

Java EE 7 および Java EE 8 仕様がコンポーネント仕様バージョンを共有している場合を除き、liberty は 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)}" />

Simple 演算は、整数値を持つ変数でサポートされます。演算子の左側と右辺は、変数または数字のいずれかになります。以下の例のように、演算子は +、-、*、または / のいずれかになります。

<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 要素 の代わりにインラインに含まれているかのように、参照されるファイルの内容を処理します。

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

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

デフォルトでは、包含ファイルが存在する必要があります。include ファイルが存在しない場合には、以下の例のように オプション の属性を 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 ] および dataStore[ myDS ]/dataSource[default-0] としてログで識別されます。

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

Open Liberty Operator でアプリケーションをデプロイする場合、Operator は Open Liberty リソースを監視し、リソースの現在の状態を、設定したリソースの状態と比較します。リソースの現在の状態と、設定した状態の間に不一致が存在する場合は、Operator は Kubernetes リソースの作成、更新、または削除を行い、設定した状態に戻ります。これらの Kubernetes リソースには、デプロイメント、サービス、または ルート が含まれる可能性があります。Operator なしでは、デプロイメント、サービス、ルートその他の Kubernetes リソースを手動で作成する必要があります。これには、時間のかかる学習曲線が関係する可能性があります。Operator を使用して、アプリケーションイメージ、サービスポート、およびクラスター外部でアプリケーションを公開するかどうかなど、アプリケーションの詳細を指定できます。次に、Operator はすべての Kubernetes リソースを作成し、管理します。今回のリリースより、多くのリソースではなく、単一の OpenLibertyApplication リソースのみを管理するようになりました。さらに、Operator はクラスター内のアプリケーションに関連するイベントを継続的に監視し、データおよびリソースを同期するために必要なアクションを実行します。Operator は Kubernetes リソースの管理を容易にするため、Operator はクラウドデプロイメントの詳細を多く処理しながらアプリケーションに集中することができます。

Open Liberty Operator は Runtime Component Operator をベースとしています。これはランタイム固有の Operator にインポートして標準化されたエンタープライズ機能を提供するための汎用演算子です。そのため、イメージストリームの使用や高可用性のためにアプリケーションの複数のインスタンスを実行する機能など、これらの 2 つの Operator 間に共通機能が存在します。Open Liberty Operator を使用すると、Operator コンテナーおよびコントローラーは Kubernetes Pod にデプロイされ、Operator は kind: OpenLibertyApplication ステートメントで受信リソースをリッスンし ます。OpenLibertyApplication カスタムリソース(CR ) を作成する場合、Operator はアプリケーションがクラスターで実行されるために必要な Kubernetes リソースを管理します。

Open Liberty Operator にはケイパビリティーレベル 5 があり、以下の機能を含む エンタープライズレベルの機能を持つことになり ます。

ストレージのサイズのみを指定 し、ストレージをマウントする場所を指定して、アプリケーションの永続性を有効 にできます。次に、Operator はストレージ要求を作成し、管理します。永続ボリューム要求(PVC)の追加詳細の設定を可能にする高度なモードを利用できます。また、サーバーメモリーダンプやサーバートレースの収集など、サービス関連の操作に単一のストレージを設定し、使用することもできます。サーバーメモリーダンプおよびサーバートレースの収集に関する詳細は、「 Day-2 operations 」を参照してください。

Operator の設定後に、Open Liberty と Kubernetes クラスターで可観測性のロギングおよび監視ツールを統合 することができます。監視するさまざまな種類の Open Liberty データを選択できます。ロギングイベントを可視化および追跡するには、提供される Open Liberty Kibana ダッシュボードのいずれかをデプロイします。MicroProfile Metrics、Prometheus、および Grafana を使用してメトリクスデータを収集し、収集し、視覚化することで Open Liberty メトリクスをモニターできます。また、MicroProfile Health を有効にして liveness チェックおよび readiness チェックを実行して、Kubernetes がコンテナーの正常性を確認できるようにすることもできます。

Kubernetes または OpenShift で使用するために 、OperatorHub から Open Liberty Operator をインストール できます。この オペレーターは、OpenShift Container Platform(OCP)から Red Hat 認定演算子としても利用 できます。Open Liberty Operator ドキュメントでは、基本設定、カスタムリソース定義(CRD)パラメーター、Open Liberty コンソールのロギング環境変数、永続ストレージ仕様など、Operator の設定に関する詳細が記載されています。

dev モードで 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 スレッドプールに手動の設定またはチューニングは必要ありません。スレッドプールの自己チューニングは、最適なサーバーのスループットを提供するために必要なスレッド数を決定します。スレッドプールコントローラーは、コアスレッド および maxThreads 属性に定義されたバインド内のプール内のスレッド数を継続的に調整 し ます。ただし、コアスレッドまたは maxThreads 属性の設定が 必要 になることがあります。以下のセクションでは、これらの属性を説明し、手動で調整する必要がある可能性のある条件の例を示します。

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

エグゼキューター管理

ロギングコンポーネントはサーバー設定を使用して制御できます。logging コンポーネントは、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 要素の config reference で利用できます。

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

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

MicroShed Testing を使用すると、以下の例のようなインテグレーションテストを作成できます。

@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 アノテーション は PersonService クラスの REST Client プロキシーを注入します。これは、実行中のアプリケーションコンテナーで HTTP 要求を送信するのに役立ちます。@RESTClient アノテーションは、HTTP POST リクエストを実行中のコンテナーに送信します。PersonService#createPerson エンドポイントをトリガーし、生成された ID を返します。生成された ID を使用すると、HTTP GET リクエストを送信して、作成されたレコードを読み取ることができます。JSON 応答は、JSON-B トークンを使用して Person オブジェクトに自動的に変換します。@ Test アノテーション は HTTP GET リクエストを送信し、-1 ID がない Person オブジェクトを検索します。アノテーションは、アプリケーションコンテナーが HTTP 404 例外を返すことをアサートします。

Guide: MicroProfile または Jakarta EE アプリケーションのテスト

単一のモジュールを持つシンプルなアプリケーションか、複数のモジュールで構成されるより複雑なアプリケーションかどうか、アプリケーションを構築してテストできます。

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

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

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

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

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

分散トレースは、分散システムで伝播する際に要求を検査およびロギングすることでマイクロサービスのトラブルシューティングに役立ちます。これにより、開発者はこれらのリクエストのデバッグの困難な作業に対応できます。分散トレースシステムが配置されない場合、リクエストを受信する時または応答が返されるタイミングと、ワークフローおよびピンポイントの分析が困難です。

アプリケーションのマイクロサービス全体でのロギング要求を監視およびトレースする方法は、「マイクロサービスでの 分散トレースの有効化」を参照してください。

Open Liberty では、アプリケーション、MicroProfile Metrics によって提供される REST エンドポイントスタイルのメトリクス、および Java Management Extensions(JMX)メトリクスを監視できるメトリクスが 2 つ利用できます。

MicroProfile Metrics には、Prometheus などのモニタリングツールや REST 要求を実行できるすべてのクライアントがアクセスできます。JMX メトリクスは、JMX サーバーと通信できる Java ベースの監視ツールやカスタム JMX クライアントによる使用に適しています。

ヘルスチェックは、マイクロサービスとその依存関係のステータスを検証するために使用できる特別な REST API 実装です。MicroProfile Health を使用すると、アプリケーションのマイクロサービスでそれらの健全性を自己チェックし、全体的なヘルスステータスが定義されたエンドポイントに公開されます。

ヘルスチェックは、依存関係、システムプロパティー、データベース接続、エンドポイント接続、リソースの可用性など、マイクロサービスが必要とするものをすべて評価できます。サービスは、MicroProfile Health によって提供される API を実装して可用性として報告します。マイクロサービスが利用可能になると、UP のステータスを報告します。マイクロサービスが利用できない場合は、DOWN のステータスを報告します。サービスオーソライザーはこれらのステータスレポートを使用して、アプリケーション内でマイクロサービスを管理し、スケーリングする方法を決定できます。ヘルスチェックは、Kubernetes の liveness および readiness プローブと対話すること もできます。

たとえば、マイクロサービスベースの銀行アプリケーションでは、ログインマイクロサービス、バランス転送マイクロサービス、および請求用のマイクロサービスにヘルスチェックを実装する場合があります。バランス転送マイクロサービスのヘルスチェックがバグまたはデッドロックを検出すると、DOWN ステータスを返します。この場合、/health/live エンドポイントが Kubernetes liveness プローブで設定されている場合、プローブはマイクロサービスを自動的に再起動します。マイクロサービスを再起動すると、ユーザーにダウンタイムやエラーが発生し、アプリケーション内の他のマイクロサービスの機能が維持されます。

@Liveness
@ApplicationScoped
public class MemoryCheck implements HealthCheck {
 @Override
 public HealthCheckResponse call() {
        // status is up if used memory is < 90% of max
        MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
        long memUsed = memoryBean.getHeapMemoryUsage().getUsed();
        long memMax = memoryBean.getHeapMemoryUsage().getMax();

        HealthCheckResponse response = HealthCheckResponse.named("heap-memory")
                .withData("used", memUsed)
                .withData("max", memMax)
                .state(memUsed < memMax * 0.9)
                .build();
        return response;
    }
}

{
  "status": "UP",
  "checks": [
    {
      "name": "heap-memory",
      "status": "UP",
      "data": {
        "used": "1475462",
        "max": ”51681681"
      }
    }
  ]
}

@Readiness
@ApplicationScoped
public class DatabaseReadyCheck implements HealthCheck {

    @Override
    public HealthCheckResponse call() {

        if (isDBConnected()) {
           return HealthCheckResponse.up(“databaseReady”);
        }
        else {
           return HealthCheckResponse.down(“databaseReady”);
        }
    }
}

{
  "status": ”DOWN",
  "checks": [
    {
      "name": ”databaseReady",
      "status": ”DOWN",
    }
  ]
}