Package io.quarkus.container.image.jib.deployment

Class JibConfig

  • @ConfigRoot(phase=BUILD_TIME)
public class JibConfig
extends Object

    • Field Detail

      • baseJvmImage

        @ConfigItem(defaultValue="fabric8/java-alpine-openjdk11-jre")
public String baseJvmImage
        The base image to be used when a container image is being produced for the jar build

      • baseNativeImage

        @ConfigItem(defaultValue="registry.access.redhat.com/ubi8/ubi-minimal")
public String baseNativeImage
        The base image to be used when a container image is being produced for the native binary build

      • jvmArguments

        @ConfigItem(defaultValue="-Djava.util.logging.manager=org.jboss.logmanager.LogManager")
public List<String> jvmArguments
        Additional JVM arguments to pass to the JVM when starting the application

      • nativeArguments

        @ConfigItem
public Optional<List<String>> nativeArguments
        Additional arguments to pass when starting the native application

      • jvmEntrypoint

        @ConfigItem
public Optional<List<String>> jvmEntrypoint
        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
        • 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
        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

      • nativeEntrypoint

        @ConfigItem
public Optional<List<String>> nativeEntrypoint
        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
        • 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
        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

      • environmentVariables

        @ConfigItem
public Map<String,​String> environmentVariables
        Environment variables to add to the container image

      • labels

        @ConfigItem
public Map<String,​String> labels
        Custom labels to add to the generated image

      • baseRegistryUsername

        @ConfigItem
public Optional<String> baseRegistryUsername
        The username to use to authenticate with the registry used to pull the base JVM image

      • baseRegistryPassword

        @ConfigItem
public Optional<String> baseRegistryPassword
        The password to use to authenticate with the registry used to pull the base JVM image

      • ports

        @ConfigItem(defaultValue="${quarkus.http.port:8080}")
public List<Integer> ports
        The ports to expose

      • user

        @ConfigItem
public Optional<String> user
        The user to use in generated image

      • alwaysCacheBaseImage

        @ConfigItem(defaultValue="false")
public boolean alwaysCacheBaseImage
        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.

      • platforms

        @ConfigItem
public Optional<Set<String>> platforms
        List of target platforms. Each platform is defined using the pattern: \|\[/variant]|\/\[/variant] ex: 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 It doesn't work with native images, as cross-compilation is not supported Target Platform is a incubating feature of Jib. See Jib FAQ for more information

      • imageDigestFile

        @ConfigItem(defaultValue="jib-image.digest")
public String imageDigestFile
        The path of a file that will be written containing the digest of the generated image. If the path is relative, is writen to the output directory of the build tool

      • imageIdFile

        @ConfigItem(defaultValue="jib-image.id")
public String imageIdFile
        The path of a file that will be written containing the id of the generated image. If the path is relative, is writen to the output directory of the build tool

    • Constructor Detail

      • JibConfig

        public JibConfig()