ネイティブ実行可能ファイルへの Red Hat build of Quarkus アプリケーションのコンパイル
概要
Red Hat build of Quarkus ドキュメントへのフィードバックの提供
エラーを報告したり、ドキュメントを改善したりするには、Red Hat Jira アカウントにログインし、課題を送信してください。Red Hat Jira アカウントをお持ちでない場合は、アカウントを作成するように求められます。
手順
- 次のリンクをクリックして チケットを作成します。
- Summary に課題の簡単な説明を入力します。
- Description に課題や機能拡張の詳細な説明を入力します。問題があるドキュメントのセクションへの URL も記載してください。
- Submit をクリックすると、課題が作成され、適切なドキュメントチームに転送されます。
第1章 ネイティブ実行可能ファイルへの Red Hat build of Quarkus アプリケーションのコンパイル
アプリケーション開発者は、Red Hat build of Quarkus 3.20 を使用して、OpenShift Container Platform 環境およびサーバーレス環境で実行される、Java で記述されたマイクロサービスを作成できます。Quarkus アプリケーションは、通常の Java アプリケーションとして (Java 仮想マシン (JVM) 上で) 実行することも、ネイティブ実行可能ファイルにコンパイルすることもできます。ネイティブ実行可能ファイルにコンパイルされたアプリケーションは、対応する Java アプリケーションよりもメモリーフットプリントが小さく、短時間で起動します。
このガイドでは、Red Hat build of Quarkus 3.20 の Getting Started プロジェクトをネイティブ実行可能ファイルにコンパイルする方法と、ネイティブ実行可能ファイルを設定してテストする方法を説明します。Red Hat build of Quarkus スタートガイド で作成したアプリケーションが必要になります。
Red Hat build of Quarkus を使用したネイティブ実行可能ファイルのビルドでは、以下を説明します。
- Podman または Docker などのコンテナーランタイムを使用して、シングルコマンドでネイティブ実行可能ファイルをビルドする
- 生成されたネイティブ実行可能ファイルを使用して、カスタムコンテナーイメージを作成する
- OpenShift Container Platform Docker ビルドストラテジーを使用して、コンテナーイメージを作成する
- Quarkus ネイティブアプリケーションを OpenShift Container Platform にデプロイする
- ネイティブ実行可能ファイルを設定する
- ネイティブ実行可能ファイルをテストする
前提条件
JAVA_HOME
環境変数を設定して Java SDK の場所を指定している。- Red Hat build of OpenJDK は、Red Hat カスタマーポータルにログインして ソフトウェアダウンロード ページからダウンロードできます。
- Open Container Initiative (OCI) と互換性のあるコンテナーランタイム (Podman、Docker など)。
Quarkus Getting Started プロジェクトを完了している。
- Quarkus Getting Started プロジェクトのビルド方法は、Red Hat build of Quarkus のスタートガイド を参照してください。
-
または、Quarkus Quickstarts アーカイブをダウンロードするか、Quarkus Quickstarts Git リポジトリーのクローンを作成することもできます。プロジェクトのサンプルは
getting-started
ディレクトリーにあります。
1.1. ネイティブ実行可能ファイルの作成
ネイティブバイナリーは、特定のオペレーティングシステムおよび CPU アーキテクチャー上で実行するために作成された実行可能ファイルです。
以下は、ネイティブ実行可能ファイルの例をいくつか示しています。
- Linux AMD 64 ビット用の ELF バイナリー
- Windows AMD 64 ビット用の EXE バイナリー
- ARM 64 ビット用の ELF バイナリー
Red Hat build of Quarkus では、Linux x86-64 または AArch64 ビット用の ELF バイナリーのみがサポートされています。
ネイティブ実行可能ファイルを構築する利点の 1 つは、Java 仮想マシン (JVM) を含むアプリケーションと依存関係が 1 つのファイルにパッケージ化されることです。アプリケーションのネイティブ実行可能ファイルには、次の項目が含まれています。
- コンパイルされたアプリケーションコード
- 必要な Java ライブラリー
- アプリケーションの起動時間を短縮し、ディスクとメモリーのフットプリントを最小限に抑えるための仮想マシン (VM) の縮小バージョン。これは、アプリケーションコードとその依存関係に合わせて調整されています。
Quarkus アプリケーションからネイティブ実行可能ファイルを生成する場合は、コンテナ内ビルドまたはローカルホストビルドのいずれかを選択できます。次の表は、使用可能なビルドオプションとその説明を示しています。
ビルドオプション | 必須 | 用途 | 結果 | 利点 |
---|---|---|---|---|
コンテナ内ビルド - サポート対象 | コンテナーランタイム (Podman や Docker など) |
デフォルトの | ホストの CPU アーキテクチャーを使用する Linux 64 ビット実行可能ファイル | GraalVM はローカルで設定する必要がないため、CI パイプライン の実行効率が向上します。 |
ローカルホストビルド - アップストリームでのみサポート対象 | GraalVM または Mandrel のローカルインストール |
| ビルドが実行されるマシンと同じオペレーティングシステムおよび CPU アーキテクチャーを持つ実行可能ファイル | Docker や Podman などのツールを使用できない、または使用しない開発者向けの代替手段。総じて、コンテナ内ビルドアプローチよりも高速です。 |
-
Red Hat build of Quarkus 3.20 は、Java 21 ベースの Red Hat build of Quarkus Native Builder イメージ (
quarkus/mandrel-for-jdk-21-rhel8
) を使用したネイティブ Linux 実行可能ファイルのビルドのみをサポートしています。このイメージは、GraalVM Mandrel の製品化されたディストリビューションです。Quarkus コミュニティーでは他のイメージも利用できますが、それらは製品ではサポートされていないため、Red Hat によるサポートが必要な実稼働ビルドには使用しないでください。 - ソースが 17 に基づいて記述され、Java 18 - 21 の機能が使用されていないアプリケーションでも、Java 21 ベースの Mandrel 23.1 ベースイメージを使用して、そのアプリケーションのネイティブ実行可能ファイルをコンパイルできます。
- Red Hat build of Quarkus は、Oracle GraalVM Community Edition (CE)、Mandrel コミュニティーエディション、またはその他の GraalVM ディストリビューションを使用したネイティブ実行可能ファイルのビルドをサポートしていません。詳細は、ネイティブ実行可能ファイルへの Red Hat build of Quarkus アプリケーションのコンパイル を参照してください。
1.1.1. コンテナ内ビルドを使用してネイティブ実行可能ファイルを生成する
ネイティブ実行可能ファイルを作成し、ネイティブイメージテストを実行するには、コンテナ内ビルド用に Red Hat build of Quarkus が提供する native
プロファイルを使用します。
前提条件
- Podman または Docker がインストールされている。
- コンテナーは、8 GB 以上のメモリーにアクセスできる。
- オプション: Quarkus CLI がインストールされている。これは、ネイティブ実行可能ファイルをビルドする方法の 1 つとして使用できます。詳細は、Quarkus CLI のインストール を参照してください。
Quarkus CLI は、Quarkus プロジェクトの作成、更新、ビルドなどのタスクを含む開発目的で使用されます。Red Hat は、実稼働環境での Quarkus CLI の使用をサポートしていません。
手順
Getting Started プロジェクトの
pom.xml
ファイルを開き、プロジェクトにnative
プロファイルが含まれていることを確認します。<profiles> <profile> <id>native</id> <activation> <property> <name>native</name> </property> </activation> <properties> <skipITs>false</skipITs> <quarkus.native.enabled>true</quarkus.native.enabled> </properties> </profile> </profiles>
次のいずれかの方法を使用して、ネイティブ実行可能ファイルをビルドします。
Maven を使用:
Docker の場合:
./mvnw package -Dnative -Dquarkus.native.container-build=true
Podman の場合:
./mvnw package -Dnative -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=podman
Quarkus CLI を使用:
Docker の場合:
quarkus build --native -Dquarkus.native.container-build=true
Podman の場合:
quarkus build --native -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=podman
手順を実行した結果
これらのコマンドを実行すると、
target
ディレクトリーに*-runner
バイナリーが作成されます。その場合は、以下が適用されます。-
*-runner
ファイルは、Quarkus が生成するビルドされたネイティブバイナリーです。 target
ディレクトリーは、Maven アプリケーションをビルドするときに Maven が作成するディレクトリーです。重要Quarkus アプリケーションをネイティブ実行可能ファイルにコンパイルすると、分析および最適化の際にメモリーを大量に消費します。
quarkus.native.native-image-xmx
設定プロパティーを設定して、ネイティブコンパイル時に使用されるメモリーの量を制限できます。メモリー制限を低く設定すると、ビルド時間が長くなる可能性があります。
ネイティブ実行可能ファイルを実行するには、以下のコマンドを入力します。
./target/*-runner
1.1.2. ローカルホストビルドを使用してネイティブ実行可能ファイルを生成する
Docker または Podman を使用しない場合は、ネイティブ実行可能ファイルの作成と実行に Quarkus ローカルホストビルドオプションを使用します。
ローカルホストビルドアプローチを使用すると、コンテナーを使用した場合と比べて高速になるため、Linux オペレーティングシステムを使用するマシンに適しています。
Red Hat build of Quarkus では、本番環境での次の手順の使用はサポートされていません。この方法は、テストで、もしくは Docker や Podman が使用できない場合のバックアップアプローチとしてのみ使用してください。
前提条件
Quarkus の Building a native executable ガイドに従って正しく設定された、Mandrel または GraalVm のローカルインストール。
-
GraalVM インストールの場合は、
native-image
もインストールされている必要があります。
-
GraalVM インストールの場合は、
- オプション: Quarkus CLI がインストールされている。これは、ネイティブ実行可能ファイルをビルドする方法の 1 つとして使用できます。詳細は、Quarkus CLI のインストール を参照してください。
Quarkus CLI は、Quarkus プロジェクトの作成、更新、ビルドなどのタスクを含む開発目的で使用されます。Red Hat は、実稼働環境での Quarkus CLI の使用をサポートしていません。
手順
GraalVM または Mandrel の場合は、次のいずれかの方法を使用してネイティブ実行可能ファイルをビルドします。
Maven を使用:
./mvnw package -Dnative
Quarkus CLI を使用:
quarkus build --native
手順を実行した結果
これらのコマンドを実行すると、
target
ディレクトリーに*-runner
バイナリーが作成されます。その場合は、以下が適用されます。-
*-runner
ファイルは、Quarkus が生成するビルドされたネイティブバイナリーです。 target
ディレクトリーは、Maven アプリケーションをビルドするときに Maven が作成するディレクトリーです。注記ネイティブ実行可能ファイルをビルドすると、
quarkus.profile
プロパティーで変更されない限り、prod
プロファイルが有効になります。
-
ネイティブ実行可能ファイルを実行します。
./target/*-runner
関連情報
詳細は、Quarkus の「Producing a native executable」ガイドの Building a native executable セクションを参照してください。
1.2. カスタムコンテナーイメージの作成
以下のいずれかの方法を使用して、Quarkus アプリケーションからコンテナーイメージを作成できます。
- 手動によるコンテナーの作成
- OpenShift Container Platform Docker ビルドを使用してコンテナーを作成
Red Hat build of Quarkus アプリケーションをネイティブ実行可能ファイルにコンパイルすると、分析と最適化中に大量のメモリーが消費されます。quarkus.native.native-image-xmx
設定プロパティーを設定して、ネイティブコンパイル時に使用されるメモリーの量を制限できます。メモリー制限を低く設定すると、ビルド時間が長くなる可能性があります。
1.2.1. 手動によるコンテナーの作成
Linux AMD64 用のアプリケーションを使用して、コンテナーイメージを手動で作成できます。Quarkus ネイティブコンテナーを使用してネイティブイメージを生成すると、そのネイティブイメージは Linux AMD64 をターゲットとする実行可能ファイルを作成します。ホストオペレーティングシステムが Linux AMD64 ではない場合は、バイナリーを直接実行できず、手動でコンテナーを作成する必要があります。
Quarkus Getting Started プロジェクトには、以下の内容と共に src/main/docker
ディレクトリーに Dockerfile.native
が含まれます。
FROM registry.access.redhat.com/ubi9-minimal:9.5 WORKDIR /work/ RUN chown 1001 /work \ && chmod "g+rwX" /work \ && chown 1001:root /work COPY --chown=1001:root target/*-runner /work/application EXPOSE 8080 USER 1001 ENTRYPOINT ["./application", "-Dquarkus.http.host=0.0.0.0"]
Universal Base Image (UBI)
次のリストは、Dockerfile での使用に適したイメージを示しています。
Red Hat Universal Base Image 8 (UBI8)。このベースイメージは、コンテナー化されたすべてのアプリケーション、ミドルウェア、ユーティリティーのベースレイヤーになるように設計されています。
registry.access.redhat.com/ubi9/ubi:9.5
Red Hat Universal Base Image 8 Minimal (UBI8-minimal)。microdnf をパッケージマネージャーとして使用する、最小化された UBI8 イメージ。
registry.access.redhat.com/ubi9-minimal:9.5
- すべての Red Hat Base イメージは、コンテナーイメージ カタログサイトで入手できます。
手順
次のいずれかの方法を使用して、ネイティブ Linux 実行可能ファイルをビルドします。
Docker:
./mvnw package -Dnative -Dquarkus.native.container-build=true
Podman:
./mvnw package -Dnative -Dquarkus.native.container-build=true -Dquarkus.native.container-runtime=podman
次のいずれかの方法を使用して、コンテナーイメージをビルドします。
Docker:
docker build -f src/main/docker/Dockerfile.native -t quarkus-quickstart/getting-started .
Podman
podman build -f src/main/docker/Dockerfile.native -t quarkus-quickstart/getting-started .
次のいずれかの方法を使用して、コンテナーを実行します。
Docker:
docker run -i --rm -p 8080:8080 quarkus-quickstart/getting-started .
Podman:
podman run -i --rm -p 8080:8080 quarkus-quickstart/getting-started .
1.2.2. OpenShift Docker ビルドを使用してコンテナーを作成する
OpenShift Container Platform Docker ビルドストラテジーを使用して、Quarkus アプリケーションのコンテナーイメージを作成できます。このストラテジーは、クラスター内のビルド設定を使用してコンテナーイメージを作成します。
前提条件
-
OpenShift Container Platform クラスター、およびインストールされている最新バージョンの
oc
ツールにアクセスできる。oc
のインストールについては、CLI ツール ガイドの OpenShift CLI のインストール を参照してください。 - OpenShift Container Platform API エンドポイントの URL。
手順
OpenShift CLI にログインします。
oc login -u <username_url>
OpenShift に新規プロジェクトを作成します。
oc new-project <project_name>
src/main/docker/Dockerfile.native
ファイルに基づいてビルド設定を作成します。cat src/main/docker/Dockerfile.native | oc new-build --name <build_name> --strategy=docker --dockerfile -
プロジェクトをビルドします。
oc start-build <build_name> --from-dir .
プロジェクトを OpenShift Container Platform にデプロイします。
oc new-app <build_name>
サービスを公開するには、以下を実行します。
oc expose svc/<build_name>
1.3. ネイティブ実行可能ファイルの設定プロパティー
設定プロパティーは、ネイティブ実行可能ファイルの生成方法を定義します。application.properties
ファイルを使用して、Quarkus アプリケーションを設定できます。
設定プロパティー
以下の表は、ネイティブ実行可能ファイルの生成方法を定義するよう設定できる設定プロパティーのリストです。
プロパティー | 説明 | 型 | デフォルト |
|
デバッグを有効にし、別の | boolean |
|
| ネイティブイメージに追加するべきではないリソースパスに一致する glob のコンマ区切りリスト。 | 文字列のリスト | |
| ビルドプロセスにパスする追加の引数。 | 文字列のリスト | |
|
HTTP URL ハンドラーを有効にします。これにより、HTTP URL に対して | boolean |
|
|
HTTPS URL ハンドラーを有効にします。これにより、HTTPS URL に対して | boolean |
|
| ネイティブイメージにすべてのセキュリティーサービスを追加します。 | boolean |
|
| ネイティブイメージにすべてのキャラクターセットを追加します。これにより、イメージサイズが大きくなります。 | boolean |
|
| GraalVM ディストリビューションのパスが含まれます。 | string |
|
| JDK のパスが含まれます。 | file |
|
| ネイティブイメージを生成するために使用する Java の最大ヒープサイズ。 | string | |
| ネイティブイメージのビルドを実行する前に、デバッガーがビルドプロセスにアタッチするまで待機します。GraalVM インターナルの知識のあるユーザーにとって、これは高度なオプションになります。 | boolean |
|
|
| boolean |
|
| ネイティブイメージサーバーを再起動します。 | boolean |
|
| メモリー管理を改善するために分離を有効にします。 | boolean |
|
| ネイティブイメージが失敗した場合に、JVM ベースのフォールバックイメージを作成します。 | boolean |
|
| ネイティブイメージサーバーを使用します。これによりコンパイルが高速化されますが、キャッシュ無効化の問題により変更が失われる可能性があります。 | boolean |
|
|
すべての | boolean |
|
| 検査用にすべてのプロキシーのバイトコードをダンプします。 | boolean |
|
| コンテナーランタイムを使用するビルド。デフォルトで Docker が使用されます。 | boolean |
|
| イメージをビルドするための Docker イメージ。 | string |
|
| イメージのビルドに使用されるコンテナーランタイム。たとえば、Docker などがあります。 | string | |
| コンテナーランタイムにパスするオプション。 | 文字列のリスト | |
| イメージの VM イントロスペクションを有効化します。 | boolean |
|
| イメージのフルスタックトレースを有効化します。 | boolean |
|
| 呼び出しパスと、含まれるパッケージ、クラス、メソッドのレポートを生成します。 | boolean |
|
| フルスタックトレースを使用して例外を報告します。 | boolean |
|
| ランタイム時にエラーを報告します。これにより、サポートされていない機能を使用すると、ランタイムでアプリケーションが失敗する可能性があります。 | boolean |
|
|
ネイティブイメージに追加する必要のあるリソースパスに一致する glob のコンマ区切りリスト。すべてのプラットフォームで、パス区切り文字としてスラッシュ ( | 文字列のリスト |
ビルド設定中に、プロジェクト内で共通のパターンまたは場所を共有する一連のファイルまたはリソースを含める場合は、glob パターンを使用できます。
たとえば、複数の設定ファイルを含むディレクトリーがある場合は、glob パターンを使用してそのディレクトリー内のすべてのファイルを含めることができます。
以下に例を示します。
quarkus.native.resources.includes = my/config/files/*
次の例は、ネイティブイメージに追加するリソースパスに一致する glob のコンマ区切りリストを示しています。これらのパターンにより、クラスパスで見つかったすべての .png
イメージがネイティブイメージに追加されるほか、サブディレクトリーの下にネストされている場合でも、フォルダーバーの下の .txt
で終わるすべてのファイルが追加されます。
quarkus.native.resources.includes = **/*.png,bar/**/*.txt
サポートされている glob 機能
次の表は、サポートされる glob 機能とその説明をリスト化したものです。
文字 | 機能の説明 |
|
スラッシュ ( |
|
スラッシュ ( |
| 1 つの文字と一致しますが、スラッシュとは一致しません。 |
| 括弧内に指定された 1 文字を照合しますが、スラッシュは照合しません。 |
| ブラケットで指定した範囲の文字の 1 つと一致しますが、スラッシュとは一致しません。 |
| ブラケットで指定していない文字の 1 つと一致しますが、スラッシュとは一致しません。 |
| ブラケットで指定した範囲外の文字の 1 つと一致しますが、スラッシュとは一致しません。 |
| コンマで区切られた代替のトークンを照合します。トークンには、ワイルドカード、ネストされた論理和指定子、範囲が含まれます。 |
|
エスケープ文字。エスケープには、 |
1.3.1. Red Hat build of Quarkus ネイティブコンピレーションのメモリー消費を設定する
Red Hat build of Quarkus アプリケーションをネイティブ実行可能ファイルにコンパイルすると、分析と最適化中に大量のメモリーが消費されます。quarkus.native.native-image-xmx
設定プロパティーを設定して、ネイティブコンパイル時に使用されるメモリーの量を制限できます。メモリー制限を低く設定すると、ビルド時間が長くなる可能性があります。
手順
以下のいずれかの方法を使用して
quarkus.native.native-image-xmx
プロパティーに値を設定し、ネイティブイメージのビルドタイム中のメモリー消費を制限します。application.properties
ファイルを使用します。quarkus.native.native-image-xmx=<maximum_memory>
システムプロパティーの設定
mvn package -Dnative -Dquarkus.native.container-build=true -Dquarkus.native.native-image-xmx=<maximum_memory>
このコマンドは、Docker を使用してネイティブ実行可能ファイルをビルドします。Podman を使用するには、
-Dquarkus.native.container-runtime=podman
引数を追加します。
たとえば、メモリー制限を 8 GB に設定するには、quarkus.native.native-image-xmx=8g
を入力します。値は、2MB より大きい 1024 の倍数にする必要があります。メガバイトを示す m
または M
、ギガバイトを示す g
または G
の文字を追加します。
1.4. ネイティブ実行可能ファイルをテストする
ネイティブ実行可能ファイルの機能をテストするには、ネイティブモードでアプリケーションをテストします。@QuarkusIntegrationTest
アノテーションを使用してネイティブ実行可能ファイルをビルドし、HTTP エンドポイントに対してテストを実行します。
次の例は、GraalVM または Mandrel のローカルインストールを使用してネイティブ実行可能ファイルをテストする方法を示しています。テストを実行する前に、次の点を考慮してください。
- ネイティブ実行可能ファイルの作成 で説明されているように、このビルド方法は Red Hat build of Quarkus のサポート対象外です。
- ここでテストするネイティブ実行可能ファイルは、ホストのオペレーティングシステムとアーキテクチャーに一致する必要があります。したがって、ネイティブバイナリーが macOS 上のコンテナー内にビルドされている場合、この手順は使用できません。
手順
pom.xml
ファイルを開き、build
セクションに次の要素が含まれていることを確認します。<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> <version>${surefire-plugin.version}</version> <executions> <execution> <goals> <goal>integration-test</goal> <goal>verify</goal> </goals> <configuration> <systemPropertyVariables> <native.image.path>${project.build.directory}/${project.build.finalName}-runner</native.image.path> <java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager> <maven.home>${maven.home}</maven.home> </systemPropertyVariables> </configuration> </execution> </executions> </plugin>
-
Maven Failsafe プラグイン (
maven-failsafe-plugin
) は結合テストを実行し、生成されたネイティブ実行可能ファイルの場所を示します。
-
Maven Failsafe プラグイン (
src/test/java/org/acme/GreetingResourceIT.java
ファイルを開き、次のコンテンツが含まれていることを確認します。package org.acme; import io.quarkus.test.junit.QuarkusIntegrationTest; @QuarkusIntegrationTest 1 public class GreetingResourceIT extends GreetingResourceTest { 2 // Execute the same tests but in native mode. }
テストを実行します。
./mvnw verify -Dnative
以下の例は、このコマンドの出力を示しています。
./mvnw verify -Dnative .... GraalVM Native Image: Generating 'getting-started-1.0.0-SNAPSHOT-runner' (executable)... ======================================================================================================================== [1/8] Initializing... (6.6s @ 0.22GB) Java version: 21.0.4+7-LTS, vendor version: Mandrel-23.1.4.0-1b1 Graal compiler: optimization level: 2, target machine: x86-64-v3 C compiler: gcc (redhat, x86_64, 13.2.1) Garbage collector: Serial GC (max heap size: 80% of RAM) 2 user-specific feature(s) - io.quarkus.runner.Feature: Auto-generated class by Red Hat build of Quarkus from the existing extensions - io.quarkus.runtime.graal.DisableLoggingFeature: Disables INFO logging during the analysis phase [2/8] Performing analysis... [******] (40.0s @ 2.05GB) 10,318 (86.40%) of 11,942 types reachable 15,064 (57.36%) of 26,260 fields reachable 52,128 (55.75%) of 93,501 methods reachable 3,298 types, 109 fields, and 2,698 methods registered for reflection 63 types, 68 fields, and 55 methods registered for JNI access 4 native libraries: dl, pthread, rt, z [3/8] Building universe... (5.9s @ 1.31GB) [4/8] Parsing methods... [**] (3.7s @ 2.08GB) [5/8] Inlining methods... [***] (2.0s @ 1.92GB) [6/8] Compiling methods... [******] (34.4s @ 3.25GB) [7/8] Layouting methods... [**] (4.1s @ 1.78GB) [8/8] Creating image... [**] (4.5s @ 2.31GB) 20.93MB (48.43%) for code area: 33,233 compilation units 21.95MB (50.80%) for image heap: 285,664 objects and 8 resources 337.06kB ( 0.76%) for other data 43.20MB in total .... [INFO] [INFO] --- maven-failsafe-plugin:3.0.0-M7:integration-test (default) @ getting-started --- [INFO] Using auto detected provider org.apache.maven.surefire.junitplatform.JUnitPlatformProvider [INFO] [INFO] ------------------------------------------------------- [INFO] T E S T S [INFO] ------------------------------------------------------- [INFO] Running org.acme.GreetingResourceIT __ ____ __ _____ ___ __ ____ ______ --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \ --\___\_\____/_/ |_/_/|_/_/|_|\____/___/ 2024-09-27 14:04:52,681 INFO [io.quarkus] (main) getting-started 1.0.0-SNAPSHOT native (powered by Quarkus 3.20.0.redhat-00002) started in 0.038s. Listening on: http://0.0.0.0:8081 2024-09-27 14:04:52,682 INFO [io.quarkus] (main) Profile prod activated. 2024-09-27 14:04:52,682 INFO [io.quarkus] (main) Installed features: [cdi, rest, smallrye-context-propagation, vertx] [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.696 s - in org.acme.GreetingResourceIT [INFO] [INFO] Results: [INFO] [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] [INFO] --- maven-failsafe-plugin:3.0.0-M7:verify (default) @ getting-started ---
注記Quarkus は、ネイティブイメージが起動するのを 60 秒間待機してから、自動的にネイティブテストに失敗します。この期間は、
quarkus.test.wait-time
システムプロパティーを設定することで変更できます。以下のコマンドを使用して、待機時間を延長できます。この場合の
<duration>
は待機時間 (秒単位) です。./mvnw verify -Dnative -Dquarkus.test.wait-time=<duration>
注記-
デフォルトでは、
quarkus.test.native-image-profile
プロパティーで変更されていない限り、ネイティブテストはprod
プロファイルを使用して実行されます。
-
デフォルトでは、
1.4.1. ネイティブ実行可能ファイルとして実行する場合のテストを除外する
ネイティブ実行可能ファイルに対してテストを実行する場合、たとえばアプリケーションの HTTP エンドポイントと対話するなどの、ブラックボックステストのみを実行できます。
ブラックボックス とは、ブラックボックステストなど、製品またはプログラムの隠された内部動作を指します。
テストはネイティブでは実行されないため、Java 仮想マシン (JVM) でテストを実行する場合のようにアプリケーションのコードにリンクすることはできません。したがって、ネイティブテストでは Bean を注入できません。
JVM とネイティブ実行の間でテストクラスを共有し、@DisabledOnIntegrationTest
アノテーションを使用して特定のテストを除外して、その JVM 上でのみテストを実行できます。
1.4.2. 既存のネイティブ実行可能ファイルのテスト
Failsafe
Maven プラグインを使用すると、既存の実行可能ビルドに対してテストを実行できます。ビルド後に、バイナリーで複数のテストセットを段階的に実行できます。
Quarkus で生成したネイティブ実行可能ファイルをテストするには、利用可能な Maven コマンドを使用します。コマンドラインを使用してこのタスクを完了できる同等の Quarkus CLI コマンドはありません。
手順
ビルド済みのネイティブ実行可能ファイルに対してテストを実行します。
./mvnw test-compile failsafe:integration-test -Dnative
このコマンドは、
Failsafe
Maven プラグインを使用して、既存のネイティブイメージに対してテストを実行します。あるいは、以下のコマンドを使用してネイティブ実行可能ファイルへのパスを指定することもできます。
<path>
は、ネイティブイメージパスになります。./mvnw test-compile failsafe:integration-test -Dnative.image.path=<path>
1.5. 関連情報
改訂日時: 2025-05-09