By Version

Imágenes de contenedores

Extensiones de la imagen del contenedor
- Jib
- Docker
- OpenShift
- Buildpack
Construcción
Using @QuarkusIntegrationTest
Subiendo
Seleccionar entre varias extensiones
Integrating with systemd-notify
Personalizar

Quarkus provides extensions for building (and pushing) container images. Currently, it supports:

Jib
Docker
OpenShift
Buildpack

Extensiones de la imagen del contenedor

Jib

La extensión quarkus-container-image-jib es impulsada por Jib para realizar construcciones de imágenes de contenedores. El mayor beneficio de usar Jib con Quarkus es que todas las dependencias (todo lo que se encuentra en target/lib) se almacenan en caché en una capa diferente a la de la aplicación real, haciendo que las reconstrucciones sean realmente rápidas y pequeñas (cuando se trata de subir). Otro beneficio importante de usar esta extensión es que proporciona la capacidad de crear una imagen de contenedor sin tener que tener ninguna herramienta dedicada del lado del cliente (como Docker) o ejecutar procesos de demonio (como el demonio Docker) cuando todo lo que se necesita es la capacidad de subir a un registro de imagen de contenedor.

Para utilizar esta función, añada la siguiente extensión a su proyecto:

CLI

quarkus extension add 'container-image-jib'

Maven

./mvnw quarkus:add-extension -Dextensions='container-image-jib'

Gradle

./gradlew addExtension --extensions='container-image-jib'

En situaciones en las que todo lo que se necesita para construir una imagen de contenedor y no es necesario empujar a un registro (esencialmente por haber establecido quarkus.container-image.build=true y dejado quarkus.container-image.push sin establecer - por defecto es false), entonces esta extensión crea una imagen de contenedor y la registra con el demonio Docker. Esto significa que aunque Docker no se utiliza para construir la imagen, es sin embargo necesario. También hay que tener en cuenta que usando este modo, la imagen de contenedor construida aparecerá cuando se ejecute docker images.

Inclusión de archivos adicionales

Hay casos en los que es necesario añadir archivos adicionales (distintos de los producidos por la construcción de Quarkus) a una imagen de contenedor. Para soportar estos casos, Quarkus copia cualquier archivo bajo src/main/jib en la imagen de contenedor construida (que es esencialmente la misma idea que soportan los plugins Jib Maven y Gradle). Por ejemplo, la presencia de src/main/jib/foo/bar haría que se añadiera /foo/bar al sistema de archivos del contenedor.

Depuración de la JVM

Hay casos en los que la imagen del contenedor construido puede necesitar tener la depuración de Java condicionada en tiempo de ejecución.

When the base image has not been changed (and therefore ubi8/openjdk-11-runtime or ubi8/openjdk-17-runtime is used), then the quarkus.jib.jvm-arguments configuration property can be used in order to make the JVM listen on the debug port at startup.

La configuración exacta es:

quarkus.jib.jvm-arguments=-agentlib:jdwp=transport=dt_socket\\,server=y\\,suspend=n\\,address=*:5005

Otras imágenes base pueden proporcionar scripts de lanzamiento que permiten la depuración cuando se establece una variable de entorno, en cuyo caso se establecería esa variable de entorno al lanzar el contenedor.

Custom Entrypoint

The quarkus.jib.jvm-entrypoint configuration property can be used to completely override the container entry point and can thus be used to either hard code the JVM debug configuration or point to a script that handles the details.

For example, if the base images ubi8/openjdk-11-runtime or ubi8/openjdk-17-runtime are used to build the container, the entry point can be hard-coded on the application properties file.

Example application.properties

quarkus.jib.jvm-entrypoint=java,-Dcustom.param=custom_value,-jar,quarkus-run.jar

Or a custom start-up script can be created and referenced on the properties file. This approach works better if there’s a need to set application params using environment variables:

Example application.properties

quarkus.jib.jvm-entrypoint=/bin/sh,run-java.sh

Example src/main/jib/home/jboss/run-java.sh

java \
  -Djavax.net.ssl.trustStore=/deployments/truststore \
  -Djavax.net.ssl.trustStorePassword="$TRUST_STORE_PASSWORD" \
  -jar quarkus-run.jar

/home/jboss is the WORKDIR for all quarkus binaries in the base images ubi8/openjdk-11-runtime and ubi8/openjdk-17-runtime (Dockerfile for ubi8/openjdk-17-runtime)

Multi-module projects and layering

When building a multi-module project containing a Quarkus application as one module and various supporting project dependencies as other modules, Quarkus supports placing these supporting modules in a separate container image layer from the rest of the application dependencies, with the expectation that these supporting modules will change more frequently than the regular application dependencies - thus making a rebuild faster if the application dependencies have not changed.

To enable this feature, the property quarkus.bootstrap.workspace-discovery needs to be set to true either as a system property when invoking the build tool, either as a build tool property. Setting this property in application.properties will not work because this property needs to be known very early on in the build process.

AppCDS

Quarkus supports generating and including an Application Class Data Sharing archive when generating a container image using Jib. See the AppCDS documentation for more details.

Docker

La extensión quarkus-container-image-docker utiliza el binario Docker y los archivos Docker generados bajo src/main/docker para realizar las construcciones Docker.

Para utilizar esta función, añada la siguiente extensión a su proyecto.

CLI

quarkus extension add 'container-image-docker'

Maven

./mvnw quarkus:add-extension -Dextensions='container-image-docker'

Gradle

./gradlew addExtension --extensions='container-image-docker'

The quarkus-container-image-docker extension is capable of creating multi-platform (or multi-arch) images using docker buildx build. See the quarkus.docker.buildx.* configuration items in the Docker Options section below.

docker buildx build ONLY supports loading the result of a build to docker images when building for a single platform. Therefore, if you specify more than one argument in the quarkus.docker.buildx.platform property, the resulting images will not be loaded into docker images. If quarkus.docker.buildx.platform is omitted or if only a single platform is specified, it will then be loaded into docker images.

OpenShift

The extension quarkus-container-image-openshift is using OpenShift binary builds in order to perform container builds inside the OpenShift cluster. The idea behind the binary build is that you just upload the artifact and its dependencies to the cluster and during the build they will be merged to a builder image (defaults to fabric8/s2i-java).

La ventaja de este enfoque es que puede combinarse con el sitio web de OpenShift DeploymentConfig, que facilita la introducción de cambios en el clúster.

Para utilizar esta función, añada la siguiente extensión a su proyecto.

CLI

quarkus extension add 'container-image-openshift'

Maven

./mvnw quarkus:add-extension -Dextensions='container-image-openshift'

Gradle

./gradlew addExtension --extensions='container-image-openshift'

OpenShift builds require creating a BuildConfig and two ImageStream resources, one for the builder image and one for the output image. The creation of such objects is being taken care of by the Quarkus Kubernetes extension.

Buildpack

La extensión quarkus-container-image-buildpack utiliza buildpacks para realizar la construcción de imágenes de contenedores. Bajo el capó, los buildpacks utilizarán un demonio Docker para la construcción real. Mientras que los buildpacks soportan alternativas a Docker, esta extensión sólo funcionará con Docker.

Además, el usuario tendrá que configurar qué imagen de compilación utilizar (no se proporciona ninguna imagen por defecto). Por ejemplo:

quarkus.buildpack.jvm-builder-image=<jvm builder image>

o para los nativos:

quarkus.buildpack.native-builder-image=<native builder image>

Para utilizar esta función, añada la siguiente extensión a su proyecto.

CLI

quarkus extension add 'container-image-buildpack'

Maven

./mvnw quarkus:add-extension -Dextensions='container-image-buildpack'

Gradle

./gradlew addExtension --extensions='container-image-buildpack'

Cuando se utiliza la extensión de la imagen del contenedor buildpack se recomienda encarecidamente evitar añadir quarkus.container-image.build=true en la configuración de las propiedades, ya que podría desencadenar construcciones anidadas dentro de otras. Es preferible pasarla como una opción al comando de construcción.

Construcción

Para construir una imagen de contenedor para su proyecto, quarkus.container-image.build=true necesita ser configurado usando cualquiera de las formas que Quarkus soporta.

CLI

quarkus build -Dquarkus.container-image.build=true

Maven

./mvnw install -Dquarkus.container-image.build=true

Gradle

./gradlew build -Dquarkus.container-image.build=true

Si alguna vez quiere construir una imagen de contenedor nativo y ya tiene una imagen nativa existente, puede establecer -Dquarkus.native.reuse-existing=true y la construcción de la imagen nativa no se volverá a ejecutar.

Using @QuarkusIntegrationTest

To run tests on the resulting image, quarkus.container-image.build=true needs to be set using any of the ways that Quarkus supports.

Maven

./mvnw verify -Dquarkus.container-image.build=true

Gradle

./gradlew quarkusIntTest -Dquarkus.container-image.build=true

Subiendo

Para subir una imagen de contenedor para su proyecto, quarkus.container-image.push=true necesita ser establecido usando cualquiera de las formas que Quarkus soporta.

CLI

quarkus build -Dquarkus.container-image.push=true

Maven

./mvnw install -Dquarkus.container-image.push=true

Gradle

./gradlew build -Dquarkus.container-image.push=true

Si no se establece ningún registro (utilizando quarkus.container-image.registry), se utilizará docker.io por defecto.

Seleccionar entre varias extensiones

No tiene sentido utilizar varias extensiones como parte de la misma construcción. Cuando haya varias extensiones de imagen de contenedor, se producirá un error para informar al usuario. El usuario puede eliminar las extensiones innecesarias o seleccionar una utilizando application.properties.

For example, if both container-image-docker and container-image-openshift are present and the user needs to use container-image-docker:

quarkus.container-image.builder=docker

Integrating with `systemd-notify`

If you are building a container image in order to deploy your Quarkus application as a Linux service with Podman and Systemd, you might want to consider including the Quarkus Systemd Notify Extension as part of your application, with:

CLI

quarkus extension add 'io.quarkiverse.systemd.notify:quarkus-systemd-notify'

Maven

./mvnw quarkus:add-extension -Dextensions='io.quarkiverse.systemd.notify:quarkus-systemd-notify'

Gradle

./gradlew addExtension --extensions='io.quarkiverse.systemd.notify:quarkus-systemd-notify'

Personalizar

Las siguientes propiedades pueden utilizarse para personalizar el proceso de construcción de la imagen del contenedor.

Opciones de imagen del contenedor

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property	Type	Default
`quarkus.container-image.group` The group the container image will be part of Environment variable: `QUARKUS_CONTAINER_IMAGE_GROUP` Show more	string
`quarkus.container-image.name` The name of the container image. If not set defaults to the application name Environment variable: `QUARKUS_CONTAINER_IMAGE_NAME` Show more	string	`${quarkus.application.name:unset}`
`quarkus.container-image.tag` The tag of the container image. If not set defaults to the application version Environment variable: `QUARKUS_CONTAINER_IMAGE_TAG` Show more	string	`${quarkus.application.version:latest}`
`quarkus.container-image.additional-tags` Additional tags of the container image. Environment variable: `QUARKUS_CONTAINER_IMAGE_ADDITIONAL_TAGS` Show more	list of string
`quarkus.container-image.registry` The container registry to use Environment variable: `QUARKUS_CONTAINER_IMAGE_REGISTRY` Show more	string
`quarkus.container-image.image` Represents the entire image string. If set, then `group`, `name`, `registry`, `tags`, `additionalTags` are ignored Environment variable: `QUARKUS_CONTAINER_IMAGE_IMAGE` Show more	string
`quarkus.container-image.username` The username to use to authenticate with the registry where the built image will be pushed Environment variable: `QUARKUS_CONTAINER_IMAGE_USERNAME` Show more	string
`quarkus.container-image.password` The password to use to authenticate with the registry where the built image will be pushed Environment variable: `QUARKUS_CONTAINER_IMAGE_PASSWORD` Show more	string
`quarkus.container-image.insecure` Whether or not insecure registries are allowed Environment variable: `QUARKUS_CONTAINER_IMAGE_INSECURE` Show more	boolean	`false`
`quarkus.container-image.build` Whether or not a image build will be performed. Environment variable: `QUARKUS_CONTAINER_IMAGE_BUILD` Show more	boolean
`quarkus.container-image.push` Whether or not an image push will be performed. Environment variable: `QUARKUS_CONTAINER_IMAGE_PUSH` Show more	boolean
`quarkus.container-image.builder` The name of the container image extension to use (e.g. docker, jib, s2i). The option will be used in case multiple extensions are present. Environment variable: `QUARKUS_CONTAINER_IMAGE_BUILDER` Show more	string
`quarkus.container-image.labels` Custom labels to add to the generated image. Environment variable: `QUARKUS_CONTAINER_IMAGE_LABELS` Show more	`Map<String,String>`

Configuration property

Type

Default

quarkus.container-image.group

The group the container image will be part of

Environment variable: QUARKUS_CONTAINER_IMAGE_GROUP

string

quarkus.container-image.name

The name of the container image. If not set defaults to the application name

Environment variable: QUARKUS_CONTAINER_IMAGE_NAME

string

${quarkus.application.name:unset}

quarkus.container-image.tag

The tag of the container image. If not set defaults to the application version

Environment variable: QUARKUS_CONTAINER_IMAGE_TAG

string

${quarkus.application.version:latest}

quarkus.container-image.additional-tags

Additional tags of the container image.

Environment variable: QUARKUS_CONTAINER_IMAGE_ADDITIONAL_TAGS

list of string

quarkus.container-image.registry

The container registry to use

Environment variable: QUARKUS_CONTAINER_IMAGE_REGISTRY

string

quarkus.container-image.image

Represents the entire image string. If set, then group, name, registry, tags, additionalTags are ignored

Environment variable: QUARKUS_CONTAINER_IMAGE_IMAGE

string

quarkus.container-image.username

The username to use to authenticate with the registry where the built image will be pushed

Environment variable: QUARKUS_CONTAINER_IMAGE_USERNAME

string

quarkus.container-image.password

The password to use to authenticate with the registry where the built image will be pushed

Environment variable: QUARKUS_CONTAINER_IMAGE_PASSWORD

string

quarkus.container-image.insecure

Whether or not insecure registries are allowed

Environment variable: QUARKUS_CONTAINER_IMAGE_INSECURE

boolean

false

quarkus.container-image.build

Whether or not a image build will be performed.

Environment variable: QUARKUS_CONTAINER_IMAGE_BUILD

boolean

quarkus.container-image.push

Whether or not an image push will be performed.

Environment variable: QUARKUS_CONTAINER_IMAGE_PUSH

boolean

quarkus.container-image.builder

The name of the container image extension to use (e.g. docker, jib, s2i). The option will be used in case multiple extensions are present.

Environment variable: QUARKUS_CONTAINER_IMAGE_BUILDER

string

quarkus.container-image.labels

Custom labels to add to the generated image.

Environment variable: QUARKUS_CONTAINER_IMAGE_LABELS

Map<String,String>

Uso de entornos de IC

Varios entornos de CI proporcionan un registro de imagen de contenedor listo para usar que puede combinarse con las extensiones de Quarkus de imagen de contenedor para crear y empujar sin esfuerzo una aplicación de Quarkus a dicho registro.

Por ejemplo, GitLab proporciona un registro de este tipo y en el entorno de CI proporcionado, pone a disposición la variable de entorno CI_REGISTRY_IMAGE (véase la documentación de GitLab) para obtener más información), que se puede utilizar en Quarkus de esta manera:

quarkus.container-image.image=${CI_REGISTRY_IMAGE}

See this for more information on how to combine properties with environment variables.

Opciones de pluma

Además de las opciones genéricas de la imagen del contenedor, container-image-jib también proporciona las siguientes opciones:

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property	Type	Default
`quarkus.jib.base-jvm-image` The base image to be used when a container image is being produced for the jar build. When the application is built against Java 17 or higher, `registry.access.redhat.com/ubi8/openjdk-17-runtime:1.16` is used as the default. Otherwise `registry.access.redhat.com/ubi8/openjdk-11-runtime:1.16` is used as the default. Environment variable: `QUARKUS_JIB_BASE_JVM_IMAGE` Show more	string
`quarkus.jib.base-native-image` The base image to be used when a container image is being produced for the native binary build. The default is "quay.io/quarkus/quarkus-micro-image". You can also use "registry.access.redhat.com/ubi8/ubi-minimal" which is a bigger base image, but provide more built-in utilities such as the microdnf package manager. Environment variable: `QUARKUS_JIB_BASE_NATIVE_IMAGE` Show more	string	`quay.io/quarkus/quarkus-micro-image:2.0`
`quarkus.jib.jvm-arguments` The JVM arguments to pass to the JVM when starting the application Environment variable: `QUARKUS_JIB_JVM_ARGUMENTS` Show more	list of string	`-Djava.util.logging.manager=org.jboss.logmanager.LogManager`
`quarkus.jib.jvm-additional-arguments` Additional JVM arguments to pass to the JVM when starting the application Environment variable: `QUARKUS_JIB_JVM_ADDITIONAL_ARGUMENTS` Show more	list of string
`quarkus.jib.native-arguments` Additional arguments to pass when starting the native application Environment variable: `QUARKUS_JIB_NATIVE_ARGUMENTS` Show more	list of string
`quarkus.jib.jvm-entrypoint` If this is set, then it will be used as the entry point of the container image. There are a few things to be aware of when creating an entry point Entrypoint "INHERIT" means to inherit entrypoint from base image, `jvmArguments` field is used for arguments A valid entrypoint is jar package specific (see `quarkus.package.type`) A valid entrypoint depends on the location of both the launching scripts and the application jar file. To that end it’s helpful to remember that when `fast-jar` packaging is used (the default), all necessary application jars are added to the `/work` directory and that the same directory is also used as the working directory. When `legacy-jar` or `uber-jar` are used, the application jars are unpacked under the `/app` directory and that directory is used as the working directory. Even if the `jvmArguments` field is set, it is ignored completely unless entrypoint is "INHERIT" When this is not set, a proper default entrypoint will be constructed. As a final note, a very useful tool for inspecting container image layers that can greatly aid when debugging problems with endpoints is dive Environment variable: `QUARKUS_JIB_JVM_ENTRYPOINT` Show more	list of string
`quarkus.jib.native-entrypoint` If this is set, then it will be used as the entry point of the container image. There are a few things to be aware of when creating an entry point Entrypoint "INHERIT" means to inherit entrypoint from base image, `nativeArguments` field is used for arguments A valid entrypoint depends on the location of both the launching scripts and the native binary file. To that end it’s helpful to remember that the native application is added to the `/work` directory and that and the same directory is also used as the working directory Even if the `nativeArguments` field is set, it is ignored completely unless entrypoint is "INHERIT" When this is not set, a proper default entrypoint will be constructed. As a final note, a very useful tool for inspecting container image layers that can greatly aid when debugging problems with endpoints is dive Environment variable: `QUARKUS_JIB_NATIVE_ENTRYPOINT` Show more	list of string
`quarkus.jib.base-registry-username` The username to use to authenticate with the registry used to pull the base JVM image Environment variable: `QUARKUS_JIB_BASE_REGISTRY_USERNAME` Show more	string
`quarkus.jib.base-registry-password` The password to use to authenticate with the registry used to pull the base JVM image Environment variable: `QUARKUS_JIB_BASE_REGISTRY_PASSWORD` Show more	string
`quarkus.jib.ports` The ports to expose Environment variable: `QUARKUS_JIB_PORTS` Show more	list of int	`${quarkus.http.port:8080}`
`quarkus.jib.user` The user to use in generated image Environment variable: `QUARKUS_JIB_USER` Show more	string
`quarkus.jib.working-directory` The working directory to use in the generated image. The default value is chosen to work in accordance with the default base image. Environment variable: `QUARKUS_JIB_WORKING_DIRECTORY` Show more	string	`/home/jboss`
`quarkus.jib.always-cache-base-image` Controls the optimization which skips downloading base image layers that exist in a target registry. If the user does not set this property, then read as false. If `true`, base image layers are always pulled and cached. If `false`, base image layers will not be pulled/cached if they already exist on the target registry. Environment variable: `QUARKUS_JIB_ALWAYS_CACHE_BASE_IMAGE` Show more	boolean	`false`
`quarkus.jib.platforms` List of target platforms. Each platform is defined using the pattern: `<os>\|<arch>[/variant]\|<os>/<arch>[/variant]` for example: `linux/amd64,linux/arm64/v8` If not specified, OS default is linux and architecture default is `amd64`. If more than one platform is configured, it is important to note that the base image has to be a Docker manifest or an OCI image index containing a version of each chosen platform. The feature does not work with native images, as cross-compilation is not supported. This configuration is based on an incubating feature of Jib. See Jib FAQ for more information. Environment variable: `QUARKUS_JIB_PLATFORMS` Show more	list of string
`quarkus.jib.image-digest-file` The path of a file in which the digest of the generated image will be written. If the path is relative, the base path is the output directory of the build tool. Environment variable: `QUARKUS_JIB_IMAGE_DIGEST_FILE` Show more	string	`jib-image.digest`
`quarkus.jib.image-id-file` The path of a file in which the id of the generated image will be written. If the path is relative, the base path is the output directory of the build tool. Environment variable: `QUARKUS_JIB_IMAGE_ID_FILE` Show more	string	`jib-image.id`
`quarkus.jib.offline-mode` Whether or not to operate offline. Environment variable: `QUARKUS_JIB_OFFLINE_MODE` Show more	boolean	`false`
`quarkus.jib.docker-executable-name` Name of binary used to execute the docker commands. This is only used by Jib when the container image is being built locally. Environment variable: `QUARKUS_JIB_DOCKER_EXECUTABLE_NAME` Show more	string
`quarkus.jib.use-current-timestamp` Whether to set the creation time to the actual build time. Otherwise, the creation time will be set to the Unix epoch (00:00:00, January 1st, 1970 in UTC). See Jib FAQ for more information Environment variable: `QUARKUS_JIB_USE_CURRENT_TIMESTAMP` Show more	boolean	`true`
`quarkus.jib.use-current-timestamp-file-modification` Whether to set the modification time (last modified time) of the files put by Jib in the image to the actual build time. Otherwise, the modification time will be set to the Unix epoch (00:00:00, January 1st, 1970 in UTC). If the modification time is constant (flag is set to false so Unix epoch is used) across two consecutive builds, the docker layer sha256 digest will be different only if the actual files added by Jib to the docker layer were changed. More exactly, having 2 consecutive builds will generate different docker layers only if the actual content of the files within the docker layer was changed. If the current timestamp is used the sha256 digest of the docker layer will always be different even if the content of the files didn’t change. Environment variable: `QUARKUS_JIB_USE_CURRENT_TIMESTAMP_FILE_MODIFICATION` Show more	boolean	`true`
`quarkus.jib.environment-variables` Environment variables to add to the container image Environment variable: `QUARKUS_JIB_ENVIRONMENT_VARIABLES` Show more	`Map<String,String>`
`quarkus.jib.docker-environment` Sets environment variables used by the Docker executable. This is only used by Jib when the container image is being built locally. Environment variable: `QUARKUS_JIB_DOCKER_ENVIRONMENT` Show more	`Map<String,String>`

Configuration property

Type

Default

quarkus.jib.base-jvm-image

The base image to be used when a container image is being produced for the jar build. When the application is built against Java 17 or higher, registry.access.redhat.com/ubi8/openjdk-17-runtime:1.16 is used as the default. Otherwise registry.access.redhat.com/ubi8/openjdk-11-runtime:1.16 is used as the default.

Environment variable: QUARKUS_JIB_BASE_JVM_IMAGE

string

quarkus.jib.base-native-image

The base image to be used when a container image is being produced for the native binary build. The default is "quay.io/quarkus/quarkus-micro-image". You can also use "registry.access.redhat.com/ubi8/ubi-minimal" which is a bigger base image, but provide more built-in utilities such as the microdnf package manager.

Environment variable: QUARKUS_JIB_BASE_NATIVE_IMAGE

string

quay.io/quarkus/quarkus-micro-image:2.0

quarkus.jib.jvm-arguments

The JVM arguments to pass to the JVM when starting the application

Environment variable: QUARKUS_JIB_JVM_ARGUMENTS

list of string

-Djava.util.logging.manager=org.jboss.logmanager.LogManager

quarkus.jib.jvm-additional-arguments

Additional JVM arguments to pass to the JVM when starting the application

Environment variable: QUARKUS_JIB_JVM_ADDITIONAL_ARGUMENTS

list of string

quarkus.jib.native-arguments

Additional arguments to pass when starting the native application

Environment variable: QUARKUS_JIB_NATIVE_ARGUMENTS

list of string

quarkus.jib.jvm-entrypoint

If this is set, then it will be used as the entry point of the container image. There are a few things to be aware of when creating an entry point

Entrypoint "INHERIT" means to inherit entrypoint from base image, jvmArguments field is used for arguments
A valid entrypoint is jar package specific (see quarkus.package.type)
A valid entrypoint depends on the location of both the launching scripts and the application jar file. To that end it’s helpful to remember that when fast-jar packaging is used (the default), all necessary application jars are added to the /work directory and that the same directory is also used as the working directory. When legacy-jar or uber-jar are used, the application jars are unpacked under the /app directory and that directory is used as the working directory.
Even if the jvmArguments field is set, it is ignored completely unless entrypoint is "INHERIT" When this is not set, a proper default entrypoint will be constructed. As a final note, a very useful tool for inspecting container image layers that can greatly aid when debugging problems with endpoints is dive

Environment variable: QUARKUS_JIB_JVM_ENTRYPOINT

list of string

quarkus.jib.native-entrypoint

If this is set, then it will be used as the entry point of the container image. There are a few things to be aware of when creating an entry point

Entrypoint "INHERIT" means to inherit entrypoint from base image, nativeArguments field is used for arguments
A valid entrypoint depends on the location of both the launching scripts and the native binary file. To that end it’s helpful to remember that the native application is added to the /work directory and that and the same directory is also used as the working directory
Even if the nativeArguments field is set, it is ignored completely unless entrypoint is "INHERIT" When this is not set, a proper default entrypoint will be constructed. As a final note, a very useful tool for inspecting container image layers that can greatly aid when debugging problems with endpoints is dive

Environment variable: QUARKUS_JIB_NATIVE_ENTRYPOINT

list of string

quarkus.jib.base-registry-username

The username to use to authenticate with the registry used to pull the base JVM image

Environment variable: QUARKUS_JIB_BASE_REGISTRY_USERNAME

string

quarkus.jib.base-registry-password

The password to use to authenticate with the registry used to pull the base JVM image

Environment variable: QUARKUS_JIB_BASE_REGISTRY_PASSWORD

string

quarkus.jib.ports

The ports to expose

Environment variable: QUARKUS_JIB_PORTS

list of int

${quarkus.http.port:8080}

quarkus.jib.user

The user to use in generated image

Environment variable: QUARKUS_JIB_USER

string

quarkus.jib.working-directory

The working directory to use in the generated image. The default value is chosen to work in accordance with the default base image.

Environment variable: QUARKUS_JIB_WORKING_DIRECTORY

string

/home/jboss

quarkus.jib.always-cache-base-image

Controls the optimization which skips downloading base image layers that exist in a target registry. If the user does not set this property, then read as false. If true, base image layers are always pulled and cached. If false, base image layers will not be pulled/cached if they already exist on the target registry.

Environment variable: QUARKUS_JIB_ALWAYS_CACHE_BASE_IMAGE

boolean

false

quarkus.jib.platforms

List of target platforms. Each platform is defined using the pattern:

<os>|<arch>[/variant]|<os>/<arch>[/variant]

for example:

linux/amd64,linux/arm64/v8

If not specified, OS default is linux and architecture default is amd64. If more than one platform is configured, it is important to note that the base image has to be a Docker manifest or an OCI image index containing a version of each chosen platform. The feature does not work with native images, as cross-compilation is not supported. This configuration is based on an incubating feature of Jib. See Jib FAQ for more information.

Environment variable: QUARKUS_JIB_PLATFORMS

list of string

quarkus.jib.image-digest-file

The path of a file in which the digest of the generated image will be written. If the path is relative, the base path is the output directory of the build tool.

Environment variable: QUARKUS_JIB_IMAGE_DIGEST_FILE

string

jib-image.digest

quarkus.jib.image-id-file

The path of a file in which the id of the generated image will be written. If the path is relative, the base path is the output directory of the build tool.

Environment variable: QUARKUS_JIB_IMAGE_ID_FILE

string

jib-image.id

quarkus.jib.offline-mode

Whether or not to operate offline.

Environment variable: QUARKUS_JIB_OFFLINE_MODE

boolean

false

quarkus.jib.docker-executable-name

Name of binary used to execute the docker commands. This is only used by Jib when the container image is being built locally.

Environment variable: QUARKUS_JIB_DOCKER_EXECUTABLE_NAME

string

quarkus.jib.use-current-timestamp

Whether to set the creation time to the actual build time. Otherwise, the creation time will be set to the Unix epoch (00:00:00, January 1st, 1970 in UTC). See Jib FAQ for more information

Environment variable: QUARKUS_JIB_USE_CURRENT_TIMESTAMP

boolean

true

quarkus.jib.use-current-timestamp-file-modification

Whether to set the modification time (last modified time) of the files put by Jib in the image to the actual build time. Otherwise, the modification time will be set to the Unix epoch (00:00:00, January 1st, 1970 in UTC). If the modification time is constant (flag is set to false so Unix epoch is used) across two consecutive builds, the docker layer sha256 digest will be different only if the actual files added by Jib to the docker layer were changed. More exactly, having 2 consecutive builds will generate different docker layers only if the actual content of the files within the docker layer was changed. If the current timestamp is used the sha256 digest of the docker layer will always be different even if the content of the files didn’t change.

Environment variable: QUARKUS_JIB_USE_CURRENT_TIMESTAMP_FILE_MODIFICATION

boolean

true

quarkus.jib.environment-variables

Environment variables to add to the container image

Environment variable: QUARKUS_JIB_ENVIRONMENT_VARIABLES

Map<String,String>

quarkus.jib.docker-environment

Sets environment variables used by the Docker executable. This is only used by Jib when the container image is being built locally.

Environment variable: QUARKUS_JIB_DOCKER_ENVIRONMENT

Map<String,String>

Opciones de Docker

Además de las opciones genéricas de la imagen del contenedor, container-image-docker también proporciona las siguientes opciones:

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property	Type	Default
`quarkus.docker.dockerfile-jvm-path` Path to the JVM Dockerfile. If set to an absolute path then the absolute path will be used, otherwise the path will be considered relative to the project root. If not set src/main/docker/Dockerfile.jvm will be used. Environment variable: `QUARKUS_DOCKER_DOCKERFILE_JVM_PATH` Show more	string	`src/main/docker/Dockerfile.jvm`
`quarkus.docker.dockerfile-native-path` Path to the native Dockerfile. If set to an absolute path then the absolute path will be used, otherwise the path will be considered relative to the project root. If not set src/main/docker/Dockerfile.native will be used. Environment variable: `QUARKUS_DOCKER_DOCKERFILE_NATIVE_PATH` Show more	string	`src/main/docker/Dockerfile.native`
`quarkus.docker.cache-from` Images to consider as cache sources. Values are passed to `docker build` via the `cache-from` option Environment variable: `QUARKUS_DOCKER_CACHE_FROM` Show more	list of string
`quarkus.docker.network` The networking mode for the RUN instructions during build Environment variable: `QUARKUS_DOCKER_NETWORK` Show more	string
`quarkus.docker.executable-name` Name of binary used to execute the docker commands. This setting can override the global container runtime detection. Environment variable: `QUARKUS_DOCKER_EXECUTABLE_NAME` Show more	string
`quarkus.docker.additional-args` Additional arbitrary arguments passed to the executable when building the container image. Environment variable: `QUARKUS_DOCKER_ADDITIONAL_ARGS` Show more	list of string
`quarkus.docker.build-args` Build args passed to docker via `--build-arg` Environment variable: `QUARKUS_DOCKER_BUILD_ARGS` Show more	`Map<String,String>`
Configuration for Docker Buildx options	Type	Default
`quarkus.docker.buildx.platform` Which platform(s) to target during the build. See https://docs.docker.com/engine/reference/commandline/buildx_build/#platform Environment variable: `QUARKUS_DOCKER_BUILDX_PLATFORM` Show more	list of string
`quarkus.docker.buildx.output` Sets the export action for the build result. See https://docs.docker.com/engine/reference/commandline/buildx_build/#output. Note that any filesystem paths need to be absolute paths, not relative from where the command is executed from. Environment variable: `QUARKUS_DOCKER_BUILDX_OUTPUT` Show more	string
`quarkus.docker.buildx.progress` Set type of progress output (`auto`, `plain`, `tty`). Use `plain` to show container output (default “`auto`”). See https://docs.docker.com/engine/reference/commandline/buildx_build/#progress Environment variable: `QUARKUS_DOCKER_BUILDX_PROGRESS` Show more	string

Configuration property

Type

Default

quarkus.docker.dockerfile-jvm-path

Path to the JVM Dockerfile. If set to an absolute path then the absolute path will be used, otherwise the path will be considered relative to the project root. If not set src/main/docker/Dockerfile.jvm will be used.

Environment variable: QUARKUS_DOCKER_DOCKERFILE_JVM_PATH

string

src/main/docker/Dockerfile.jvm

quarkus.docker.dockerfile-native-path

Path to the native Dockerfile. If set to an absolute path then the absolute path will be used, otherwise the path will be considered relative to the project root. If not set src/main/docker/Dockerfile.native will be used.

Environment variable: QUARKUS_DOCKER_DOCKERFILE_NATIVE_PATH

string

src/main/docker/Dockerfile.native

quarkus.docker.cache-from

Images to consider as cache sources. Values are passed to docker build via the cache-from option

Environment variable: QUARKUS_DOCKER_CACHE_FROM

list of string

quarkus.docker.network

The networking mode for the RUN instructions during build

Environment variable: QUARKUS_DOCKER_NETWORK

string

quarkus.docker.executable-name

Name of binary used to execute the docker commands. This setting can override the global container runtime detection.

Environment variable: QUARKUS_DOCKER_EXECUTABLE_NAME

string

quarkus.docker.additional-args

Additional arbitrary arguments passed to the executable when building the container image.

Environment variable: QUARKUS_DOCKER_ADDITIONAL_ARGS

list of string

quarkus.docker.build-args

Build args passed to docker via --build-arg

Environment variable: QUARKUS_DOCKER_BUILD_ARGS

Map<String,String>

Configuration for Docker Buildx options

Type

Default

quarkus.docker.buildx.platform

Which platform(s) to target during the build. See https://docs.docker.com/engine/reference/commandline/buildx_build/#platform

Environment variable: QUARKUS_DOCKER_BUILDX_PLATFORM

list of string

quarkus.docker.buildx.output

Sets the export action for the build result. See https://docs.docker.com/engine/reference/commandline/buildx_build/#output. Note that any filesystem paths need to be absolute paths, not relative from where the command is executed from.

Environment variable: QUARKUS_DOCKER_BUILDX_OUTPUT

string

quarkus.docker.buildx.progress

Set type of progress output (auto, plain, tty). Use plain to show container output (default “auto”). See https://docs.docker.com/engine/reference/commandline/buildx_build/#progress

Environment variable: QUARKUS_DOCKER_BUILDX_PROGRESS

string

OpenShift Options

In addition to the generic container image options, the container-image-openshift also provides the following options:

Configuration property fixed at build time - All other configuration properties are overridable at runtime

Configuration property	Type	Default
`quarkus.openshift.build-strategy` The build config strategy to use. Environment variable: `QUARKUS_OPENSHIFT_BUILD_STRATEGY` Show more	`binary`, `docker`	`binary`
`quarkus.openshift.base-jvm-image` The base image to be used when a container image is being produced for the jar build. The value of this property is used to create an ImageStream for the builder image used in the Openshift build. When it references images already available in the internal Openshift registry, the corresponding streams are used instead. When the application is built against Java 17 or higher, `registry.access.redhat.com/ubi8/openjdk-17:1.16` is used as the default. Otherwise `registry.access.redhat.com/ubi8/openjdk-11:1.16` is used as the default. Environment variable: `QUARKUS_OPENSHIFT_BASE_JVM_IMAGE` Show more	string
`quarkus.openshift.base-native-image` The base image to be used when a container image is being produced for the native binary build. The value of this property is used to create an ImageStream for the builder image used in the Openshift build. When it references images already available in the internal Openshift registry, the corresponding streams are used instead. Environment variable: `QUARKUS_OPENSHIFT_BASE_NATIVE_IMAGE` Show more	string	`quay.io/quarkus/ubi-quarkus-native-binary-s2i:2.0`
`quarkus.openshift.jvm-dockerfile` The default Dockerfile to use for jvm builds Environment variable: `QUARKUS_OPENSHIFT_JVM_DOCKERFILE` Show more	string	`src/main/docker/Dockerfile.jvm`
`quarkus.openshift.native-dockerfile` The default Dockerfile to use for native builds Environment variable: `QUARKUS_OPENSHIFT_NATIVE_DOCKERFILE` Show more	string	`src/main/docker/Dockerfile.native`
`quarkus.openshift.jvm-arguments` The JVM arguments to pass to the JVM when starting the application Environment variable: `QUARKUS_OPENSHIFT_JVM_ARGUMENTS` Show more	list of string
`quarkus.openshift.native-arguments` Additional arguments to pass when starting the native application Environment variable: `QUARKUS_OPENSHIFT_NATIVE_ARGUMENTS` Show more	list of string
`quarkus.openshift.jar-directory` The directory where the jar is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non default image is used. Environment variable: `QUARKUS_OPENSHIFT_JAR_DIRECTORY` Show more	string
`quarkus.openshift.jar-file-name` The resulting filename of the jar in the S2I image. This option may be used if the selected S2I image uses a fixed name for the jar. Environment variable: `QUARKUS_OPENSHIFT_JAR_FILE_NAME` Show more	string
`quarkus.openshift.native-binary-directory` The directory where the native binary is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non-default image is used. Environment variable: `QUARKUS_OPENSHIFT_NATIVE_BINARY_DIRECTORY` Show more	string
`quarkus.openshift.native-binary-file-name` The resulting filename of the native binary in the S2I image. This option may be used if the selected S2I image uses a fixed name for the native binary. Environment variable: `QUARKUS_OPENSHIFT_NATIVE_BINARY_FILE_NAME` Show more	string
`quarkus.openshift.build-timeout` The build timeout. Environment variable: `QUARKUS_OPENSHIFT_BUILD_TIMEOUT` Show more	Duration	`PT5M`
`quarkus.openshift.build-log-level` The log level of OpenShift build log. Environment variable: `QUARKUS_OPENSHIFT_BUILD_LOG_LEVEL` Show more	`fatal`, `error`, `warn`, `info`, `debug`, `trace`	`info`
`quarkus.openshift.image-push-secret` The image push secret to use for pushing to external registries. (see: https://cloud.redhat.com/blog/pushing-application-images-to-an-external-registry) Environment variable: `QUARKUS_OPENSHIFT_IMAGE_PUSH_SECRET` Show more	string
`quarkus.s2i.build-strategy` The build config strategy to use. Environment variable: `QUARKUS_S2I_BUILD_STRATEGY` Show more	`binary`, `docker`	`binary`
`quarkus.s2i.base-jvm-image` The base image to be used when a container image is being produced for the jar build. When the application is built against Java 17 or higher, `registry.access.redhat.com/ubi8/openjdk-17:1.16` is used as the default. Otherwise `registry.access.redhat.com/ubi8/openjdk-11:1.16` is used as the default. Environment variable: `QUARKUS_S2I_BASE_JVM_IMAGE` Show more	string
`quarkus.s2i.base-native-image` The base image to be used when a container image is being produced for the native binary build Environment variable: `QUARKUS_S2I_BASE_NATIVE_IMAGE` Show more	string	`quay.io/quarkus/ubi-quarkus-native-binary-s2i:2.0`
`quarkus.s2i.jvm-arguments` The JVM arguments to pass to the JVM when starting the application Environment variable: `QUARKUS_S2I_JVM_ARGUMENTS` Show more	list of string
`quarkus.s2i.native-arguments` Additional arguments to pass when starting the native application Environment variable: `QUARKUS_S2I_NATIVE_ARGUMENTS` Show more	list of string
`quarkus.s2i.jar-directory` The directory where the jar is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non default image is used. Environment variable: `QUARKUS_S2I_JAR_DIRECTORY` Show more	string	`/deployments/target/`
`quarkus.s2i.jar-file-name` The resulting filename of the jar in the S2I image. This option may be used if the selected S2I image uses a fixed name for the jar. Environment variable: `QUARKUS_S2I_JAR_FILE_NAME` Show more	string
`quarkus.s2i.native-binary-directory` The directory where the native binary is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non-default image is used. Environment variable: `QUARKUS_S2I_NATIVE_BINARY_DIRECTORY` Show more	string	`/home/quarkus/`
`quarkus.s2i.native-binary-file-name` The resulting filename of the native binary in the S2I image. This option may be used if the selected S2I image uses a fixed name for the native binary. Environment variable: `QUARKUS_S2I_NATIVE_BINARY_FILE_NAME` Show more	string
`quarkus.s2i.build-timeout` The build timeout. Environment variable: `QUARKUS_S2I_BUILD_TIMEOUT` Show more	Duration	`PT5M`

Configuration property

Type

Default

quarkus.openshift.build-strategy

The build config strategy to use.

Environment variable: QUARKUS_OPENSHIFT_BUILD_STRATEGY

binary, docker

binary

quarkus.openshift.base-jvm-image

The base image to be used when a container image is being produced for the jar build. The value of this property is used to create an ImageStream for the builder image used in the Openshift build. When it references images already available in the internal Openshift registry, the corresponding streams are used instead. When the application is built against Java 17 or higher, registry.access.redhat.com/ubi8/openjdk-17:1.16 is used as the default. Otherwise registry.access.redhat.com/ubi8/openjdk-11:1.16 is used as the default.

Environment variable: QUARKUS_OPENSHIFT_BASE_JVM_IMAGE

string

quarkus.openshift.base-native-image

The base image to be used when a container image is being produced for the native binary build. The value of this property is used to create an ImageStream for the builder image used in the Openshift build. When it references images already available in the internal Openshift registry, the corresponding streams are used instead.

Environment variable: QUARKUS_OPENSHIFT_BASE_NATIVE_IMAGE

string

quay.io/quarkus/ubi-quarkus-native-binary-s2i:2.0

quarkus.openshift.jvm-dockerfile

The default Dockerfile to use for jvm builds

Environment variable: QUARKUS_OPENSHIFT_JVM_DOCKERFILE

string

src/main/docker/Dockerfile.jvm

quarkus.openshift.native-dockerfile

The default Dockerfile to use for native builds

Environment variable: QUARKUS_OPENSHIFT_NATIVE_DOCKERFILE

string

src/main/docker/Dockerfile.native

quarkus.openshift.jvm-arguments

The JVM arguments to pass to the JVM when starting the application

Environment variable: QUARKUS_OPENSHIFT_JVM_ARGUMENTS

list of string

quarkus.openshift.native-arguments

Additional arguments to pass when starting the native application

Environment variable: QUARKUS_OPENSHIFT_NATIVE_ARGUMENTS

list of string

quarkus.openshift.jar-directory

The directory where the jar is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non default image is used.

Environment variable: QUARKUS_OPENSHIFT_JAR_DIRECTORY

string

quarkus.openshift.jar-file-name

The resulting filename of the jar in the S2I image. This option may be used if the selected S2I image uses a fixed name for the jar.

Environment variable: QUARKUS_OPENSHIFT_JAR_FILE_NAME

string

quarkus.openshift.native-binary-directory

The directory where the native binary is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non-default image is used.

Environment variable: QUARKUS_OPENSHIFT_NATIVE_BINARY_DIRECTORY

string

quarkus.openshift.native-binary-file-name

The resulting filename of the native binary in the S2I image. This option may be used if the selected S2I image uses a fixed name for the native binary.

Environment variable: QUARKUS_OPENSHIFT_NATIVE_BINARY_FILE_NAME

string

quarkus.openshift.build-timeout

The build timeout.

Environment variable: QUARKUS_OPENSHIFT_BUILD_TIMEOUT

Duration

PT5M

quarkus.openshift.build-log-level

The log level of OpenShift build log.

Environment variable: QUARKUS_OPENSHIFT_BUILD_LOG_LEVEL

fatal, error, warn, info, debug, trace

info

quarkus.openshift.image-push-secret

The image push secret to use for pushing to external registries. (see: https://cloud.redhat.com/blog/pushing-application-images-to-an-external-registry)

Environment variable: QUARKUS_OPENSHIFT_IMAGE_PUSH_SECRET

string

quarkus.s2i.build-strategy

The build config strategy to use.

Environment variable: QUARKUS_S2I_BUILD_STRATEGY

binary, docker

binary

quarkus.s2i.base-jvm-image

The base image to be used when a container image is being produced for the jar build. When the application is built against Java 17 or higher, registry.access.redhat.com/ubi8/openjdk-17:1.16 is used as the default. Otherwise registry.access.redhat.com/ubi8/openjdk-11:1.16 is used as the default.

Environment variable: QUARKUS_S2I_BASE_JVM_IMAGE

string

quarkus.s2i.base-native-image

The base image to be used when a container image is being produced for the native binary build

Environment variable: QUARKUS_S2I_BASE_NATIVE_IMAGE

string

quay.io/quarkus/ubi-quarkus-native-binary-s2i:2.0

quarkus.s2i.jvm-arguments

The JVM arguments to pass to the JVM when starting the application

Environment variable: QUARKUS_S2I_JVM_ARGUMENTS

list of string

quarkus.s2i.native-arguments

Additional arguments to pass when starting the native application

Environment variable: QUARKUS_S2I_NATIVE_ARGUMENTS

list of string

quarkus.s2i.jar-directory

The directory where the jar is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non default image is used.

Environment variable: QUARKUS_S2I_JAR_DIRECTORY

string

/deployments/target/

quarkus.s2i.jar-file-name

The resulting filename of the jar in the S2I image. This option may be used if the selected S2I image uses a fixed name for the jar.

Environment variable: QUARKUS_S2I_JAR_FILE_NAME

string

quarkus.s2i.native-binary-directory

The directory where the native binary is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non-default image is used.

Environment variable: QUARKUS_S2I_NATIVE_BINARY_DIRECTORY

string

/home/quarkus/

quarkus.s2i.native-binary-file-name

The resulting filename of the native binary in the S2I image. This option may be used if the selected S2I image uses a fixed name for the native binary.

Environment variable: QUARKUS_S2I_NATIVE_BINARY_FILE_NAME

string

quarkus.s2i.build-timeout

The build timeout.

Environment variable: QUARKUS_S2I_BUILD_TIMEOUT

Duration

PT5M

About the Duration format

To write duration values, use the standard java.time.Duration format. See the Duration#parse() javadoc for more information.

You can also use a simplified format, starting with a number:

If the value is only a number, it represents time in seconds.
If the value is a number followed by ms, it represents time in milliseconds.

In other cases, the simplified format is translated to the java.time.Duration format for parsing:

If the value is a number followed by h, m, or s, it is prefixed with PT.
If the value is a number followed by d, it is prefixed with P.

Imágenes de contenedores

Extensiones de la imagen del contenedor

Jib

Inclusión de archivos adicionales

Depuración de la JVM

Custom Entrypoint

Multi-module projects and layering

AppCDS

Docker

OpenShift

Buildpack

Construcción

Using @QuarkusIntegrationTest

Subiendo

Seleccionar entre varias extensiones

Integrating with systemd-notify

Personalizar

Opciones de imagen del contenedor

Uso de entornos de IC

Opciones de pluma

Opciones de Docker

OpenShift Options

Integrating with `systemd-notify`