The English version of quarkus.io is the official project site. Translated sites are community supported on a best-effort basis.

Building a Native Executable

このガイドでは以下をカバーしています:

  • アプリケーションをネイティブ実行可能ファイルにコンパイル

  • ネイティブ実行可能ファイルのコンテナーへのパッケージング

  • ネイティブ実行可能ファイルのデバッグ

This guide takes as input the application developed in the Getting Started Guide.

GraalVM

ネイティブな実行可能ファイルをビルドするには、GraalVM のディストリビューションを使用する必要があります。ディストリビューションは3つあります。Oracle GraalVM Community Edition (CE)、Oracle GraalVM Enterprise Edition (EE)、そして Mandrel です。Oracle ディストリビューションと Mandrel ディストリビューションの違いは以下の通りです。

  • Mandrelは、Oracle GraalVM CEのダウンストリームディストリビューションです。Mandrelの主な目的は、Quarkusをサポートするために特別に設計されたネイティブ実行可能ファイルを構築する方法を提供することです。

  • Mandrel のリリースは、アップストリームのOracle GraalVM CEコードベースから派生したコードベースから構築されており、わずかな変更しか行われていませんが、Quarkusネイティブアプリには必要ない重要な除外事項がいくつかあります。これらのリリースは、Oracle GraalVM CEと同じ機能をサポートしており、機能に大きな変更はありません。特筆すべきは、多言語プログラミングのサポートが含まれていないことです。これらの除外の理由は、大多数のQuarkusユーザーにより良いレベルのサポートを提供するためです。また、これらの除外は、Oracle GraalVM CE/EEと比較して、Mandrelの配布サイズが大幅に縮小されていることを意味しています。

  • Mandrel is built slightly differently to Oracle GraalVM CE, using the standard OpenJDK project. This means that it does not profit from a few small enhancements that Oracle have added to the version of OpenJDK used to build their own GraalVM downloads. These enhancements are omitted because upstream OpenJDK does not manage them, and cannot vouch for. This is particularly important when it comes to conformance and security.

  • Mandrel is recommended for building native executables that target Linux containerized environments. This means that Mandrel users are encouraged to use containers to build their native executables. If you are building native executables for macOS, you should consider using Oracle GraalVM instead, because Mandrel does not currently target this platform. Building native executables directly on bare metal Linux or Windows is possible, with details available in the Mandrel README and Mandrel releases.

前提条件

このガイドを完成させるには、以下が必要です:

C言語でのネイティブコンパイルをサポート

動作するC言語の開発環境があるとはどういう意味でしょうか?

  • Linuxでは、GCC、glibc、zlibヘッダが必要です。一般的なディストリビューションでは次の通りです:

    # dnf (rpm-based)
    sudo dnf install gcc glibc-devel zlib-devel libstdc++-static
    # Debian-based distributions:
    sudo apt-get install build-essential libz-dev zlib1g-dev
  • macOS では、XCode が必要な依存関係を提供します:

    xcode-select --install
  • Windowsの場合は、 Visual Studio 2017 Visual C++ Build Tools をインストールする必要があります。

GraalVM の設定

GraalVMをインストールできない場合は、マルチステージのDockerビルドを使用して、GraalVMを含むDockerコンテナー内でMavenを実行することができます。このガイドの最後にこれを行う方法の説明があります。

Version 22.1 が必要です。コミュニティエディションで大丈夫です。

  1. Install GraalVM if you haven’t already. You have a few options for this:

  2. ランタイム環境を構成します。 GRAALVM_HOME 環境変数をGraalVMインストールディレクトリーに設定します。例えば、

    export GRAALVM_HOME=$HOME/Development/graalvm/

    On macOS (not supported by Mandrel), point the variable to the Home sub-directory:

    export GRAALVM_HOME=$HOME/Development/graalvm/Contents/Home/

    Windowsでは、コントロールパネルから環境変数を設定する必要があります。

    scoop でインストールすれば自動的に設定されます。

  3. (Only for Oracle GraalVM CE/EE) Install the native-image tool using gu install:

    ${GRAALVM_HOME}/bin/gu install native-image

    GraalVMの以前のリリースでは、デフォルトで native-image ツールが含まれていました。現在はそのようになっておらず、GraalVM自体をインストールした後の第二ステップとしてインストールする必要があります。注意: #graal-and-catalina[macOS CatalinaでGraalVMを使用する]際に、未解決の問題が発生しています。

  4. (オプション) 環境変数 JAVA_HOME を GraalVM のインストールディレクトリーに設定します。

    export JAVA_HOME=${GRAALVM_HOME}
  5. (オプション) GraalVM bin ディレクトリーをパスに追加します。

    export PATH=${GRAALVM_HOME}/bin:$PATH
macOS CatalinaでGraalVMを使用している場合の問題

この GraalVMの問題で報告されているように、GraalVMバイナリーは(まだ)macOS Catalinaに対して認証されていません。これは、gu 使用時に次のエラーが表示される可能性があることを意味します:

“gu” cannot be opened because the developer cannot be verified

回避策として、次のコマンドを使用して、GraalVMインストールディレクトリー上の com.apple.quarantine 拡張属性を再帰的に削除します。

xattr -r -d com.apple.quarantine ${GRAALVM_HOME}/../..

ソリューション

次のセクションの手順に従って、アプリケーションを段階的にパッケージ化することをお勧めします。しかしながら、完成したサンプルに直接進むこともできます。

Gitレポジトリをクローンするか git clone https://github.com/quarkusio/quarkus-quickstarts.gitアーカイブ をダウンロードします。

ソリューションは getting-started ディレクトリーに存在します。

ネイティブ実行可能ファイルの生成

アプリケーションのネイティブ実行可能ファイルには、アプリケーション・コード、必要なライブラリ、Java API、および VM の縮小版が含まれます。VM ベースが小さくなることで、アプリケーションの起動時間が改善され、ディスクフットプリントが最小限に抑えられます。

ネイティブ実行可能ファイルの生成

前回のチュートリアルでアプリケーションを生成した場合は、 pom.xml に以下の プロファイル があります。

<profiles>
    <profile>
        <id>native</id>
        <properties>
            <quarkus.package.type>native</quarkus.package.type>
        </properties>
    </profile>
</profiles>

<quarkus.native.additional-build-args> プロパティーを使用して、 native-image コマンドにカスタムオプションを指定できます。複数のオプションはカンマで区切ることができます。

もう一つの可能性は、 application.propertiesquarkus.native.additional-build-args 設定プロパティーを含めることです。

ネイティブイメージビルド処理の設定方法については、以下の [設定リファレンス] の項で詳しく説明しています。

プロファイルを使用しているのは、すぐにわかると思いますが、ネイティブ実行可能ファイルをパッケージ化するのに 分かかるからです。コマンドラインのプロパティーとして -Dquarkus.package.type=native を渡すだけでもいいのですが、プロファイルを使う方がいいでしょう。

Create a native executable using:

CLI
quarkus build --native
Maven
./mvnw package -Dnative
Gradle
./gradlew build -Dquarkus.package.type=native
Windowsでのパッケージングに関する問題

Visual Studio の Microsoft Native Tools はパッケージングを行う前に、初期化する必要があります。これは、Visual Studio ビルドツールと一緒にインストールされた x64 Native Tools Command Prompt を起動することで行うことができます。 x64 Native Tools Command Prompt で、プロジェクト・フォルダーに移動して mvnw package -Pnative を実行してください。

もう一つのソリューションは、これを行うためのスクリプトを書くことです。

cmd /c 'call "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Auxiliary\Build\vcvars64.bat" && mvn package -Pnative'

通常のファイルに加えて、このビルドでは target/getting-started-1.0-SNAPSHOT-runner を生成します。これを実行するには、次のようにします: ./target/getting-started-1.0-SNAPSHOT-runner .

Java preview features

Java code that relies on preview features requires special attention. To produce a native executable, this means that the --enable-preview flag needs to be passed to the underlying native image invocation. You can do so by prepending the flag with -J and passing it as additional native build argument: -Dquarkus.native.additional-build-args=-J—​enable-preview.

Build fully static native executables

Fully static native executables support is experimental.

On Linux it’s possible to package a native executable that doesn’t depend on any system shared library. There are some system requirements to be fulfilled and additional build arguments to be used along with the native-image invocation, a minimum is -Dquarkus.native.additional-build-args="--static","--libc=musl".

Compiling fully static binaries is done by statically linking musl instead of glibc and should not be used in production without rigorous testing.

ネイティブ実行可能ファイルのテスト

Producing a native executable can lead to a few issues, and so it’s also a good idea to run some tests against the application running in the native file. The reasoning is explained in the Testing Guide.

To see the GreetingResourceIT run against the native executable, use ./mvnw verify -Pnative:

$ ./mvnw verify -Pnative
...
[getting-started-1.0.0-SNAPSHOT-runner:18820]     universe:     587.26 ms
[getting-started-1.0.0-SNAPSHOT-runner:18820]      (parse):   2,247.59 ms
[getting-started-1.0.0-SNAPSHOT-runner:18820]     (inline):   1,985.70 ms
[getting-started-1.0.0-SNAPSHOT-runner:18820]    (compile):  14,922.77 ms
[getting-started-1.0.0-SNAPSHOT-runner:18820]      compile:  20,361.28 ms
[getting-started-1.0.0-SNAPSHOT-runner:18820]        image:   2,228.30 ms
[getting-started-1.0.0-SNAPSHOT-runner:18820]        write:     364.35 ms
[getting-started-1.0.0-SNAPSHOT-runner:18820]      [total]:  52,777.76 ms
[INFO]
[INFO] --- maven-failsafe-plugin:2.22.1:integration-test (default) @ getting-started ---
[INFO]
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running org.acme.quickstart.GreetingResourceIT
Executing [/data/home/gsmet/git/quarkus-quickstarts/getting-started/target/getting-started-1.0.0-SNAPSHOT-runner, -Dquarkus.http.port=8081, -Dtest.url=http://localhost:8081, -Dquarkus.log.file.path=build/quarkus.log]
2019-04-15 11:33:20,348 INFO  [io.quarkus] (main) Quarkus 999-SNAPSHOT started in 0.002s. Listening on: http://[::]:8081
2019-04-15 11:33:20,348 INFO  [io.quarkus] (main) Installed features: [cdi, resteasy-reactive]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.387 s - in org.acme.quickstart.GreetingResourceIT
...

By default, Quarkus waits for 60 seconds for the native image to start before automatically failing the native tests. This duration can be changed using the quarkus.test.wait-time system property. For example, to increase the duration to 300 seconds, use: ./mvnw verify -Pnative -Dquarkus.test.wait-time=300.

This procedure was formerly accomplished using the @NativeImageTest annotation. @NativeImageTest is considered deprecated in favor of @QuarkusIntegrationTest which provides a superset of the testing capabilities of @NativeImageTest. More information about @QuarkusIntegrationTest can be found in the Testing Guide.

プロファイル

By default, integration tests both build and run the native executable using the prod profile.

You can override the profile the executable runs with during the test using the quarkus.test.native-image-profile property. Either by adding it to application.properties or by appending it to the command line: ./mvnw verify -Pnative -Dquarkus.test.native-image-profile=test. Your %test. prefixed properties will be used at the test runtime.

You can override the profile the executable is built with and runs with using the quarkus-profile=test property, e.g. ./mvnw clean verify -Pnative -Dquarkus-profile=test. This might come handy if there are test specific resources to be processed, such as importing test data into the database.

With the aforementioned example in your `application.properties`, your Hibernate ORM managed database will be populated with test data both during the JVM mode test run and during the native mode test run. The production executable will contain only the `version.txt` resource, no superfluous test data.

[WARNING]
====
The executable built with `-Dquarkus-profile=test` is not suitable for production deployment. It contains your test resources files and settings. Once the testing is done, the executable would have to be built again, using the default, `prod` profile.
====

=== Java preview features

[[graal-test-preview]]
[NOTE]
.Java preview features
====
Java code that relies on preview features requires special attention. To test a native executable, this means that the `--enable-preview` flag needs to be passed to the Surefire plugin. Adding `<argLine>--enable-preview</argLine>` to its `configuration` section is one way to do so.
====

=== ネイティブ実行可能ファイルとして実行している場合のテストの除外

この方法でテストを実行する場合、実際にネイティブで実行されるのはアプリケーションのエンドポイントのみで、HTTP 呼び出しでしかテストできません。テストコードは実際にはネイティブには実行されないので、HTTP エンドポイントを呼び出さないコードをテストしている場合は、ネイティブテストの一部として実行するのは良い考えではないでしょう。

If you share your test class between JVM and native executions like we advise above, you can mark certain tests with the `@DisabledOnIntegrationTest` annotation in order to skip them when testing against a native image.

[NOTE]
====
Using `@DisabledOnIntegrationTest` will also disable the test in all integration test instances, including testing the application in JVM mode, in a container image, and native image.
====

=== 既存のネイティブ実行可能ファイルのテスト

It is also possible to re-run the tests against a native executable that has already been built. To do this run `./mvnw test-compile failsafe:integration-test -Pnative`. This will discover the existing native image and run the tests against it using failsafe.

何らかの理由でプロセスがネイティブイメージを見つけられない場合や、ターゲットディレクトリーにないネイティブイメージをテストしたい場合は、 `-Dnative.image.path=` システムプロパティーで実行ファイルを指定することができます。

[#container-runtime]
== GraalVMをインストールしていない状態でLinux実行ファイルを作成する

IMPORTANT: 先に進む前に、コンテナーランタイム(Docker、podman)の動作環境が整っていることを確認しておきましょう。WindowsでDockerを使用している場合は、Docker Desktopのファイル共有設定でプロジェクトのドライブを共有し、Docker Desktopを再起動する必要があります。

多くの場合、Quarkusアプリケーション用のネイティブLinux実行ファイルを作成する必要があります(例えば、コンテナー化された環境で実行するためなど)、このタスクを達成するために適切なGraalVMバージョンをインストールする手間を省きたいと考えています(例えば、CI環境では、できるだけ少ないソフトウェアをインストールするのが一般的です)。

このため、Quarkusでは、Dockerやpodmanなどのコンテナーランタイムを利用して、ネイティブのLinux実行ファイルを作成する非常に便利な方法を提供しています。このタスクを達成する最も簡単な方法は、次を実行することです:

[source, bash, subs=attributes+,,  role="primary asciidoc-tabs-sync-cli"]
.CLI
----
quarkus build --native --no-tests -Dquarkus.native.container-build=true
# The --no-tests flag is required only on Windows and macOS.
----
[source, bash, subs=attributes+,,  role="secondary asciidoc-tabs-sync-maven"]
.Maven
----
./mvnw package -Dnative -Dquarkus.native.container-build=true
----
[source, bash, subs=attributes+,,  role="secondary asciidoc-tabs-sync-gradle"]
.Gradle
----
./gradlew build -Dquarkus.package.type=native -Dquarkus.native.container-build=true
----

[TIP]
====
By default, Quarkus automatically detects the container runtime. If you want to explicitly select the container runtime, you can do it with:

For Docker:

:build-additional-parameters: -Dquarkus.native.container-runtime=docker
[source, bash, subs=attributes+,,  role="primary asciidoc-tabs-sync-cli"]
.CLI
----
quarkus build --native -Dquarkus.native.container-build=true {build-additional-parameters}
----
[source, bash, subs=attributes+,,  role="secondary asciidoc-tabs-sync-maven"]
.Maven
----
./mvnw package -Dnative -Dquarkus.native.container-build=true {build-additional-parameters}
----
[source, bash, subs=attributes+,,  role="secondary asciidoc-tabs-sync-gradle"]
.Gradle
----
./gradlew build -Dquarkus.package.type=native -Dquarkus.native.container-build=true {build-additional-parameters}
----
:!build-additional-parameters:

For podman:

:build-additional-parameters: -Dquarkus.native.container-runtime=podman
[source, bash, subs=attributes+,,  role="primary asciidoc-tabs-sync-cli"]
.CLI
----
quarkus build --native -Dquarkus.native.container-build=true {build-additional-parameters}
----
[source, bash, subs=attributes+,,  role="secondary asciidoc-tabs-sync-maven"]
.Maven
----
./mvnw package -Dnative -Dquarkus.native.container-build=true {build-additional-parameters}
----
[source, bash, subs=attributes+,,  role="secondary asciidoc-tabs-sync-gradle"]
.Gradle
----
./gradlew build -Dquarkus.package.type=native -Dquarkus.native.container-build=true {build-additional-parameters}
----
:!build-additional-parameters:

これらは通常のQuarkusの設定プロパティーなので、常にコンテナーでビルドしたい場合は、毎回指定しなくて済むように、 `application.properties` に追加することをお勧めします。
====

[TIP]
====
JARが正常にビルドされているにもかかわらず、コンテナビルドでネイティブ実行可能ファイルを作成しようとすると、アプリケーションJARに対して以下のようなinvalid pathエラーが表示される場合は、コンテナランタイムにリモートデーモンを使用している可能性があります。
----
Error: Invalid Path entry getting-started-1.0.0-SNAPSHOT-runner.jar
Caused by: java.nio.file.NoSuchFileException: /project/getting-started-1.0.0-SNAPSHOT-runner.jar
----
この場合、パラメータ `-Dquarkus.native.container-build=true` の代わりに `-Dquarkus.native.remote-container-build=true` を使用してください。

その理由は、 `-Dquarkus.native.container-build=true` を通して起動されるローカルビルドドライバは、ビルドコンテナで JAR を利用できるようにするためにボリュームマウントを使用しますが、ボリュームマウントはリモートデーモンでは機能しません。リモートコンテナのビルドドライバは、必要なファイルをマウントするのではなく、コピーします。リモートドライバはローカルデーモンでも動作しますが、ローカルの場合はローカルドライバを使用した方が良いことに注意してください。なぜなら、マウントの方がコピーよりもパフォーマンスが高いからです。
====

[TIP]
====
Mandrelを使ってビルドするには、カスタムビルダーのイメージパラメーターを追加で渡す必要があります:

:build-additional-parameters: -Dquarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-mandrel:{mandrel-flavor}
[source, bash, subs=attributes+,,  role="primary asciidoc-tabs-sync-cli"]
.CLI
----
quarkus build --native -Dquarkus.native.container-build=true {build-additional-parameters}
----
[source, bash, subs=attributes+,,  role="secondary asciidoc-tabs-sync-maven"]
.Maven
----
./mvnw package -Dnative -Dquarkus.native.container-build=true {build-additional-parameters}
----
[source, bash, subs=attributes+,,  role="secondary asciidoc-tabs-sync-gradle"]
.Gradle
----
./gradlew build -Dquarkus.package.type=native -Dquarkus.native.container-build=true {build-additional-parameters}
----
:!build-additional-parameters:

上記のコマンドはフローティングタグを指していることに注意してください。ビルダーイメージを最新かつ安全に保つために、フローティングタグを使用することを強く推奨します。どうしても必要な場合は、特定のタグをハードコーディングしても構いませんが(利用可能なタグについては https://quay.io/repository/quarkus/ubi-quarkus-mandrel?tab=tags[こちら]を参照してください)、その方法ではセキュリティーアップデートが受けられず、サポートされていないことに注意してください。
====

== コンテナーの作成

=== コンテナーイメージのエクステンションの使用

Quarkusアプリケーションからコンテナーイメージを作成する最も簡単な方法は、コンテナーイメージ エクステンションの1つを利用することです。

これらのエクステンションのいずれかが存在する場合、ネイティブ実行可能ファイル用のコンテナーイメージを作成することは、基本的には単一のコマンドを実行することになります:

[source, bash]
----
./mvnw package -Pnative -Dquarkus.native.container-build=true -Dquarkus.container-image.build=true
----

* `quarkus.native.container-build=true` では GraalVM がインストールされていなくても Linux の実行ファイルを作成することができます(ローカルに GraalVM がインストールされていない場合や、ローカルのオペレーティングシステムが Linux ではない場合にのみ必要です)。
* `quarkus.container-image.build=true` 最終的なアプリケーションアーティファクト(この場合はネイティブ実行可能ファイル)を使用してコンテナーイメージを作成するようにQuarkusに指示します。

See the xref:container-image.adoc[Container Image guide] for more details.

=== Manually using the micro base image

Quarkus Mavenプラグインで生成されたJARを使用して、コンテナー内でアプリケーションを実行することができます。ただし、このセクションでは、生成されたネイティブ実行可能ファイルを使用してコンテナーイメージを作成することに焦点を当てます。

image:containerization-process.png[alt="Containerization Process"]

ローカルのGraalVMインストール環境を使用する場合、ネイティブ実行可能ファイルは、ローカルのオペレーティングシステム(Linux、macOS、Windowsなど)をターゲットにしています。しかし、コンテナーはオペレーティングシステムによって生成されたものと同じ _実行_ 形式を使用しない場合があるため、コンテナーランタイムを活用して実行形式を生成するようにMavenビルドに指示します(この <<#container-runtime, セクション>> で説明されているように)。

The produced executable will be a 64-bit Linux executable, so depending on your operating system it may no longer be runnable. However, it's not an issue as we are going to copy it to a container. The project generation has provided a `Dockerfile.native-micro` in the `src/main/docker` directory with the following content:

[source, dockerfile]
----
FROM quay.io/quarkus/quarkus-micro-image:1.0
WORKDIR /work/
COPY target/*-runner /work/application
RUN chmod 775 /work
EXPOSE 8080
CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]
----

[NOTE]
.Quarkus Micro Image?
====
The Quarkus Micro Image is a small container image providing the right set of dependencies to run your native application. It is based on https://catalog.redhat.com/software/containers/ubi8-micro/601a84aadd19c7786c47c8ea?container-tabs=overview[UBI Micro]. This base image has been tailored to work perfectly in containers.

You can read more about UBI images on:

* https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image[Introduction to Universal Base Image]
* https://catalog.redhat.com/software/container-stacks/detail/5ec53f50ef29fd35586d9a56[Red Hat Universal Base Image 8]

UBI images can be used without any limitations.

xref:quarkus-runtime-base-image.adoc[This page] explains how to extend the `quarkus-micro` image when your application has specific requirements.
====

あとは、生成されたネイティブ実行可能ファイルを削除していなければ、dockerイメージを使ってビルドします:

[source, bash]
----
docker build -f src/main/docker/Dockerfile.native -t quarkus-quickstart/getting-started .
----

そして最後に、以下を実行します:

[source, bash]
----
docker run -i --rm -p 8080:8080 quarkus-quickstart/getting-started
----

=== Manually using the minimal base image

The project generation has also provided a `Dockerfile.native` in the `src/main/docker` directory with the following content:

[source, dockerfile]
----
FROM registry.access.redhat.com/ubi8/ubi-minimal:8.5
WORKDIR /work/
COPY target/*-runner /work/application
RUN chmod 775 /work
EXPOSE 8080
CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]
----

The UBI minimal image is bigger than the micro one mentioned above. It contains more utilities such as the `microdnf` package manager.

[#multistage-docker]
=== マルチステージDockerビルドの使用

The previous section showed you how to build a native executable using Maven or Gradle, but it requires you to have created the native executable first. In addition, this native executable must be a Linux 64 bits executable.

You may want to build the native executable directly in a container without having a final container containing the build tools. That approach is possible with a multi-stage Docker build:

1. The first stage builds the native executable using Maven or Gradle
2. The second stage is a minimal image copying the produced native executable

Such a multi-stage build can be achieved as follows:

MavenでビルドするためのサンプルDockerfileです。
[source, dockerfile, subs=attributes+]
----
## Stage 1 : build with maven builder image with native capabilities
FROM quay.io/quarkus/ubi-quarkus-native-image:{graalvm-flavor} AS build
COPY --chown=quarkus:quarkus mvnw /code/mvnw
COPY --chown=quarkus:quarkus .mvn /code/.mvn
COPY --chown=quarkus:quarkus pom.xml /code/
USER quarkus
WORKDIR /code
RUN ./mvnw -B org.apache.maven.plugins:maven-dependency-plugin:3.1.2:go-offline
COPY src /code/src
RUN ./mvnw package -Pnative

## Stage 2 : create the docker final image
FROM quay.io/quarkus/quarkus-micro-image:1.0
WORKDIR /work/
COPY --from=build /code/target/*-runner /work/application

# set up permissions for user `1001`
RUN chmod 775 /work /work/application \
  && chown -R 1001 /work \
  && chmod -R "g+rwX" /work \
  && chown -R 1001:root /work

EXPOSE 8080
USER 1001

CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]
----

NOTE: This multi-stage Docker build copies the Maven wrapper from the host machine. The Maven wrapper (or the Gradle wrapper) is a convenient way to provide a specific version of Maven/Gradle. It avoids having to create a base image with Maven and Gradle. To provision the Maven Wrapper in your project, use: `mvn -N org.apache.maven.plugins:maven-wrapper-plugin:3.1.0:wrapper`.

このファイルは、Getting started quickstartには含まれていないので、 `src/main/docker/Dockerfile.multistage` に保存してください。

GradleでビルドするためのサンプルDockerfileです。
[source, dockerfile, subs=attributes+]
----
## Stage 1 : build with maven builder image with native capabilities
FROM quay.io/quarkus/ubi-quarkus-native-image:{graalvm-flavor} AS build
USER root
RUN microdnf install findutils
COPY --chown=quarkus:quarkus gradlew /code/gradlew
COPY --chown=quarkus:quarkus gradle /code/gradle
COPY --chown=quarkus:quarkus build.gradle /code/
COPY --chown=quarkus:quarkus settings.gradle /code/
COPY --chown=quarkus:quarkus gradle.properties /code/
USER quarkus
WORKDIR /code
COPY src /code/src
RUN ./gradlew build -Dquarkus.package.type=native

## Stage 2 : create the docker final image
FROM quay.io/quarkus/quarkus-micro-image:1.0
WORKDIR /work/
COPY --from=build /code/build/*-runner /work/application
RUN chmod 775 /work
EXPOSE 8080
CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]
----

プロジェクトでGradleを使用している場合は、このサンプルDockerfileを使用することができます。 `src/main/docker/Dockerfile.multistage` に保存してください。

[WARNING]
====
Before launching our Docker build, we need to update the default `.dockerignore` file as it filters everything except the `target` directory. As we plan to build inside a container, we need to copy the `src` directory. Thus, edit your `.dockerignore` and update the content.
====

[source, bash]
----
docker build -f src/main/docker/Dockerfile.multistage -t quarkus-quickstart/getting-started .
----

And, finally, run it with:

[source, bash]
----
docker run -i --rm -p 8080:8080 quarkus-quickstart/getting-started
----

[TIP]
====
ネイティブ実行可能ファイルにSSLサポートが必要な場合は、Dockerイメージに必要なライブラリを簡単に含めることができます。

Please see xref:native-and-ssl.adoc#working-with-containers[our Using SSL With Native Executables guide] for more information.
====

NOTE: To use Mandrel instead of GraalVM CE, update the `FROM` clause to: `FROM quay.io/quarkus/ubi-quarkus-mandrel:$TAG AS build`. `$TAG` can be found on the https://quay.io/repository/quarkus/ubi-quarkus-mandrel?tab=tags[Quarkus Mandrel Images Tags page].

=== Using a Distroless base image

IMPORTANT: Distroless image support is experimental.

If you are looking for small container images, the https://github.com/GoogleContainerTools/distroless[distroless] approach reduces the size of the base layer. The idea behind _distroless_ is the usage of a single and minimal base image containing all the requirements, and sometimes even the application itself.

Quarkus provides a distroless base image that you can use in your `Dockerfile`. You only need to copy your application, and you are done:

[source, dockerfile]
----
FROM quay.io/quarkus/quarkus-distroless-image:1.0
COPY target/*-runner /application

EXPOSE 8080
USER nonroot

CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]
----

Quarkus provides the `quay.io/quarkus/quarkus-distroless-image:1.0` image. It contains the required packages to run a native executable and is only **9Mb**. Just add your application on top of this image, and you will get a tiny container image.

Distroless images should not be used in production without rigorous testing.

=== Using a scratch base image

IMPORTANT: Scratch image support is experimental.

Building fully statically linked binaries enables the usage of a https://hub.docker.com/_/scratch[scratch image] containing solely the resulting native executable.

Sample multistage Dockerfile for building an image from `scratch`:

[source, dockerfile]
----
## Stage 1 : build with maven builder image with native capabilities
FROM quay.io/quarkus/ubi-quarkus-native-image:22.0-java11 AS build
USER root
RUN microdnf install make gcc
COPY --chown=quarkus:quarkus mvnw /code/mvnw
COPY --chown=quarkus:quarkus .mvn /code/.mvn
COPY --chown=quarkus:quarkus pom.xml /code/
RUN mkdir /musl && \
    curl -L -o musl.tar.gz https://more.musl.cc/10.2.1/x86_64-linux-musl/x86_64-linux-musl-native.tgz && \
    tar -xvzf musl.tar.gz -C /musl --strip-components 1 && \
    curl -L -o zlib.tar.gz https://zlib.net/zlib-1.2.12.tar.gz && \
    mkdir zlib && tar -xvzf zlib.tar.gz -C zlib --strip-components 1 && \
    cd zlib && ./configure --static --prefix=/musl && \
    make && make install && \
    cd .. && rm -rf zlib && rm -f zlib.tar.gz && rm -f musl.tar.gz
ENV PATH="/musl/bin:${PATH}"
USER quarkus
WORKDIR /code
RUN ./mvnw -B org.apache.maven.plugins:maven-dependency-plugin:3.1.2:go-offline
COPY src /code/src
RUN ./mvnw package -Pnative -Dquarkus.native.additional-build-args="--static","--libc=musl"

## Stage 2 : create the docker final image
FROM scratch
COPY --from=build /code/target/*-runner /application
ENTRYPOINT [ "/application" ]
----

Scratch images should not be used in production without rigorous testing.

=== Native executable compression

Quarkus can compress the produced native executable using UPX. More details on xref:./upx.adoc[UPX Compression documentation].

=== Separating Java and native image compilation

In certain circumstances, you may want to build the native image in a separate step. For example, in a CI/CD pipeline, you may want to have one step to generate the source that will be used for the native image generation and another step to use these sources to actually build the native executable. For this use case, you can set the `quarkus.package.type=native-sources`. This will execute the java compilation as if you had started native compilation (`-Pnative`), but stops before triggering the actual call to GraalVM's `native-image`.

[source, bash]
----
$ ./mvnw clean package -Dquarkus.package.type=native-sources
----

After compilation has finished, you find the build artifact in `target/native-sources`:

[source, bash]
----
$ cd target/native-sources
$ ls
native-image.args  getting-started-1.0.0-SNAPSHOT-runner.jar lib
----

From the output above one can see that, in addition to the produced jar file and the associated lib directory, a text file named `native-image.args` was created. This file holds all parameters (including the name of the JAR to compile) to pass along to GraalVM's `native-image` command. If you have GraalVM installed, you can start the native compilation by executing:

[source, bash]
----
$ cd target/native-source
$ native-image $(cat native-image.args)
...
$ ls
native-image.args
getting-started-1.0.0-SNAPSHOT-runner
getting-started-1.0.0-SNAPSHOT-runner.build_artifacts.txt
getting-started-1.0.0-SNAPSHOT-runner.jar
----

The process for Gradle is analogous.

Running the build process in a container is also possible:

[source, bash, subs=attributes+]
----
cd target/native-image
docker run \
  -it \
  --rm \
  --v $(pwd):/work (1)
  -w /work (2)
  --entrypoint bin/sh \
  quay.io/quarkus/ubi-quarkus-native-image:{graalvm-flavor} \ (3)
  -c "native-image $(cat native-image.args) -J-Xmx4g" (4)
----

<1> Mount the host's directory `target/native-image` to the container's `/work`. Thus, the generated binary will also be written to this directory.
<2> Switch the working directory to `/work`, which we have mounted in <1>.
<3> Use the `quay.io/quarkus/ubi-quarkus-native-image:{graalvm-flavor}` docker image introduced in <<#multistage-docker,Using a multi-stage Docker build>> to build the native image.
<4> Call `native-image` with the content of file `native-image.args` as arguments. We also supply an additional argument to limit the process's maximum memory to 4 Gigabytes (this may vary depending on the project being built and the machine building it).

[WARNING]
====
If you are running on a Windows machine, please keep in mind that the binary was created within a Linux docker container. Hence, the binary will not be executable on the host Windows machine.
====

A high level overview of what the various steps of a CI/CD pipeline would look is the following:

1. Register the output of the step executing `./mvnw ...` command (i.e. directory `target/native-image`) as a build artifact,
2. Require this artifact in the step executing the `native-image ...` command, and
3. Register the output of the step executing the `native-image ...` command (i.e. files matching `target/*runner`) as build artifact.

The environment executing step `1` only needs Java and Maven (or Gradle) installed, while the environment executing step `3` only needs a GraalVM installation (including the `native-image` feature).

Depending on what the final desired output of the CI/CD pipeline is, the generated binary might then be used to create a container image.

== ネイティブ実行可能ファイルのデバッグ

Starting with Oracle GraalVM 20.2 or Mandrel 20.1, debug symbols for native executables can be generated for Linux environments (Windows support is still under development, macOS is not supported). These symbols can be used to debug native executables with tools such as `gdb`.

デバッグシンボルを生成するには、ネイティブ実行可能ファイルの生成時に `-Dquarkus.native.debug.enabled=true` フラグを追加してください。ネイティブ実行可能ファイルのデバッグシンボルは、ネイティブ実行可能ファイルの隣にある `.debug` ファイルにあります。

[NOTE]
====
The generation of the `.debug` file depends on `objcopy`. On common Linux distributions you will need to install the `binutils` package:

[source, bash]
----
# dnf (rpm-based)
sudo dnf install binutils
# Debian-based distributions
sudo apt-get install binutils
----

`objcopy` が利用できない場合、デバッグシンボルが実行ファイルに埋め込まれています。
====

デバッグシンボルとは別に、 `-Dquarkus.native.debug.enabled=true` フラグを設定すると、ネイティブ実行可能ファイル生成時に解決された JDK ランタイムクラス、GraalVM クラス、アプリケーションクラスのソースファイルのキャッシュが生成されます。このソースキャッシュは、シンボルと一致するソースコード間のリンクを確立するために、ネイティブデバッグツールにとって有用です。ネイティブ実行可能ファイルをデバッグする際に、必要なソースだけをデバッガー/IDEが利用できるようにする便利な方法を提供します。

Quarkusのソースコードを含むサードパーティのjar依存関係のソースは、デフォルトではソースキャッシュに追加されません。これらを含めるには、まず `mvn dependency:sources` を起動してください。このステップは、これらの依存関係のソースを引き出し、ソースキャッシュに含めるために必要です。

ソースキャッシュは `target/sources` フォルダーにあります。

[TIP]
====
`gdb` を `target` とは異なるディレクトリーから実行している場合、ソースは以下を

[source, bash]
----
directory path/to/target
----

 `gdb` プロンプトで実行することで読み込まれます。

または、 `gdb` を以下のように起動してください:

[source, bash]
----
gdb -ex 'directory path/to/target' path/to/target/{project.name}-{project.version}-runner
----

例えば
[source, bash]
----
gdb -ex 'directory ./target' ./target/getting-started-1.0.0-SNAPSHOT-runner
----
====

For a more detailed guide about debugging native images please refer to the xref:native-reference.adoc[Native Reference Guide].

[[configuration-reference]]
== ネイティブ実行可能ファイルの設定

ネイティブ実行可能ファイルの生成方法に影響を与える設定オプションがたくさんあります。これらは他の設定プロパティーと同じように `application.properties` で提供されています。

プロパティーは以下の通りです:


:summaryTableId: quarkus-native-pkg-native-config
[.configuration-legend]
icon:lock[title=ビルド時に固定] ビルド時に固定される設定プロパティ - それ以外の設定プロパティは実行時に上書き可能
[.configuration-reference, cols="80,.^10,.^10"]
|===

h|[[quarkus-native-pkg-native-config_configuration]]link:#quarkus-native-pkg-native-config_configuration[Configuration property]

h|タイプ
h|デフォルト

a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.additional-build-args]]`link:#quarkus-native-pkg-native-config_quarkus.native.additional-build-args[quarkus.native.additional-build-args]`

[.description]
--
Comma-separated, additional arguments to pass to the build process. If an argument includes the `,` symbol, it needs to be escaped, e.g. `++\\++,`

Environment variable: `+++QUARKUS_NATIVE_ADDITIONAL_BUILD_ARGS+++`
--|list of string
|


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.enable-http-url-handler]]`link:#quarkus-native-pkg-native-config_quarkus.native.enable-http-url-handler[quarkus.native.enable-http-url-handler]`

[.description]
--
If the HTTP url handler should be enabled, allowing you to do URL.openConnection() for HTTP URLs

Environment variable: `+++QUARKUS_NATIVE_ENABLE_HTTP_URL_HANDLER+++`
--|boolean
|`true`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.enable-https-url-handler]]`link:#quarkus-native-pkg-native-config_quarkus.native.enable-https-url-handler[quarkus.native.enable-https-url-handler]`

[.description]
--
If the HTTPS url handler should be enabled, allowing you to do URL.openConnection() for HTTPS URLs

Environment variable: `+++QUARKUS_NATIVE_ENABLE_HTTPS_URL_HANDLER+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.inline-before-analysis]]`link:#quarkus-native-pkg-native-config_quarkus.native.inline-before-analysis[quarkus.native.inline-before-analysis]`

[.description]
--
If `-H:{plus}InlineBeforeAnalysis` flag will be added to the native-image run

Environment variable: `+++QUARKUS_NATIVE_INLINE_BEFORE_ANALYSIS+++`
--|boolean
|`true`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.headless]]`link:#quarkus-native-pkg-native-config_quarkus.native.headless[quarkus.native.headless]`

[.description]
--
The default value for java.awt.headless JVM option. Switching this option affects linking of awt libraries.

Environment variable: `+++QUARKUS_NATIVE_HEADLESS+++`
--|boolean
|`true`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.file-encoding]]`link:#quarkus-native-pkg-native-config_quarkus.native.file-encoding[quarkus.native.file-encoding]`

[.description]
--
Defines the file encoding as in `-Dfile.encoding=...`. Native image runtime uses the host's (i.e. build time) value of `file.encoding` system property. We intentionally default this to UTF-8 to avoid platform specific defaults to be picked up which can then result in inconsistent behavior in the generated native executable.

Environment variable: `+++QUARKUS_NATIVE_FILE_ENCODING+++`
--|string
|`UTF-8`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.add-all-charsets]]`link:#quarkus-native-pkg-native-config_quarkus.native.add-all-charsets[quarkus.native.add-all-charsets]`

[.description]
--
If all character sets should be added to the native image. This increases image size

Environment variable: `+++QUARKUS_NATIVE_ADD_ALL_CHARSETS+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.graalvm-home]]`link:#quarkus-native-pkg-native-config_quarkus.native.graalvm-home[quarkus.native.graalvm-home]`

[.description]
--
The location of the Graal distribution

Environment variable: `+++QUARKUS_NATIVE_GRAALVM_HOME+++`
--|string
|`${GRAALVM_HOME:}`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.java-home]]`link:#quarkus-native-pkg-native-config_quarkus.native.java-home[quarkus.native.java-home]`

[.description]
--
The location of the JDK

Environment variable: `+++QUARKUS_NATIVE_JAVA_HOME+++`
--|link:https://docs.oracle.com/javase/8/docs/api/java/io/File.html[File]

|`${java.home}`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.native-image-xmx]]`link:#quarkus-native-pkg-native-config_quarkus.native.native-image-xmx[quarkus.native.native-image-xmx]`

[.description]
--
The maximum Java heap to be used during the native image generation

Environment variable: `+++QUARKUS_NATIVE_NATIVE_IMAGE_XMX+++`
--|string
|


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.debug-build-process]]`link:#quarkus-native-pkg-native-config_quarkus.native.debug-build-process[quarkus.native.debug-build-process]`

[.description]
--
If the native image build should wait for a debugger to be attached before running. This is an advanced option and is generally only intended for those familiar with GraalVM internals

Environment variable: `+++QUARKUS_NATIVE_DEBUG_BUILD_PROCESS+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.publish-debug-build-process-port]]`link:#quarkus-native-pkg-native-config_quarkus.native.publish-debug-build-process-port[quarkus.native.publish-debug-build-process-port]`

[.description]
--
If the debug port should be published when building with docker and debug-build-process is true

Environment variable: `+++QUARKUS_NATIVE_PUBLISH_DEBUG_BUILD_PROCESS_PORT+++`
--|boolean
|`true`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.enable-isolates]]`link:#quarkus-native-pkg-native-config_quarkus.native.enable-isolates[quarkus.native.enable-isolates]`

[.description]
--
If isolates should be enabled

Environment variable: `+++QUARKUS_NATIVE_ENABLE_ISOLATES+++`
--|boolean
|`true`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.enable-fallback-images]]`link:#quarkus-native-pkg-native-config_quarkus.native.enable-fallback-images[quarkus.native.enable-fallback-images]`

[.description]
--
If a JVM based 'fallback image' should be created if native image fails. This is not recommended, as this is functionally the same as just running the application in a JVM

Environment variable: `+++QUARKUS_NATIVE_ENABLE_FALLBACK_IMAGES+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.auto-service-loader-registration]]`link:#quarkus-native-pkg-native-config_quarkus.native.auto-service-loader-registration[quarkus.native.auto-service-loader-registration]`

[.description]
--
If all META-INF/services entries should be automatically registered

Environment variable: `+++QUARKUS_NATIVE_AUTO_SERVICE_LOADER_REGISTRATION+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.dump-proxies]]`link:#quarkus-native-pkg-native-config_quarkus.native.dump-proxies[quarkus.native.dump-proxies]`

[.description]
--
If the bytecode of all proxies should be dumped for inspection

Environment variable: `+++QUARKUS_NATIVE_DUMP_PROXIES+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.container-build]]`link:#quarkus-native-pkg-native-config_quarkus.native.container-build[quarkus.native.container-build]`

[.description]
--
If this build should be done using a container runtime. Unless container-runtime is also set, docker will be used by default. If docker is not available or is an alias to podman, podman will be used instead as the default.

Environment variable: `+++QUARKUS_NATIVE_CONTAINER_BUILD+++`
--|boolean
|


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.remote-container-build]]`link:#quarkus-native-pkg-native-config_quarkus.native.remote-container-build[quarkus.native.remote-container-build]`

[.description]
--
If this build is done using a remote docker daemon.

Environment variable: `+++QUARKUS_NATIVE_REMOTE_CONTAINER_BUILD+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.builder-image]]`link:#quarkus-native-pkg-native-config_quarkus.native.builder-image[quarkus.native.builder-image]`

[.description]
--
The docker image to use to do the image build. It can be one of `graalvm`, `mandrel`, or the full image path, e.g. `quay.io/quarkus/ubi-quarkus-mandrel:21.3-java17`.

Environment variable: `+++QUARKUS_NATIVE_BUILDER_IMAGE+++`
--|string
|`${platform.quarkus.native.builder-image}`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.container-runtime]]`link:#quarkus-native-pkg-native-config_quarkus.native.container-runtime[quarkus.native.container-runtime]`

[.description]
--
The container runtime (e.g. docker) that is used to do an image based build. If this is set then a container build is always done.

Environment variable: `+++QUARKUS_NATIVE_CONTAINER_RUNTIME+++`
-- a|
`docker`, `podman`
|


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.container-runtime-options]]`link:#quarkus-native-pkg-native-config_quarkus.native.container-runtime-options[quarkus.native.container-runtime-options]`

[.description]
--
Options to pass to the container runtime

Environment variable: `+++QUARKUS_NATIVE_CONTAINER_RUNTIME_OPTIONS+++`
--|list of string
|


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.enable-vm-inspection]]`link:#quarkus-native-pkg-native-config_quarkus.native.enable-vm-inspection[quarkus.native.enable-vm-inspection]`

[.description]
--
If the resulting image should allow VM introspection

Environment variable: `+++QUARKUS_NATIVE_ENABLE_VM_INSPECTION+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.full-stack-traces]]`link:#quarkus-native-pkg-native-config_quarkus.native.full-stack-traces[quarkus.native.full-stack-traces]`

[.description]
--
If full stack traces are enabled in the resulting image

Environment variable: `+++QUARKUS_NATIVE_FULL_STACK_TRACES+++`
--|boolean
|`true`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.enable-reports]]`link:#quarkus-native-pkg-native-config_quarkus.native.enable-reports[quarkus.native.enable-reports]`

[.description]
--
If the reports on call paths and included packages/classes/methods should be generated

Environment variable: `+++QUARKUS_NATIVE_ENABLE_REPORTS+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.report-exception-stack-traces]]`link:#quarkus-native-pkg-native-config_quarkus.native.report-exception-stack-traces[quarkus.native.report-exception-stack-traces]`

[.description]
--
If exceptions should be reported with a full stack trace

Environment variable: `+++QUARKUS_NATIVE_REPORT_EXCEPTION_STACK_TRACES+++`
--|boolean
|`true`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.report-errors-at-runtime]]`link:#quarkus-native-pkg-native-config_quarkus.native.report-errors-at-runtime[quarkus.native.report-errors-at-runtime]`

[.description]
--
If errors should be reported at runtime. This is a more relaxed setting, however it is not recommended as it means your application may fail at runtime if an unsupported feature is used by accident.

Environment variable: `+++QUARKUS_NATIVE_REPORT_ERRORS_AT_RUNTIME+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.reuse-existing]]`link:#quarkus-native-pkg-native-config_quarkus.native.reuse-existing[quarkus.native.reuse-existing]`

[.description]
--
Don't build a native image if it already exists. This is useful if you have already built an image and you want to use Quarkus to deploy it somewhere. Note that this is not able to detect if the existing image is outdated, if you have modified source or config and want a new image you must not use this flag.

Environment variable: `+++QUARKUS_NATIVE_REUSE_EXISTING+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.resources.includes]]`link:#quarkus-native-pkg-native-config_quarkus.native.resources.includes[quarkus.native.resources.includes]`

[.description]
--
A comma separated list of globs to match resource paths that should be added to the native image.
 Use slash (`/`) as a path separator on all platforms. Globs must not start with slash.
 By default, no resources are included.
 Example: Given that you have `src/main/resources/ignored.png` and `src/main/resources/foo/selected.png` in your source tree and one of your dependency JARs contains `bar/some.txt` file, with the following configuration quarkus.native.resources.includes = foo/++**++,bar/++**++/++*++.txt  the files `src/main/resources/foo/selected.png` and `bar/some.txt` will be included in the native image, while `src/main/resources/ignored.png` will not be included.
 Supported glob features   Feature Description   `++*++` Matches a (possibly empty) sequence of characters that does not contain slash (`/`)   `++**++` Matches a (possibly empty) sequence of characters that may contain slash (`/`)   `?` Matches one character, but not slash   `++[++abc++]++` Matches one character given in the bracket, but not slash   `++[++a-z++]++` Matches one character from the range given in the bracket, but not slash   `++[++!abc++]++` Matches one character not named in the bracket; does not match slash   `++[++a-z++]++` Matches one character outside the range given in the bracket; does not match slash   `++{++one,two,three++}++` Matches any of the alternating tokens separated by comma; the tokens may contain wildcards, nested alternations and ranges   `++\++` The escape character
 Note that there are three levels of escaping when passing this option via `application.properties`:
 . `application.properties` parser
 - MicroProfile Config list converter that splits the comma separated list
 - Glob parser  All three levels use backslash (`++\++`) as the escaping character. So you need to use an appropriate number of backslashes depending on which level you want to escape.
 Note that Quarkus extensions typically include the resources they require by themselves. This option is useful in situations when the built-in functionality is not sufficient.

Environment variable: `+++QUARKUS_NATIVE_RESOURCES_INCLUDES+++`
--|list of string
|


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.resources.excludes]]`link:#quarkus-native-pkg-native-config_quarkus.native.resources.excludes[quarkus.native.resources.excludes]`

[.description]
--
A comma separated list of globs to match resource paths that should *not* be added to the native image.
 Use slash (`/`) as a path separator on all platforms. Globs must not start with slash.
 Please refer to `includes` for details about the glob syntax.
 By default, no resources are excluded.
 Example: Given that you have `src/main/resources/red.png` and `src/main/resources/foo/green.png` in your source tree and one of your dependency JARs contains `bar/blue.png` file, with the following configuration quarkus.native.resources.includes = ++**++/++*++.png quarkus.native.resources.excludes = foo/++**++,++**++/green.png  the resource `red.png` will be available in the native image while the resources `foo/green.png` and `bar/blue.png` will not be available in the native image.

Environment variable: `+++QUARKUS_NATIVE_RESOURCES_EXCLUDES+++`
--|list of string
|


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.debug.enabled]]`link:#quarkus-native-pkg-native-config_quarkus.native.debug.enabled[quarkus.native.debug.enabled]`

[.description]
--
If debug is enabled and debug symbols are generated. The symbols will be generated in a separate .debug file.

Environment variable: `+++QUARKUS_NATIVE_DEBUG_ENABLED+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.enable-dashboard-dump]]`link:#quarkus-native-pkg-native-config_quarkus.native.enable-dashboard-dump[quarkus.native.enable-dashboard-dump]`

[.description]
--
Generate the report files for GraalVM Dashboard.

Environment variable: `+++QUARKUS_NATIVE_ENABLE_DASHBOARD_DUMP+++`
--|boolean
|`false`


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.compression.level]]`link:#quarkus-native-pkg-native-config_quarkus.native.compression.level[quarkus.native.compression.level]`

[.description]
--
The compression level in ++[++1, 10++]++. 10 means *best* Higher compression level requires more time to compress the executable.

Environment variable: `+++QUARKUS_NATIVE_COMPRESSION_LEVEL+++`
--|int
|


a|icon:lock[title=Fixed at build time] [[quarkus-native-pkg-native-config_quarkus.native.compression.additional-args]]`link:#quarkus-native-pkg-native-config_quarkus.native.compression.additional-args[quarkus.native.compression.additional-args]`

[.description]
--
Allows passing extra arguments to the UPX command line (like --brute). The arguments are comma-separated. The exhaustive list of parameters can be found in link:https://github.com/upx/upx/blob/devel/doc/upx.pod[https://github.com/upx/upx/blob/devel/doc/upx.pod].

Environment variable: `+++QUARKUS_NATIVE_COMPRESSION_ADDITIONAL_ARGS+++`
--|list of string
|

|===

== 次のステップ

このガイドでは、アプリケーション用のネイティブ(バイナリー)実行ファイルの作成について説明しました。これにより、迅速な起動時間と少ないメモリー消費を示すアプリケーションを提供します。しかし、それだけではありません。

We recommend continuing the journey with the xref:deploying-to-kubernetes.adoc[deployment to Kubernetes and OpenShift].