1.3. 新機能、機能拡張、および技術的な変更

Red Hat build of Quarkus 3.20 では、次のエクステンションによって Fabric8 Kubernetes Client がバージョン 6.13 から 7.1 にアップグレードされます。

このアップグレードにより、パフォーマンス、互換性、テストにいくつかの改善がもたらされます。

Fabric8 Kubernetes Client 7.1 の主な利点は次のとおりです。

この変更により、重大な変更が導入されます。詳細は、「以前のバージョンとの互換性に影響を与える変更」セクションの こちらのリリースノート を参照してください。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

Red Hat build of Quarkus 3.20 以降、Red Hat ビルダーおよびランタイムベースイメージは、デフォルトで Red Hat Universal Base Image 9 (UBI 9) を使用します。

以下のイメージがアップグレードされます。

このアップグレードでは重大な変更が導入されます。ビルダーおよびランタイムベースイメージが UBI 9 にアップグレードされます。

UBI 9 イメージに手動でアップグレードする場合のオプションの概要を次の表に示します。

UBI 9 ベースのランタイムイメージで問題が発生した場合は、手動で UBI 8 ベースのイメージに切り替えることができます。詳細は、ビルダーおよびランタイムベースイメージが UBI 9 にアップグレードされる を参照してください。

詳細は、以下の資料を参照してください。

Red Hat build of Quarkus 3.20 では、エクステンションは開発モード (dev モード) でのみ、または特定の条件が満たされた場合にのみアクティブ化される条件付き依存関係を宣言できるようになり、通常モードとテストモードでの不要な依存関係を回避できます。

詳細は、Quarkus ガイド「条件付きエクステンションの依存関係」の 開発モードのみのエクステンションの依存関係 セクションを参照してください。

Red Hat build of Quarkus 3.20 では、Mandrel バージョン 24.2 以降に合わせてロケール処理が更新されています。

アプリケーションは、ビルドシステムのロケールに関係なく、実行時に一貫したデフォルトのロケールを使用するようになりました。この変更により、環境間でのロケールに依存する動作の移植性と予測可能性が向上します。

この変更により、重大な変更が導入されます。詳細は、「以前のバージョンとの互換性に影響を与える変更」セクションの こちらのリリースノート を参照してください。

この変更には手動による介入が必要です。これは、Red Hat build of Quarkus 3.20 へのアプリケーションの移行 ガイドで説明されている自動更新プロセスには含まれていません。

Red Hat build of Quarkus 3.20 以降、quarkus-agroal エクステンションにより、Dev UI へのデータベース接続を監視するための専用の Agroal - Database connection pool カードとページが追加されます。

Quarkus アプリケーションに quarkus-agroal エクステンションを使用する JDBC ドライバーエクステンションが含まれている場合、そのエクステンションはアプリケーションに自動的に含まれます。

Dev UI では、Agroal - Database connection pool カードをお気に入り (星印) にすることができます。また、Database view のリンクをカードから Dev UI メニューにドラッグすることもできます。Database view をクリックすると、Agroal - Database connection pool ページが開き、接続 URL を含むすべてのアクティブなデータソースを表示できます。

この機能拡張により、Dev UI 内でのデータベースの監視と設定が合理化され、デバッグとデータベース管理が改善されます。

Red Hat build of Quarkus 3.20 では、quarkus-datasource エクステンションが、ArC に最適化された依存性注入フレームワークを使用して、アプリケーションの起動時にデータソース設定を検証するようになりました。この機能拡張により、設定ミスが早期に検出されるようになり、ランタイムエラーを防ぎ、障害のあるインスタンスにトラフィックがルーティングされるリスクを低減します。

Red Hat build of Quarkus における主な変更点:

詳細は、「データソースの設定」ガイドの データソースのアクティブ化または非アクティブ化 セクションを参照してください。

Red Hat build of Quarkus 3.20 では、SmallRye Reactive Messaging Kafka コネクターを通じて Apache Kafka トランザクションのサポートを追加する quarkus-messaging-kafka エクステンションが導入されました。この機能により、複数の Kafka トピックとパーティションへのアトミックな書き込みが可能になり、トランザクション内のすべてのレコードをコミットするか、一切コミットしないかを確実にすることで、イベント駆動型アプリケーションのデータの整合性を高めます。

この機能は テクノロジープレビュー として利用できます。

詳細は、Quarkus ガイド「Apache Kafka リファレンス」の Kafka トランザクション セクションを参照してください。

Red Hat build of Quarkus 3.20 以降、エクステンション開発者は Dev UI フッターにカスタムログタブを作成し、そこにログデータをストリームできます。このプロセスは、Dev UI でカードまたはページを作成するプロセスに似ています。

ログタブは、アプリケーション開発者がツールを切り替えることなく、アプリケーションを監視およびトラブルシューティングできるように継続的なデータを提供します。ページは他のページに移動するとバックエンドから切断されますが、ログタブは永続的に接続されたままになります。

詳細は、Quarkus ガイド「エクステンション開発者向けの Dev UI」の フッタータブの追加 セクションを参照してください。

Red Hat build of Quarkus 3.20 は、LGTM Dev Services を使用する際に、事前設定された複数の Grafana ダッシュボードを提供します。これらのダッシュボードは、アプリケーションのメトリクス、トレース、およびログを視覚化します。また、シームレスなデータ収集とプレゼンテーションのために OpenTelemetry を活用しています。一部のダッシュボードでは、OpenTelemetry 出力など、複数の方法で Micrometer データが表示されます。各ダッシュボードは、特定のアプリケーションセットアップに合わせて調整されています。

利用可能なダッシュボードは次のとおりです。

一部のダッシュボードパネルでは、スライディングタイムウィンドウでの計算を行うため、正確なデータが表示されるまでに数分かかる場合があります。

この更新以降、quarkus.otel.traces.suppress-application-uris 設定プロパティーを使用して、OpenTelemetry トレーシングから特定の URI を除外できるようになりました。これにより、トレーサーが無視する URI パターンのコンマ区切りリストを定義できます。

たとえば、quarkus.otel.traces.suppress-application-uris=trace,ping,people* を設定すると、/trace および /ping URI のトレースだけでなく、/people/1 や /people/1/cars などの /people で始まるすべての URI のトレーシングもオフになります。

カスタムの quarkus.http.root-path を使用する場合は、必ずそれを設定に含めてください。

Red Hat build of Quarkus 3.20 では、quarkus-opentelemetry エクステンションによって、終了するとすぐにスパンとログをエクスポートする SimpleSpanProcessor のサポートが追加されました。この動作は、サーバーレス環境や短命のアプリケーションで特に役立ちます。

この機能を有効にするには、次の設定プロパティーを true に設定します。

quarkus.otel.simple=true

この設定は、デフォルトの BatchSpanProcessor を置き換え、スパンとログがバッファリングされるのではなく、すぐに送信されるようにします。この変更は、アプリケーションがシャットダウンする前にテレメトリーデータが確実にエクスポートされるようにするため、Lambda 関数やその他の短期的なプロセスにとって極めて重要です。これにより、バッチ処理の遅延によるデータ損失を防ぐことができます。

Red Hat build of Quarkus 3.20 では、quarkus-opentelemetry エクステンションが OpenTelemetry (OTel) ロギングをサポートするようになりました。この機能を使用すると、対話型 Web アプリケーションに分散ロギングを提供できます。

この機能を有効にするには、次の設定プロパティーを true に設定します。

quarkus.otel.logs.enabled=true

詳細は、Quarkus ガイド OpenTelemetry Logging の使用 を参照してください。

Red Hat build of Quarkus 3.20 では、OpenTelemetry メトリクスが有効になっている場合、quarkus-opentelemetry エクステンションによって、MicroProfile Telemetry 2.0 仕様に準拠した JVM および HTTP サーバー要求メトリクスの自動計装が提供されます。

OpenTelemetry メトリクスはデフォルトで無効になっています。JVM および HTTP サーバー要求メトリクスを収集するには、quarkus.otel.metrics.enabled=true を設定して有効にする必要があります。

対応する設定プロパティーはデフォルトで有効になっていますが、設定で quarkus.otel.instrument.jvm-metrics=false または quarkus.otel.instrument.http-server-metrics=false を設定することで無効化できます。

OpenTelemetry メトリクスと統合したフォールトトレランス機能は、現時点ではサポートされていません。

Red Hat build of Quarkus 3.20 では、単一のリクエスト内で複数の認証メカニズムを使用するためのサポートが追加されました。相互 TLS (mTLS) や OpenID Connect (OIDC) ベアラートークン認証などのメカニズムを同じ認証フローで組み合わせることができるようになりました。

デフォルトでは、登録された認証メカニズムの 1 つによって最初の SecurityIdentity が生成されると、認証が完了します。すべてのメカニズムに認証情報の検証を要求するには、設定プロパティーを設定して包括的認証を有効にします。

この機能は、クライアント証明書へのアクセストークンのバインドが必要なシナリオなど、相互 TLS とベアラートークン認証を組み合わせる場合に役立ちます。

詳細と例は、「セキュリティーアーキテクチャー」ガイドの 認証メカニズムの組み合わせ セクションを参照してください。

Red Hat build of Quarkus 3.20 では、メタアノテーション内で @PermissionsAllowed を使用するためのサポートが追加され、より合理化されたアクセス制御管理のためのカスタムセキュリティーアノテーションを作成できるようになりました。

この機能拡張により、パーミッションベースの設定が簡素化され、セキュリティーコードの繰り返しが減少し、保守性が向上します。@PermissionsAllowed をカプセル化する再利用可能なセキュリティーアノテーションを定義できるようになりました。これにより、パーミッションの処理がより効率的かつ一貫したものになります。

詳細と例は、「Web エンドポイントの認可」ガイドの パーミッションメタアノテーションの作成 セクションを参照してください。

Red Hat build of Quarkus 3.20 以降、@PermissionChecker アノテーションを使用して、CDI Bean メソッドで宣言型パーミッションチェッカーを定義できます。この機能拡張により、パーミッションチェックをリソースクラスとは別に実装できるようになり、コードの重複が削減され、保守性が向上するため、柔軟で再利用可能な認可ロジックが実現します。

これらのパーミッションチェッカーは、文字列の等価性に基づいてパーミッション名を照合することにより、@PermissionsAllowed と連携して動作します。認証されたユーザーを表す SecurityIdentity と、受信した HTTP 要求パラメーターを評価することにより、汎用的な認可チェックをサポートします。このアプローチにより、きめ細かなアクセス制御が可能になります。チェッカーは、通常スコープまたはシングルトン CDI Bean で定義され、boolean または Uni<Boolean> のいずれかを返す必要があり、同期認可チェックとリアクティブ認可チェックの両方をサポートします。

この機能は、認可ロジックを一元化することでパーミッション管理を簡素化し、複数のエンドポイントにわたってセキュリティーポリシーをより簡単に適用できるようにします。開発者は、複数のアクションを動的に検証する汎用的なパーミッションチェッカーを作成できます。

詳細は、「Web エンドポイントの認可」ガイドの パーミッションチェッカーの作成 セクションを参照してください。

Red Hat build of Quarkus 3.20 以降では、quarkus-oidc を使用して、ファイルシステムから JWT ベアラートークンをロードすることで、OIDC プロバイダークライアントを認証するように OIDC を設定できます。

このアプローチにより、セキュアで自動化された認証が可能になります。これは、サービスアカウントトークンをファイルとしてマウントできる OpenShift などのコンテナー化された環境で特に役立ちます。Red Hat build of Quarkus はファイルからトークンを自動的に読み込み、トークンの有効期限が切れると再読み込みします。

設定の詳細と使用例は、次のリソースを参照してください。

Red Hat build of Quarkus 3.20 では、次の Quarkus エクステンションによって OpenID Connect (OIDC) 応答フィルターが導入されています。

ロギングやその他のアクションのために、応答ステータス、ヘッダー、本文を検査するには、OidcResponseFilter を実装します。

デフォルトでは、OIDC 応答フィルターはグローバルに適用されます。トークンエンドポイントなどの特定のエンドポイントをターゲットにするには、@OidcEndpoint アノテーションを使用します。

詳細は、「OpenID Connect (OIDC) 認証」ガイドの OIDC 応答フィルター セクションを参照してください。

相互 TLS (mTLS) トークンバインディングは、アクセストークンがクライアントの mTLS 認証証明書に暗号的にバインドされるようにして、セキュリティーを強化します。

この機能は RFC 8705 に基づいており、認証に使用される証明書の拇印がトークンに含まれる証明書の拇印と一致することを確認することで、盗まれたベアラーアクセストークンを受け入れるリスクを最小限に抑えます。

Red Hat build of Quarkus 3.20 以降、Quarkus OIDC エクステンション quarkus-oidc は、OpenID Connect (OIDC) と mTLS の両方で保護されたエンドポイントの証明書にバインドされたアクセストークンをサポートするようになりました。

この機能を有効にするには、次の設定プロパティーを設定します。

quarkus.oidc.token.binding.certificate=true

詳細は、「OpenID Connect (OIDC) 認証」ガイドの 相互 TLS トークンバインディング セクションを参照してください。

Red Hat build of Quarkus 3.20 では、OidcProviderClient の注入のサポートが導入され、アプリケーションが OpenID Connect (OIDC) プロバイダーの UserInfo、トークンイントロスペクション、および失効エンドポイントと対話できるようになりました。

これにより、開発者は必要に応じてプログラムで UserInfo、トークンイントロスペクション、および失効エンドポイントにアクセスできるようになります。たとえば、ユーザーがログアウトした後にアクセストークンを取り消すことができます。

詳細は、OpenID Connect (OIDC) 認証ガイドの トークンの失効 セクションを参照してください。

Red Hat build of Quarkus 3.20 以降、quarkus-oidc を使用すると、application.properties ファイルで設定する代わりに、OidcTenantConfig ビルダーを使用して OpenID Connect (OIDC) テナントをプログラムで定義できます。

このアプローチは、設定で OIDC テナントを定義するよりも柔軟性が高くなります。

このアプローチは、発行者ベースやパスベースのテナントリゾルバーなど、静的テナントを必要とする機能に特に役立ちます。

詳細は、「OpenID Connect (OIDC) 認証」ガイドの次のリソースを参照してください。

Red Hat build of Quarkus 3.20 では、quarkus-oidc エクステンションが存在しない場合でも、Dev Services for Keycloak を起動できるようになりました。この変更により、完全な OIDC エクステンションを必要とせずに、quarkus-oidc-client エクステンションを単独でテストできるようになります。

さらに、Dev Services for Keycloak が有効になっている場合、Red Hat build of Quarkus では次のような主要な OIDC クライアントプロパティーが自動的に設定されるようになりました。

以前は、これらのプロパティーを手動で設定する必要がありました。

これらの機能拡張は下位互換性があります。既存のワークフローと手動設定は、引き続き期待どおりに機能します。

Red Hat build of Quarkus 3.20 では、証明書チェーン全体での TLS ハンドシェイク中に期限切れまたはまだ有効でない証明書を処理するためのポリシーの設定がサポートされるようになりました。

以前は、トラストストアは RFC 3280 および関連仕様に準拠し、警告なしでこのような証明書を許可していました。

この更新により、ユーザーは次のいずれかのオプションを選択して動作を制御できるようになります。

Red Hat build of Quarkus 3.20 では、quarkus-oidc エクステンションがアクセストークンの Demonstrating Proof of Possession (DPoP) をサポートするようになりました。

この機能は テクノロジープレビュー として利用できます。

詳細は、以下の資料を参照してください。

Red Hat build of Quarkus 3.20 では、quarkus-tls-registry エクステンションにより、PEM キーストア内の暗号化された PKCS#8 秘密鍵のサポートが導入されています。

この機能は テクノロジープレビュー として利用できます。

これにより、開発者は AES-128-CBC 暗号化を使用して秘密鍵を保護し、アプリケーションのセキュリティーを向上させることができます。

この機能を使用するには、quarkus.tls.key-store.pem.password プロパティーにキーストアのパスワードを設定します。

詳細は、TLS レジストリーを使用したセキュリティーキーと証明書の管理 ガイドを参照してください。

Red Hat build of Quarkus 3.20 では、エクステンションの作成者は開発モードで実行されているアプリケーションの JVM オプションを定義できます。--enable-preview や --add-opens などのオプションをエクステンションメタデータで直接指定できるため、アプリケーション開発者がこれらを設定する必要がなくなります。

エクステンションは、開発モードで実行するときにこれらの JVM オプションを自動的に適用し、すべてのアプリケーション開発者の環境を一貫したものにします。

アプリケーション開発者は、Quarkus Maven プラグインを使用して、エクステンションが提供するすべての JVM オプションをオフにしたり、特定のエクステンションのオプションを選択的にオフにしたりできます。詳細は、Quarkus ガイド「Quarkus と Maven」の エクステンションが提供する開発モード Java オプション セクションを参照してください。

Red Hat build of Quarkus 3.20 以降、Dev UI フッターに HTTP タブが含まれるようになりました。これを使用して、ツールやコンテキストを切り替えることなく、受信 HTTP アクセスログメッセージを監視できます。

たとえば、Dev UI の SmallRye OpenAPI - Swagger UI ページを使用してアプリケーションの HTTP エンドポイントと対話する場合、Dev UI フッターの HTTP タブに、対応するログメッセージが表示されます。

詳細は、Quarkus ガイド「HTTP リファレンス」の HTTP アクセスログの設定 セクションを参照してください。

Red Hat build of Quarkus 3.20 では、REST エンドポイントパラメーターコンテナーとして Java レコードのサポートが導入され、簡潔で不変のデータ構造が可能になります。レコードはクエリー、Cookie、ヘッダー、フォーム、またはマルチパートパラメーターをカプセル化できるため、RESTful サービスでのデータ処理が簡素化されます。

Java レコードはすでに、REST 本文の JSON シリアル化とデシリアル化に使用できます。ただし、Jakarta REST 仕様の制限により、@BeanParam はまだこれらをサポートしていません。

Red Hat build of Quarkus 3.20 では、quarkus-rest および quarkus-resteasy エクステンションにより、新しい @AuthorizationPolicy アノテーションのサポートが追加されました。このアノテーションを使用すると、名前付きの HttpSecurityPolicy を Jakarta REST エンドポイントに直接バインドできます。この機能は、パス一致ルールの代替手段を提供し、SecurityIdentity ロールを変更せずに、より柔軟な認可チェックを可能にします。

詳細は、「Web エンドポイントの認可」ガイドの カスタム HttpSecurityPolicy セクションを参照してください。

Red Hat build of Quarkus 3.20 では、quarkus-rest-client エクステンションによって @Url アノテーションのサポートが追加されました。REST クライアントメソッドのパラメーターにアノテーションを付けて、ランタイムに URL を動的に提供できるようになりました。

通常、REST クライアントには、グローバルに設定されたベース URL が必要です。ただし、呼び出しごとに URL を設定する必要がある場合もあります。@Url アノテーションは、個々の呼び出しに対して動的な URL 解決を有効にすることで、このユースケースをサポートします。

詳細は、Quarkus ガイド「REST Client の使用」の 動的ベース URL セクションを参照してください。

Red Hat build of Quarkus 3.20 では、quarkus-rest-client エクステンションが MicroProfile REST Client 4.0 に更新されました。この更新では、REST クライアントを作成および管理するための標準化された宣言型 API を提供することで、アプリケーションが RESTful サービスと対話する方法が強化されます。柔軟性、パフォーマンス、セキュリティーが向上し、外部 REST サービスの統合が簡素化されます。

Red Hat build of Quarkus 3.20 では、quarkus-rest-jackson エクステンションにより、リフレクションフリーのデシリアライゼーションが導入され、JSON 処理機能が強化されます。

この機能拡張は、以前のリリースで実装されたリフレクションフリーのシリアル化を補完します。

デフォルトでは、リフレクションフリーの JSON 処理は無効になっています。有効にするには、次の設定プロパティーを true に設定します。

quarkus.rest.jackson.optimization.enable-reflection-free-serializers=true

デシリアライズ中にリフレクションへの依存を排除することで、アプリケーションはパフォーマンスを向上させ、メモリー消費を削減できます。特に、リフレクションによってオーバーヘッドが生じる可能性があるネイティブアプリケーションではその効果が顕著です。この機能を有効にする場合は、テストを実行してアプリケーションへの影響を評価します。

詳細は、Quarkus ガイド「Quarkus REST を使用した REST サービスの作成」の JSON シリアル化 セクションを参照してください。

Red Hat build of Quarkus 3.20 では、WebSocket サーバーおよびクライアントエンドポイントを定義するための最新の宣言型 API を提供する quarkus-websockets-next エクステンションのサポートが導入されています。

このエクステンションにより、効率的でスケーラブルなリアルタイム通信が可能になり、Red Hat build of Quarkus のリアクティブアーキテクチャーおよびネットワークレイヤーと統合されます。

非推奨の quarkus-websockets エクステンションとは異なり、WebSockets Next は Jakarta WebSocket 仕様を実装していません。

WebSockets Next によって導入された主な機能:

詳細は、「WebSockets Next リファレンス」ガイドの セキュリティー セクションを参照してください。

詳細は、シリアル化とデシリアル化 セクションを参照してください。

設定の詳細は、「WebSockets Next リファレンス」ガイドの テレメトリー セクションを参照してください。

詳細は、以下の資料を参照してください。