Google Container Tools - Jib
With this post we close the series of articles taking a deep dive on building Docker images. We look at a building Docker images for running Java applications in a Docker container with Jib which is part of the Google Container Tools.
Jib
Jib is highly opinionated about building Java Docker containers using Maven or Gradle as build tool. So it offers plugin support for the above mentioned build tools.
While the methods we discussed in the previous builds all required a running Docker daemon requiring root privileges, Jib works without A Docker installation but can optionally export build images to a Docker host.
By default it uses Googles "Distroless" Docker Images but can use any Docker image as a base image from which to build up.
Building a Spring Boot application with Gradle and Jib
In this example we try to build a Docker image for the Spring Boot application available from the GitHub repository https://github.com/MartinAhrer/continuousdelivery.
This project uses Gradle as build tool. So we just apply the Gradle plugin provided by the Jib project. The configuration of the image name is optional and could also be passed as argument to the build tool.
plugins {
id 'com.google.cloud.tools.jib' version '1.2.0'
}
jib {
to {
image = "martinahrer/continuousdelivery:jib-${project.version}"
}
}
Now we can build the image.
A Docker daemon is not required to run for that task. |
./gradlew jib
docker image history martinahrer/continuousdelivery:jib-0.1 -H
IMAGE CREATED BY SIZE COMMENT
a60b44a57eb4 jib-gradle-plugin:1.2.0 4.44kB classes (1)
<missing> jib-gradle-plugin:1.2.0 1.84kB resources
<missing> jib-gradle-plugin:1.2.0 45.7MB dependencies (2)
1 | High rate of changes (top of layer stack) |
2 | Low rate of changes (bottom of layer stack) |
Looking at the built layers we see how Jib tries to build image layers ordered such that layers that change more frequently are on top while layers that are expected to change less frequent are down in the stack of layers.
With Jib we have a tool that fits best for building Docker images where no Docker engine is available. Also it offers an option where we want to avoid a Docker in Docker setup when a build pipeline is executed in a Docker container.