Skip to content

Latest commit

 

History

History
493 lines (356 loc) · 18.8 KB

File metadata and controls

493 lines (356 loc) · 18.8 KB

Packaging OCI Images

Note
For security reasons, images build and run as non-root users. See the {buildpacks-reference}/reference/spec/platform-api/#users[CNB specification] for more details.

The task is automatically created when the java or war plugin is applied and is an instance of {boot-build-image-javadoc}[BootBuildImage].

Docker Daemon

The bootBuildImage task requires access to a Docker daemon. By default, it will communicate with a Docker daemon over a local connection. This works with Docker Engine on all supported platforms without configuration.

Environment variables can be set to configure the bootBuildImage task to use an alternative local or remote connection. The following table shows the environment variables and their values:

Environment variable Description

DOCKER_HOST

URL containing the host and port for the Docker daemon - for example tcp://192.168.99.100:2376

DOCKER_TLS_VERIFY

Enable secure HTTPS protocol when set to 1 (optional)

DOCKER_CERT_PATH

Path to certificate and key files for HTTPS (required if DOCKER_TLS_VERIFY=1, ignored otherwise)

Docker daemon connection information can also be provided using docker properties in the plugin configuration. The following table summarizes the available properties:

Property Description

host

URL containing the host and port for the Docker daemon - for example tcp://192.168.99.100:2376

tlsVerify

Enable secure HTTPS protocol when set to true (optional)

certPath

Path to certificate and key files for HTTPS (required if tlsVerify is true, ignored otherwise)

bindHostToBuilder

When true, the value of the host property will be provided to the container that is created for the CNB builder (optional)

For more details, see also examples.

Docker Registry

If the Docker images specified by the builder or runImage properties are stored in a private Docker image registry that requires authentication, the authentication credentials can be provided using docker.builderRegistry properties.

If the generated Docker image is to be published to a Docker image registry, the authentication credentials can be provided using docker.publishRegistry properties.

Properties are provided for user authentication or identity token authentication. Consult the documentation for the Docker registry being used to store images for further information on supported authentication methods.

The following table summarizes the available properties for docker.builderRegistry and docker.publishRegistry:

Property Description

username

Username for the Docker image registry user. Required for user authentication.

password

Password for the Docker image registry user. Required for user authentication.

url

Address of the Docker image registry. Optional for user authentication.

email

E-mail address for the Docker image registry user. Optional for user authentication.

token

Identity token for the Docker image registry user. Required for token authentication.

For more details, see also examples.

Image Customizations

The plugin invokes a {buildpacks-reference}/concepts/components/builder/[builder] to orchestrate the generation of an image. The builder includes multiple {buildpacks-reference}/concepts/components/buildpack[buildpacks] that can inspect the application to influence the generated image. By default, the plugin chooses a builder image. The name of the generated image is deduced from project properties.

Task properties can be used to configure how the builder should operate on the project. The following table summarizes the available properties and their default values:

Property Command-line option Description Default value

builder

--builder

Name of the Builder image to use.

paketobuildpacks/builder:base or paketobuildpacks/builder:tiny when {nbt-gradle-plugin}[GraalVM Native Image plugin] is applied.

runImage

--runImage

Name of the run image to use.

No default value, indicating the run image specified in Builder metadata should be used.

imageName

--imageName

{spring-boot-api}/buildpack/platform/docker/type/ImageReference.html#of-java.lang.String-[Image name] for the generated image.

docker.io/library/${project.name}:${project.version}

pullPolicy

--pullPolicy

{spring-boot-api}/buildpack/platform/build/PullPolicy.html[Policy] used to determine when to pull the builder and run images from the registry. Acceptable values are ALWAYS, NEVER, and IF_NOT_PRESENT.

ALWAYS

environment

Environment variables that should be passed to the builder.

Empty or ['BP_NATIVE_IMAGE': 'true'] when {nbt-gradle-plugin}[GraalVM Native Image plugin] is applied.

buildpacks

Buildpacks that the builder should use when building the image. Only the specified buildpacks will be used, overriding the default buildpacks included in the builder. Buildpack references must be in one of the following forms:

  • Buildpack in the builder - [urn:cnb:builder:]<buildpack ID>[@<version>]

  • Buildpack in a directory on the file system - [file://]<path>

  • Buildpack in a gzipped tar (.tgz) file on the file system - [file://]<path>/<file name>

  • Buildpack in an OCI image - [docker://]<host>/<repo>[:<tag>][@<digest>]

None, indicating the builder should use the buildpacks included in it.

bindings

Volume bind mounts that should be mounted to the builder container when building the image. The bindings will be passed unparsed and unvalidated to Docker when creating the builder container. Bindings must be in one of the following forms:

  • <host source path>:<container destination path>[:<options>]

  • <host volume name>:<container destination path>[:<options>]

Where <options> can contain:

  • ro to mount the volume as read-only in the container

  • rw to mount the volume as readable and writable in the container

  • volume-opt=key=value to specify key-value pairs consisting of an option name and its value

network

--network

The network driver the builder container will be configured to use. The value supplied will be passed unvalidated to Docker when creating the builder container.

cleanCache

--cleanCache

Whether to clean the cache before building.

false

verboseLogging

Enables verbose logging of builder operations.

false

publish

--publishImage

Whether to publish the generated image to a Docker registry.

false

tags

A list of one or more additional tags to apply to the generated image. The values provided to the tags option should be full image references in the form of [image name]:[tag] or [repository]/[image name]:[tag].

buildCache

A cache containing layers created by buildpacks and used by the image building process.

A named volume in the Docker daemon, with a name derived from the image name.

launchCache

A cache containing layers created by buildpacks and used by the image launching process.

A named volume in the Docker daemon, with a name derived from the image name.

Note
The plugin detects the target Java compatibility of the project using the JavaPlugin’s targetCompatibility property. When using the default Paketo builder and buildpacks, the plugin instructs the buildpacks to install the same Java version. You can override this behaviour as shown in the builder configuration examples.

Examples

Custom Image Builder and Run Image

If you need to customize the builder used to create the image or the run image used to launch the built image, configure the task as shown in the following example:

Groovy
link:../gradle/packaging/boot-build-image-builder.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-builder.gradle.kts[role=include]

This configuration will use a builder image with the name mine/java-cnb-builder and the tag latest, and the run image named mine/java-cnb-run and the tag latest.

The builder and run image can be specified on the command line as well, as shown in this example:

$ gradle bootBuildImage --builder=mine/java-cnb-builder --runImage=mine/java-cnb-run

Builder Configuration

If the builder exposes configuration options, those can be set using the environment property.

The following is an example of {paketo-java-reference}/#configuring-the-jvm-version[configuring the JVM version] used by the Paketo Java buildpacks at build time:

Groovy
link:../gradle/packaging/boot-build-image-env.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-env.gradle.kts[role=include]

If there is a network proxy between the Docker daemon the builder runs in and network locations that buildpacks download artifacts from, you will need to configure the builder to use the proxy. When using the Paketo builder, this can be accomplished by setting the HTTPS_PROXY and/or HTTP_PROXY environment variables as show in the following example:

Groovy
link:../gradle/packaging/boot-build-image-env-proxy.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-env-proxy.gradle.kts[role=include]

Runtime JVM Configuration

Paketo Java buildpacks {paketo-java-reference}/#runtime-jvm-configuration[configure the JVM runtime environment] by setting the JAVA_TOOL_OPTIONS environment variable. The buildpack-provided JAVA_TOOL_OPTIONS value can be modified to customize JVM runtime behavior when the application image is launched in a container.

Environment variable modifications that should be stored in the image and applied to every deployment can be set as described in the {paketo-reference}/buildpacks/configuration/#environment-variables[Paketo documentation] and shown in the following example:

Groovy
link:../gradle/packaging/boot-build-image-env-runtime.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-env-runtime.gradle.kts[role=include]

Custom Image Name

By default, the image name is inferred from the name and the version of the project, something like docker.io/library/${project.name}:${project.version}. You can take control over the name by setting task properties, as shown in the following example:

Groovy
link:../gradle/packaging/boot-build-image-name.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-name.gradle.kts[role=include]

Note that this configuration does not provide an explicit tag so latest is used. It is possible to specify a tag as well, either using ${project.version}, any property available in the build or a hardcoded version.

The image name can be specified on the command line as well, as shown in this example:

$ gradle bootBuildImage --imageName=example.com/library/my-app:v1

Buildpacks

By default, the builder will use buildpacks included in the builder image and apply them in a pre-defined order. An alternative set of buildpacks can be provided to apply buildpacks that are not included in the builder, or to change the order of included buildpacks. When one or more buildpacks are provided, only the specified buildpacks will be applied.

The following example instructs the builder to use a custom buildpack packaged in a .tgz file, followed by a buildpack included in the builder.

Groovy
link:../gradle/packaging/boot-build-image-buildpacks.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-buildpacks.gradle.kts[role=include]

Buildpacks can be specified in any of the forms shown below.

A buildpack located in a CNB Builder (version may be omitted if there is only one buildpack in the builder matching the buildpack-id):

  • urn:cnb:builder:buildpack-id

  • urn:cnb:builder:buildpack-id@0.0.1

  • buildpack-id

  • buildpack-id@0.0.1

A path to a directory containing buildpack content (not supported on Windows):

  • file:///path/to/buildpack/

  • /path/to/buildpack/

A path to a gzipped tar file containing buildpack content:

  • file:///path/to/buildpack.tgz

  • /path/to/buildpack.tgz

An OCI image containing a packaged buildpack:

  • docker://example/buildpack

  • docker:///example/buildpack:latest

  • docker:///example/buildpack@sha256:45b23dee08…​

  • example/buildpack

  • example/buildpack:latest

  • example/buildpack@sha256:45b23dee08…​

Image Publishing

The generated image can be published to a Docker registry by enabling a publish option.

If the Docker registry requires authentication, the credentials can be configured using docker.publishRegistry properties. If the Docker registry does not require authentication, the docker.publishRegistry configuration can be omitted.

Note
The registry that the image will be published to is determined by the registry part of the image name (docker.example.com in these examples). If docker.publishRegistry credentials are configured and include a url property, this value is passed to the registry but is not used to determine the publishing registry location.
Groovy
link:../gradle/packaging/boot-build-image-publish.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-publish.gradle.kts[role=include]

The publish option can be specified on the command line as well, as shown in this example:

$ gradle bootBuildImage --imageName=docker.example.com/library/my-app:v1 --publishImage

Builder Cache Configuration

The CNB builder caches layers that are used when building and launching an image. By default, these caches are stored as named volumes in the Docker daemon with names that are derived from the full name of the target image. If the image name changes frequently, for example when the project version is used as a tag in the image name, then the caches can be invalidated frequently.

The cache volumes can be configured to use alternative names to give more control over cache lifecycle as shown in the following example:

Groovy
link:../gradle/packaging/boot-build-image-caches.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-caches.gradle.kts[role=include]

Docker Configuration

Docker Configuration for minikube

The plugin can communicate with the Docker daemon provided by minikube instead of the default local connection.

On Linux and macOS, environment variables can be set using the command eval $(minikube docker-env) after minikube has been started.

The plugin can also be configured to use the minikube daemon by providing connection details similar to those shown in the following example:

Groovy
link:../gradle/packaging/boot-build-image-docker-host.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-docker-host.gradle.kts[role=include]

Docker Configuration for podman

The plugin can communicate with a podman container engine.

The plugin can be configured to use podman local connection by providing connection details similar to those shown in the following example:

Groovy
link:../gradle/packaging/boot-build-image-docker-host-podman.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-docker-host-podman.gradle.kts[role=include]

Docker Configuration for Authentication

If the builder or run image are stored in a private Docker registry that supports user authentication, authentication details can be provided using docker.builderRegistry properties as shown in the following example:

Groovy
link:../gradle/packaging/boot-build-image-docker-auth-user.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-docker-auth-user.gradle.kts[role=include]

If the builder or run image is stored in a private Docker registry that supports token authentication, the token value can be provided using docker.builderRegistry as shown in the following example:

Groovy
link:../gradle/packaging/boot-build-image-docker-auth-token.gradle[role=include]
Kotlin
link:../gradle/packaging/boot-build-image-docker-auth-token.gradle.kts[role=include]