back to all blogsすべてのブログ投稿を表示

Open Liberty 23.0.0.12におけるMicroProfile 6.1サポート, Liberty Toolsアップデート, 他

image of author image of author
David Mueller and 田中 孝清 (翻訳) 2023年12月12日
発表 , microprofile , リリース , maven , セキュリティ , spring , gradle , メトリック , 開発者経験 ,
他言語版へのリンク: English ,

いますぐOpen Liberty 23.0.0.12を使用してアプリを実行するには

Maven, Gradle, Docker, およびダウンロードしたアーカイブ から利用いただけます。

Ask a question on Stack Overflow

MicroProfile 6.1がサポートされました

MicroProfile 6.1 はマイナーリリースで、MicroProfile 6.0 と互換性があります。MicroProfile 6.1 には、Jakarta EE 10 Core Profile API と以下の MicroProfile コンポーネント仕様が含まれます：

次の 3 つの仕様がマイナーアップデートされ、他の 5 つの仕様に変更はありません：

  • MicroProfile Metrics 5.1

  • MicroProfile Telemetry 1.1

  • MicroProfile Config 3.1 (主な更新はTCKテストで、テストががCDI 3.xまたはCDI 4.0 Liteに対しても実行されるようになった)

各機能の変更の詳細と利用方法については、以下のセクションをご覧ください。

MicroProfile Metrics 5.1を使用して、ヒストグラムおよびタイマーメトリクスで追跡される統計情報を構成

MicroProfile Metrics 5.1 には、ヒストグラムおよびタイマー・メトリクスが追跡および出力する統計情報を構成するための新しい MicroProfile Config プロパティが含まれています。MicroProfile Metrics 5.0 では、ヒストグラムおよびタイマー・メトリクスは、max 記録値、すべての値の sum、記録された値の count、および 50 パーセンタイル、75 パーセンタイル、95 パーセンタイル、98 パーセンタイル、99 パーセンタイル、99.9 パーセンタイルの静的なセットのみを追跡および出力します。これらの値は Prometheus フォーマットで /metrics エンドポイントに出力されます。

MicroProfile Metrics 5.1 で導入されたプロパティでは、ヒストグラムとタイマー・メトリクスのパーセンタイルのカスタム・セットとヒストグラム・バケットのカスタム・セットを定義できます。ヒストグラム・バケツのデフォルト・セットを有効にするための構成プロパティも含まれており、これにはバケツ・セットの上限と下限を定義するためのプロパティも含まれます。

以下の表のプロパティは、以下の構文を使用して、セミコロンで区切られた値定義のリストを定義できます：

metric_name=value_1[,value_2…value_n]
Property Description

mp.metrics.distribution.percentiles

  • 追跡および出力するヒストグラムとタイマー・メトリクスのマッチングのために、パーセンタイルのカスタム・セットを定義します。

  • メトリック名のペアに整数値と 10 進値のセットを受け付けます。

  • メトリック名のペアリングで値が提供されない場合、パーセンタイル出力を無効にするために使用できます。

mp.metrics.distribution.histogram.buckets

  • 追跡および出力するヒストグラム・メトリクスに一致する（累積的な）ヒストグラム・バケツのカスタム・セットを定義します。

  • メトリック名のペアに整数値と 10 進値のセットを受け入れます。

mp.metrics.distribution.timer.buckets

  • 追跡および出力するタイマー・メトリクスに一致する（累積）ヒストグラム・バケツのカスタム・セットを定義します。

  • メトリック名のペアに、時間単位（ms、s、m、h など）を付加した 10 進値のセットを受け入れます。

mp.metrics.distribution.percentiles-histogram.enabled

  • 監視ツールでパーセンタイル構成を可能にするために、デフォルトのヒストグラムバケットの大規模なセットを提供するために、一致するヒストグラムまたはタイマーメトリックを構成します。

  • メトリック名のペアに true/false を指定します。

mp.metrics.distribution.histogram.max-value

  • タイマーのパーセンタイル・ヒストグラムが有効な場合、このプロパティは報告されるバケットの上限を定義します。

  • メトリック名のペアには、単一の整数値または 10 進値を受け入れます。

mp.metrics.distribution.histogram.min-value

  • タイマーのパーセンタイル・ヒストグラムが有効な場合、このプロパティは報告されるバケツの下限値を定義します。

  • メトリック名のペアに対して、単一の整数値または 10 進値を受け入れます。

mp.metrics.distribution.timer.max-value

  • ヒストグラムでパーセンタイル・ヒストグラムが有効な場合、このプロパティは報告されるバケットの上限を定義します。

  • メトリック名のペアには、時間単位（ms、s、m、h など）を付加した単一の 10 進値を受け入れます。

mp.metrics.distribution.timer.min-value

  • ヒストグラムでパーセンタイル・ヒストグラムが有効な場合、このプロパティは報告されるバケットの下限を定義します。

  • メトリック名のペアに、時間単位（ms、s、m、h など）を付加した単一の 10 進値をを受け入れます。

プロパティによっては、与えられたメトリック名に対して複数の値を受け入れることができるものもあれば、単一の値しか受け入れることができないものもあります。メトリック名の末尾には、ワイルドカードとしてアスタリスク (*) を使用できます。 たとえば、`mp.metrics.distribution.percentiles`は次のように定義できます：

mp.metrics.distribution.percentiles=alpha.timer=0.5,0.7,0.75,0.8;alpha.histogram=0.8,0.85,0.9,0.99;delta.*=

この例では、50 パーセンタイル、70 パーセンタイル、75 パーセンタイル、80 パーセンタイルの値を追跡して出力する alpha.timer タイマーメトリックを作成します。ヒストグラムメトリクスの alpha.histogram は、80、85、90、99パーセンタイルの値を出力します。パーセンタイルは delta.* とマッチするヒストグラムやタイマーの指標では無効になります。

次の例では、前の例を拡張して、 mp.metrics.distribution.timer.buckets プロパティを使用して、 alpha.timer タイマー・メトリックのヒストグラム・バケットを定義します：

mp.metrics.distribution.timer.buckets=alpha.timer=100ms,200ms,1s

この構成では、0～100ms、0～200ms、0～1秒に収まる継続時間のカウントを追跡して出力するように、メトリクスのランタイムに指示します。ヒストグラム・バケットは累積的に動作するため、これらの値は範囲を表します。

RESTエンドポイントの alpha.timer メトリクスに対応するPrometheusの出力は次のようになります：

# HELP alpha_timer_seconds_max
# TYPE alpha_timer_seconds_max gauge
alpha_timer_seconds_max{scope="application",} 5.633
# HELP alpha_timer_seconds
# TYPE alpha_timer_seconds histogram (1)
alpha_timer_seconds{scope="application",quantile="0.5",} 0.67108864
alpha_timer_seconds{scope="application",quantile="0.7",} 5.603590144
alpha_timer_seconds{scope="application",quantile="0.75",} 5.603590144
alpha_timer_seconds{scope="application",quantile="0.8",} 5.603590144
alpha_timer_seconds_bucket{scope="application",le="0.1",} 0.0 (2)
alpha_timer_seconds_bucket{scope="application",le="0.2",} 0.0 (2)
alpha_timer_seconds_bucket{scope="application",le="1.0",} 1.0 (2)
alpha_timer_seconds_bucket{scope="application",le="+Inf",} 2.0  (2) (3)
alpha_timer_seconds_count{scope="application",} 2.0
alpha_timer_seconds_sum{scope="application",} 6.333
1 Prometheus のメトリックタイプは histogram で、分位数またはパーセンタイルとバケットの両方がこのタイプで表現されます。
2 le タグは less than を表し、秒に変換されてバケットを定義します。
3 Prometheusはすべてのヒットをカウントする +Inf バケットを必要とします。

さらに、@RegistryScope アノテーションはCDI修飾子になりました。

MicroProfile Metricsの詳細については、以下を参照してください：

Telemetry 1.1 での Java EE および Jakarta EE サポートの拡張

MicroProfile Telemetry 1.1 は、1.19.0 から更新された OpenTelemetry-1.29.0 を使用するため、最新の Open Telemetry テクノロジーを利用できます。

この機能は、以下のプログラミングモデルの組み合わせと互換性があります：

  • Java EE 7 と MicroProfile 1.4 の組合わせ

  • Java EE 8 と MicroProfile 4.1 の組合わせ

  • Jakarta EE 9 と MicroProfile 5.0 の組合わせ

  • Jakarta EE 10 と MicroProfile 6.1 の組合わせ

この機能を有効にするには、次の機能定義を server.xml ファイルに追加します：

<features>
   <feature>mpTelemetry-1.1</feature>
</features>

また、server.xml ファイルでアプリケーションにたいしてサードパーティ API を可視化する必要があります：

<webApplication location="demo-microprofile-telemetry-inventory.war" contextRoot="/">
    <!-- enable visibility to third party apis -->
    <classloader apiTypeVisibility="+third-party"/>
</webApplication>

MicroProfile Telemetry 1.0 および 1.1 で受信 HTTP リクエストをトレース

また、Open Liberty 23.0.0.12 では、MicroProfile Telemetry 1.0 および 1.1 機能が強化され、受信 HTTP リクエスト（静的ファイル、Servlet および JSP）を自動的にトレースできるようになりました。

MicroProfile Telemetry の詳細については、次のリンクを参照してください：

MicroProfile OpenAPI： OpenAPI doc のエンドポイントパス設定

MicroProfile OpenAPI は、Liberty サーバにデプロイされる RESTful Web サービス (または JAX-RS) アプリケーション用の OpenAPI ドキュメントを生成して提供します。OpenAPI ドキュメントは /openapi エンドポイントから提供され、このドキュメントを参照するためのユーザーインターフェースは /openapi/ui エンドポイントから提供されます。

MicroProfile の OpenAPI 機能を Open Liberty で使用する場合は、次の例のように server.xml に設定を追加して、これらのエンドポイントのパスを設定できます：

<mpOpenAPI docPath="/my/openapi/doc/path" uiPath="/docsUi" />

この設定をローカルのテストサーバーに設定すると、OpenAPI ドキュメントには localhost:9080/my/openapi/doc/path から、UI には localhost:9080/docsUi からアクセスできるようになります。

この設定は、パスに基づいて異なるサービスにリクエストをルーティングする Kubernetes Ingress を通して OpenAPI ドキュメントを公開したい場合に特に便利です。例えば、以下の Ingress 設定では、

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- http:
    paths:
    - path: /appA
        pathType: Prefix
        backend:
        service:
            name: appA
            port:
            number: 9080

以下の server.xml 設定を使って、OpenAPI UI が /appA/openapi/ui で利用できるようにします：

<mpOpenAPI docPath="/appA/openapi" />

uiPath が設定されていない場合、デフォルトでは docPath に /ui を追加した値になります。

MicroProfile OpenAPI の詳細については、以下のリソースを参照してください：

計画停止を必要としないLTPAキーローテーションのサポート

Open Liberty は、このリリースから、LTPAトークンの検証を続けながら、自動的に新しいプライマリーのLTPA鍵ファイルを生成できるようになりました。今回のアップデートによって、ユーザーからの利用を中断することなく、LTPA鍵をローテーションできるようになりました。以前は、LTPA鍵が変更されると、ユーザーはアプリケーションに再度ログインしなくてはなりませんでしたが、その必要がなくなりました。

プライマリーのLTPA鍵ファイルは、ltpa.keys という名前でLTPAトークンの作成ならびに、LTPAトークンの検証に使われます。ランタイムで使われるプライマリーLTPA鍵ファイルは ltpa.keys 一つだけです。

検証用の鍵ファイルは、プライマリー鍵ファイル`ltpa.keys`以外で、.keys の拡張子を持つファイルです。検証用の鍵ファイルは、LTPAトークンの検証のみに使われ、トークンの生成には使われません。全ての検証用鍵ファイルは、プライマリー鍵ファイルと同じディレクトリーに配置する必要があります。

メンテナンス期間を取らずにLTPA鍵のローテーションを有効にするには、プライマリー鍵ディレクトリを監視する方法と、検証鍵ファイルを指定する2つの方法があり、またこ2つを同時に使うこともできます。

プライマリ鍵ファイルのディレクトリを監視し、新しい検証鍵があれば使う方法

下記のように monitorValidationKeysDir と monitorInterval の属性を有効にします。例えば、下記の構成を server.xml に追加します。

<ltpa monitorValidationKeysDir="true" monitorInterval="5s"/>

上記の monitorValidationKeysDir 属性は、プライマリー鍵ファイルのディレクトリで.keys拡張ファイルがないか監視します。デフォルトでは、このディレクトリは ${server.config.dir}/resources/security/ ですが、構成することもできます。Liberty サーバーはこれらの LTPA 鍵ファイルを検証キーとして使用します

モニタリングは updateTrigger が polled に設定され、 monitorInterval が0より大きい場合にのみ有効になります。 updateTrigger のデフォルト値は polled monitorInterval のデフォルト値は0です。

下記は、属性を省略せずに構成したものです。

<ltpa keysFileName="${server.config.dir}/resources/security/ltpa.keys" keysPassword="{xor}Lz4sLCgwLTs=" monitorValidationKeysDir="true" monitorInterval="5" expiration="45m" updateTrigger="polled">
</ltpa>
`ltpa.keys` のファイル名を変更すると、Libertyは自動的に新しいプライマリー鍵ファイルを生成します。たとえば、`validation1.keys` に名前を変更すると、Libertyは新しい `ltpa.keys` を作成して、これを使って新しいLTPAトークンを作ります。 `validation1.keys` 検証鍵ファイルにある鍵は引き続き、LTPAトークンの検証に使われます。.

+

`validation1.keys` が必要なくなったらファイルを削除するか、`monitorValidationKeysDir` を false　に設定してディレクトリーのモニターを中止します。未使用の検証鍵ファイルを削除するとパフォーマンス向上につながります。
検証キーファイルを指定し、オプションで検証キーの使用を停止する日付を指定するには

  1. 主キーファイル（ltpa.keys）を検証キーファイル（validation1.keys など）にコピーする。

  2. 'ltpa` 要素の下に validationKeys 要素を指定し、検証キーファイルを使用するようにサーバー設定を変更する。例えば、server.xml ファイルに以下の設定を追加する：

    <ltpa>
    <validationKeys fileName="validation1.keys" password="{xor}Lz4sLCgwLTs=" validUntilDate="2024-01-02T12:30:00Z"/>
</ltpa>

    オプションの validUntilDate 属性を指定することで、validation1.keys ファイルの使用を将来の指定した日付に停止することができます。validUntilDate`を使用すると、一定期間後にバリデーションキーを無視することができ、パフォーマンスが向上するので推奨されます。

    validationKeys 要素では fileName 属性と password 属性は必須であるが、 validUntilDate 属性はオプションです。

    サーバ設定の更新でバリデーションキーファイルを読み込んだ後、元のプライマリキーファイル (ltpa.keys) を削除すると、バリデーションに validation1.keys を使い続けながら、新しいプライマリキーを作成することができます。

    このようにしてバリデーションキーを指定すると、次の例のように、server.xml 構成で指定されていないバリデーションキーも同時に使用するように、モニターディレク トリを有効にすることができる：

    <ltpa monitorValidationKeysDir="true" monitorInterval="5s">
    <validationKeys fileName="validation1.keys" password="{xor}Lz4sLCgwLTs=" validUntilDate="2024-01-02T12:30:00Z"/>
</ltpa>

詳細については、 Rotate LTPA keys without requiring users to reauthenticate を参照してください。

LTPA要素にupdateTrigger属性を追加

updateTrigger 属性が polled または mbean に設定されている場合、LTPAのキーファイルはサーバによってリロードされます。デフォルトは polled です。 polled に設定されている場合、サーバは monitorInterval 属性で設定された割合でキーファイルの変更を監視します。以下の例のように updateTrigger 属性が mbean に設定されている場合、サーバは WebSphere:service=com.ibm.ws.kernel.filemonitor.FileNotificationMBean MBean から通知を受け取ると再読み込みします：

<ltpa monitorValidationKeysDir="true" updateTrigger="mbean"/>

updateTrigger 属性が disabled に設定されていると、キーファイルは再読み込みされません。

サーバー構成要素の ltpa についての詳細は、 LTPA configuration docs を参照してください。

認可コードフローを使用する認可リクエストとともに、リソースパラメータを送信

認可リクエストは、暗黙フローまたは認可コードフローのいずれかを使用して行うことができます。リクエストが暗黙フローを使用する場合、すべてのトークンは認可エンドポイントから返され、トークン・エンドポイントは使用されません。リクエストが認可コードフローを使用する場合、すべてのトークンはトークン エンドポイントから返されます。

以前は、Libertyは暗黙フローリクエスト中にのみリソースパラメータを送信していました。そのため、リクエストにリソース・パラメータが必要なのに認可コード・フローしか使えない場合、リクエストは失敗していました。今回の更新により、認可コードフローと一緒にリソースパラメータを送信できるようになりました。

この更新を実装するために、暗黙フロー中にのみリソースパラメータを送信するチェックが削除されました。これにより、両方のフローでパラメータが送信されるようになりました。

さらなる詳細については、 GitHub上のIssue を参照してください。

OpenID Connectのアクセストークンからロール情報を取得

認証と認可のために、トークンは、リクエストを行ったプリンシパルの ID と、そのプリンシパルがどのようなアクセスを許可されているかについての情報を含むデジタル・オブジェクトです。一般的に、これらのトークンは、アクセストークンとIDトークンの2つのタイプのいずれかに分類されます。

IDトークンは、OpenID Connect仕様に準拠したJSON Webトークンです。以前は、ユーザーのロール情報はこのIDトークンからのみ取得できました。IDトークン内にロール情報が提供されていない場合、その情報は取得できませんでした。今回の更新では、IDトークン内にロール情報が見つからない場合に、アクセストークンからロール情報を取得しようとするチェックが提供されます。

IDトークン内にロール情報が見つからなかった場合に、アクセストークンからロール情報の取得を試みるチェックが追加されました。次の sever.xml ファイルの例のように、tokensOrderToFetchCallerClaims 属性を AccessToken IDToken Userinfo に設定することで、このチェックを有効にすることができます：

<openidConnectClient tokensOrderToFetchCallerClaims="AccessToken IDToken Userinfo"  userIdentifier="unique_name" groupIdentifier="aud" ... />

さらなる詳細については、 Check the access token for user and group information を参照してください。

セキュリティ脆弱性 (CVE) の修正

CVE CVSS Score Vulnerability Assessment Versions Affected Notes

CVE-2023-44487

7.5

Denial of service

18.0.0.2 - 23.0.0.11

Affects the servlet-3.0, servlet-4.0, servlet-5.0 and servlet-6.0 features

過去のセキュリティ脆弱性の修正については、 Security vulnerability (CVE) list を参照してください。

Liberty Maven plug-in 3.10およびLiberty Gradle plug-in 3.8を公開

Liberty MavenとGradleプラグインの新しいリリースが利用可能になりました。以下の注目すべき新機能が含まれています：

  • Libertyの`springBoot-3.0` Featureを使うことで、ビルドプラグインを使用してSpring Boot 3アプリケーションのLibertyへのデプロイがサポートされました

  • Java 21でのプラグイン実行のサポート

新しいMavenプラグインバージョンを使うには、Mavenの pom.xml ファイルに3.10リリースを指定します。 Gradle の場合は、build.gradle ファイルに 3.8 リリースを指定してください。

これらのプラグインの詳細については、以下のリソースを参照してください：

Liberty MavenプラグインによるSpring Bootサポートの詳細については、 ci.maven: Spring Boot Support を、 Liberty GradleプラグインでのSpring Bootサポートの詳細については、 ci.gradle: Spring Boot Support を参照してください。

Eclipse IDE, IntelliJ IDEA, およびVisual Studio CodeむけにLiberty Tools 23.0.12を公開

Liberty Toolsは、Eclipse IDE、IntelliJ IDEA、Visual Studio Codeの新しいリリースをサポートするようになりました。このリリースには、さまざまな機能強化や修正も含まれています。

使用しているIDEからLiberty Toolsの最新リリースに更新するか、IDEのマーケットプレイスから最新バージョンをダウンロードしてください。

さらなる詳細については、以下のリリース・ノートを参照してください：

今すぐOpen Liberty 23.0.0.12 を入手する

Maven を使用している場合は、 pom.xml ファイルに以下の記述を追加してください。

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

また、 Gradle を使用している場合は，build.gradle ファイルに以下の記述を追加してください。

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

コンテナ・イメージ の場合はこちらです。

FROM icr.io/appcafe/open-liberty

または、 ダウンロードページ をご参照ください。

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