Building Java container images using Jib
2021年8月17日
0 分で読めますSuppose you’ve been working with container images for more than a minute. In that case, you’re probably familiar with those ubiquitous documents that describe, layer-by-layer, the steps needed to construct an image: Dockerfiles. Did you know that there is a growing set of tools for building OCI compliant images without Dockerfiles? In this article, we will look at Jib, a 100% Java-based tool that can build highly optimized images without having to worry about correctly forming up a Dockerfile.
I’m going to assume you already understand image construction and have at least a basic understanding of Dockerfiles, but if you are new to them you might want to check out my post on developer-driven workflows where I go into the details of container image building.
The problem
As a Java developer, in addition to your application code base and library dependencies, you are probably also used to keeping track of what JDK and JVM you are targeting. This can include the web app-server version you are building on top of and maybe some of the runtime configurations like garbage collector tuning and database connections. What you very well may not have had to deal with are operating system level concerns such as package installation, filesystem permissions, what UID/GID gets used at runtime, and other such configuration details that historically have been handled by the operations and security teams who provide platforms to you.
With the adoption of container runtimes and the orchestration systems that sit on top of them, much of these lower-level concerns are shifting squarely into the scope of developer teams in the form of infrastructure as code (IaC) configuration files that are part of the application/service code repositories. These files take various forms such as Kubernetes YAML, Terraform HCL, CloudFormation JSON, and, of course, Dockerfiles which define the structure of the container image where your application will run.
Getting your application packaged into an image and running in a container is not usually a very difficult task. But making sure that the image is well-formed, optimized, secure, and compliant with your organizational standards can, however, be challenging. Developers are now being tasked with learning about OS-level scanning tools, maintaining image labeling standards, learning the latest Dockerfile best practices, and whatever else they’re being asked to own. There are linting and scanning tools such as Hadolint, Dockle, and our own Snyk Container offering which can aid you in these tasks. But what if we could automate away most — if not all — of these new requirements and boilerplate content?
Enter Jib: A 100% Java-based container image build tool
Jib is an open source, 100% Java tool that builds OCI (Docker v2) compliant container images without a Dockerfile or even a container runtime present. Jib can be used as a standalone CLI tool but is most commonly used as a Maven or Gradle build step plugin. Using the plugin allows you to simply run the same mvn or gradle build command that you already use to construct your .jar, .war, etc., artifacts today to also construct — and optionally deploy — an OCI image that is ready to run your application in a container.
Starting from a Spring Boot application, adding Jib is as simple as inserting this bit of XML into your Maven pom.xml file (full doc’s here) and re-running the mvn package command. There are a couple of options we can set here about where we want the container placed. For simplicity’s sake, this example deploys to an image registry that we will use later to run from, but you can also have the image dropped to a local **.**tar file or, if you happen to have a Docker daemon running and accessible, to that Docker local image cache (just like a Docker build would do).
1<build>
2<plugins>
3...
4<plugin>
5<groupId>com.google.cloud.tools</groupId>
6<artifactId>jib-maven-plugin</artifactId>
7<version>3.1.1</version>
8<configuration>
9<to>
10<image>reg.mycorp.com/smalls/spring-goof</image>
11</to>
12</configuration>
13<executions>
14<execution>
15<phase>package</phase>
16<goals>
17<goal>build</goal>
18</goals>
19</execution>
20</executions>
21</plugin>
22...
23</plugins>
24</build>1$mvn package
2...
3[INFO] --- jib-maven-plugin:3.1.1:build (default) @ spring-goof ---
4[WARNING] 'mainClass' configured in 'maven-jar-plugin' is not a valid Java class: ${start-class}
5[INFO]
6[INFO] Containerizing application to localhost:5000/spring-goof...
7[WARNING] Base image 'adoptopenjdk:8-jre' does not use a specific image digest - build may not be reproducible
8[WARNING] The credential helper (docker-credential-desktop) has nothing for server URL: localhost:5000
9[WARNING]
10Got output:
11
12credentials not found in native keychain
13
14[WARNING] Cannot verify server at https://localhost:5000/v2/. Attempting again with no TLS verification.
15[WARNING] Failed to connect to https://localhost:5000/v2/ over HTTPS. Attempting again with HTTP.
16[INFO] The base image requires auth. Trying again for adoptopenjdk:8-jre...
17[WARNING] The credential helper (docker-credential-desktop) has nothing for server URL: registry-1.docker.io
18[WARNING]
19Got output:
20
21credentials not found in native keychain
22
23[WARNING] The credential helper (docker-credential-desktop) has nothing for server URL: registry.hub.docker.com
24[WARNING]
25Got output:
26
27credentials not found in native keychain
28
29[INFO] Using credentials from Docker config (/Users/eric/.docker/config.json) for adoptopenjdk:8-jre
30[INFO] Using base image with digest: sha256:117fae95422c19f1c1ddfb0f869913c1d934547e8eb903738a9fd2c3ad11a207
31[INFO]
32[INFO] Container entrypoint set to [java, -cp, /app/resources:/app/classes:/app/libs/*, org.snyk.groceries.SpringGoofApplication]
33[INFO]
34[INFO] Built and pushed image as localhost:5000/spring-goof
35[INFO] Executing tasks:
36[INFO] [==============================] 100.0% complete
37[INFO]
38[INFO] ------------------------------------------------------------------------
39[INFO] BUILD SUCCESS
40[INFO] ------------------------------------------------------------------------
41[INFO] Total time: 11.169 s
42[INFO] Finished at: 2021-06-28T14:43:49-05:00
43[INFO] ------------------------------------------------------------------------Note: There are some interesting “warning” lines in the above output that we will discuss a little later.
Now, on a machine with a container runtime present, simply run the container: docker run --rm -it -p 8080:8080 myimage:tag
1$ docker run --rm -it -p8080:8080 reg.mycorp.com/smalls/spring-goof
2Unable to find image reg.mycorp.com/smalls/spring-goof:latest' locally
3latest: Pulling from spring-goof
4c549ccf8d472: Pull complete
5bd7766c75e8f: Pull complete
67e80a3d8823a: Pull complete
7a7321fbff05c: Pull complete
805d4865ff251: Pull complete
9e8d1ce8a5389: Pull complete
10bc56aad8a781: Pull complete
11Digest: sha256:74710d3c27ad84cb594b84a519c111a2b04a611ca52ac81f644e3ab5e15d0063
12Status: Downloaded newer image for reg.mycorp.com/smalls/spring-goof:latest
13
14 . ____ _ __ _ _
15 /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
16( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
17 \\/ ___)| |_)| | | | | || (_| | ) ) ) )
18 ' |____| .__|_| |_|_| |_\__, | / / / /
19 =========|_|==============|___/=/_/_/_/
20 :: Spring Boot :: (v1.5.5.RELEASE)
21
222021-06-28 19:54:51.550 INFO 1 --- [ main] o.snyk.groceries.SpringGoofApplication : Starting SpringGoofApplication on beaa3641ca38 with PID 1 (/app/classes started by root in /)If you are a Gradle user, check out the official documentation for full info on how to do the same thing in your build.gradle file.
That’s all there is to it, no Dockerfile or extra tooling is needed to build images, just the same build tools that you are already using to build your Java artifacts. Not only does this simplify developers’ lives, but it also makes CI build agent support much easier as there is no need to expose the Docker socket or manage other build tools.
Digging into the image
Ok, so the image building process may be easier but, if you’re like me when I first saw it, you probably have questions like...
How does Jib build images?
Just like any image building tool, Jib creates a set of filesystem layers that contain the Java runtime, your application, and all of its dependencies, as well as the metadata that the container engine uses to know how to start the JVM.
Here’s the layer info for this example as presented by the docker image history command:
1$ docker image history localhost:5000/spring-goof:latest
2IMAGE CREATED CREATED BY SIZE COMMENT
34c125b59f147 51 years ago jib-maven-plugin:3.1.1 79B jvm arg files
4<missing> 51 years ago jib-maven-plugin:3.1.1 6.36kB classes
5<missing> 51 years ago jib-maven-plugin:3.1.1 0B resources
6<missing> 51 years ago jib-maven-plugin:3.1.1 30MB dependencies
7<missing> 10 days ago /bin/sh -c #(nop) ENV JAVA_HOME=/opt/java/o… 0B
8<missing> 10 days ago /bin/sh -c set -eux; ARCH="$(dpkg --prin… 108MB
9<missing> 10 days ago /bin/sh -c #(nop) ENV JAVA_VERSION=jdk8u292… 0B
10<missing> 10 days ago /bin/sh -c apt-get update && apt-get ins… 43.2MB
11<missing> 10 days ago /bin/sh -c #(nop) ENV LANG=en_US.UTF-8 LANG… 0B
12<missing> 10 days ago /bin/sh -c #(nop) CMD ["bash"] 0B
13<missing> 10 days ago /bin/sh -c #(nop) ADD file:920cf788d1ba88f76… 72.7MB Notice the CREATED dates for the first 4 layers all say “51 years ago.” This is a side-effect of Jib’s repeatable build strategy which aims to create the exact same layer hashes for builds against the same codebase. For more details about this, check out their FAQ.
As we can see from the layer comments, we have a bunch of layers from the AdoptOpenJDK default base image — more on this below —followed, in order, by:
Library dependencies defined in your Maven/Gradle file(s)
Resource files
Class files from your compiled application code
Java JVM argument files.
Digging a little deeper, using the open-source tool dive, let’s look at what files are in each of these 4 layers:
Dependencies
This layer contains the addition of all of the .jar files to the /app/libs folder.
1│ Layers ├──────────────────────────────────────────────────────────────────── ┃ ● Current Layer Contents ┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2Cmp Size Command Permission UID:GID Size Filetree
3 73 MB FROM 679f8666b5733b3 drwxr-xr-x 0:0 30 MB └── app
4 43 MB apt-get update && apt-get install -y --no-install-recommends t drwxr-xr-x 0:0 30 MB └── libs
5 108 MB set -eux; ARCH="$(dpkg --print-architecture)"; case "${ARC -rw-r--r-- 0:0 445 kB ├── antlr-2.7.7.jar
6 30 MB jib-maven-plugin:3.1.1 -rw-r--r-- 0:0 1.9 MB ├── aspectjweaver-1.8.10.jar
7 0 B jib-maven-plugin:3.1.1 -rw-r--r-- 0:0 65 kB ├── classmate-1.3.3.jar
8 6.4 kB jib-maven-plugin:3.1.1 -rw-r--r-- 0:0 314 kB ├── dom4j-1.6.1.jar
9 79 B jib-maven-plugin:3.1.1 -rw-r--r-- 0:0 13 kB ├── evo-inflector-1.2.2.jar
10 -rw-r--r-- 0:0 1.8 MB ├── h2-1.4.196.jar
11│ Layer Details ├───────────────────────────────────────────────────────────── -rw-r--r-- 0:0 75 kB ├── hibernate-commons-annotations-5
12 -rw-r--r-- 0:0 5.6 MB ├── hibernate-core-5.0.12.Final.jar
13Tags: (unavailable) -rw-r--r-- 0:0 612 kB ├── hibernate-entitymanager-5.0.12.
14Id: da844eca910f44e825c72121f4ec9700b3c9eec8d4c2407f926cdad0799b33e8 -rw-r--r-- 0:0 113 kB ├── hibernate-jpa-2.1-api-1.0.0.Fin
15Digest: sha256:0862e7d5215a0ec2cf7d5a8864a5a0439d9c70c39b14cdc6c38f41487ca8f23 -rw-r--r-- 0:0 726 kB ├── hibernate-validator-5.3.5.Final
16Command: -rw-r--r-- 0:0 56 kB ├── jackson-annotations-2.8.0.jar
17jib-maven-plugin:3.1.1 -rw-r--r-- 0:0 283 kB ├── jackson-core-2.8.9.jar
18Resources
Here we see /app/resources and all of the associated files from our resources folders.
1┃ ● Layers ┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │ Current Layer Contents ├────────────────────────────────────────────────────
2Cmp Size Command Permission UID:GID Size Filetree
3 73 MB FROM 679f8666b5733b3 drwxr-xr-x 0:0 0 B └── app
4 43 MB apt-get update && apt-get install -y --no-install-recommends t drwxr-xr-x 0:0 0 B └── resources
5 108 MB set -eux; ARCH="$(dpkg --print-architecture)"; case "${ARC -rw-r--r-- 0:0 0 B ├── application.properties
6 30 MB jib-maven-plugin:3.1.1 drwxr-xr-x 0:0 0 B └── org
7 0 B jib-maven-plugin:3.1.1 drwxr-xr-x 0:0 0 B └── snyk
8 6.4 kB jib-maven-plugin:3.1.1 drwxr-xr-x 0:0 0 B └── groceries
9 79 B jib-maven-plugin:3.1.1 drwxr-xr-x 0:0 0 B ├── domain
10 drwxr-xr-x 0:0 0 B └── repository
11│ Layer Details ├─────────────────────────────────────────────────────────────
12
13Tags: (unavailable)
14Id: 7891783fbddf2ac3f624ecdea6fd7d51efa476bf87b82a3a1da2517167a7812a
15Digest: sha256:bc7cee3aeb381d0b453212f345eaf34f55613c2dbb988af22f626877f4ecc89
16Command:
17jib-maven-plugin:3.1.1
18Classes
The .class files that came from the compile phase of the build are in this layer under /app/classes.
1┃ ● Layers ┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │ Current Layer Contents ├────────────────────────────────────────────────────
2Cmp Size Command Permission UID:GID Size Filetree
3 73 MB FROM 679f8666b5733b3 drwxr-xr-x 0:0 6.4 kB └── app
4 43 MB apt-get update && apt-get install -y --no-install-recommends t drwxr-xr-x 0:0 6.4 kB └── classes
5 108 MB set -eux; ARCH="$(dpkg --print-architecture)"; case "${ARC drwxr-xr-x 0:0 6.4 kB └── org
6 30 MB jib-maven-plugin:3.1.1 drwxr-xr-x 0:0 6.4 kB └── snyk
7 0 B jib-maven-plugin:3.1.1 drwxr-xr-x 0:0 6.4 kB └── groceries
8 6.4 kB jib-maven-plugin:3.1.1 -rw-r--r-- 0:0 3.3 kB ├── SpringGoofApplicati
9 79 B jib-maven-plugin:3.1.1 drwxr-xr-x 0:0 1.7 kB ├── domain
10 -rw-r--r-- 0:0 1.7 kB │ └── Item.class
11│ Layer Details ├───────────────────────────────────────────────────────────── drwxr-xr-x 0:0 1.3 kB └── repository
12 -rw-r--r-- 0:0 1.3 kB └── ItemRepository.
13Tags: (unavailable)
14Id: 5d4509a5f5856f5d6de92ed621d301861fccf414f9088d0c81e47572f48e4194
15Digest: sha256:778c99f6b1c637ab73e3fff99e933d6d6a8d247f9849d2695066c4f2e823ee7
16Command:
17jib-maven-plugin:3.1.1 JVM Arg Files
1┃ ● Layers ┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │ Current Layer Contents ├────────────────────────────────────────────────────
2Cmp Size Command Permission UID:GID Size Filetree
3 73 MB FROM 679f8666b5733b3 drwxr-xr-x 0:0 79 B └── app
4 43 MB apt-get update && apt-get install -y --no-install-recommends t -rw-r--r-- 0:0 39 B ├── jib-classpath-file
5 108 MB set -eux; ARCH="$(dpkg --print-architecture)"; case "${ARC -rw-r--r-- 0:0 40 B └── jib-main-class-file
6 30 MB jib-maven-plugin:3.1.1
7 0 B jib-maven-plugin:3.1.1
8 6.4 kB jib-maven-plugin:3.1.1
9 79 B jib-maven-plugin:3.1.1
10
11│ Layer Details ├─────────────────────────────────────────────────────────────
12
13Tags: (unavailable)
14Id: 22877091a2de894cac9070c121b116e5d3247b3a4f81774032c0698bf6a2de2f
15Digest: sha256:d8a8afa0a3d1efdb00b38b28e3dd075342c0dc65e52977e56dd3f21c277ae94
16Command:
17jib-maven-plugin:3.1.1 Finally, we have a couple of files that contain arguments used when starting up the JVM in the container in the top-level /app folder. In this example, if you were to inspect the contents of these two files you would find the runtime classpath and main class info.
1# cat jib-classpath-file
2/app/resources:/app/classes:/app/libs/*
3
4# cat jib-main-class-file
5org.snyk.groceries.SpringGoofApplicationNote: You may encounter more layers in your Jib-generated images depending on the structure of your Maven/Gradle build. See the Jib FAQ for more information about the other possible layers.
What base image does Jib use and what if I need to use my own image?
By default, Jib will use the DockerHub official adoptopenjdk:jre-8 base image for JAR file builds or the DockerHub official jetty base image for WAR builds. This is configurable via the plugin configurations. See their official documentation for details including setting custom ENTRYPOINT, USERor other declarations if needed. That same documentation also talks about why it’s a good idea to set your own base image and to use a specific hash so as to enforce build repeatability. Many organizations have internally “blessed” base images that development teams are required to use which have been audited and hardened by security and operations teams. Here’s an example of how to modify the Maven pom.xml to use such an image.
1<build>
2<plugins>
3...
4<plugin>
5...
6<configuration>
7<from>
8<image>reg.mycorp.com/smalls-base/openjdk:8u292-2021.7.4</image>
9</from>
10...
11</configuration>
12...
13</plugin>
14...
15</plugins>
16</build>Additional settings like standardized image labeling are also supported. Let’s say, for example, that your organization requires all images to contain the following labels:
Source code Git url
Git commit id/hash
Maven project build version
Assuming the pom.xml already has access to this data, the Jib plugin config to add the labels is very simple:
1<build>
2<plugins>
3...
4<plugin>
5...
6<configuration>
7...
8<container>
9<labels>
10<git.remote.origin.url>${git.remote.origin.url}</git.remote.origin.url>
11<git.commit.id>${git.commit.id}</git.commit.id>
12<mvn.build.version>${project.version}</mvn.build.version>
13</labels>
14</container>
15...
16</configuration>
17...
18</plugin>
19...
20</plugins>
21</build>Inspecting the image created, we can see the labels applied, just as if they had been added via Dockerfile LABELS lines (I’m using the wonderful jq command-line tool here to pull just that array out of the response).
1$ docker image inspect reg.mycorp.com/smalls/spring-goof:latest | jq .[].Config.Labels
2{
3 "git.commit.id": "960d768e9739ffb8e9a503c9ad3f6dad86ac68b1",
4 "git.remote.origin.url": "git@github.com:mycorp-dev/spring-goof.git",
5 "mvn.build.version": "0.0.1-SNAPSHOT"
6}Now, imagine all of the complexity of these standardized configurations are defined in a parent POM via <pluginManagement> and other usual Maven configurations. The developers no longer have to worry or even look at all of this boiler-plate XML and the architects can enforce and update the standards across the organization without having to bother their teams!
How can I be sure things are secure?
One of the challenges we face with more general image building tools like the Dockerfile is that you can do pretty much anything you want as part of the build including installing packages, using ADD to download files from random web servers, and a myriad of other steps that need to be reviewed and scrutinized. With Jib, many of these choices are automatically applied, and overriding them requires explicit Maven/Gradle configuration changes that are visibly apparent in a code review just like changing a dependency or any other build configuration would be.
As for security scanning, one of the great features Snyk Container provides is recommendations for different base images that have fewer vulnerabilities and, as of today, that functionality now works even without a Dockerfile to reference what base your image has. That means images built by Jib — or any non-Dockerfile tool —can take advantage of the same recommendations.
If you would like to follow along and scan your own Java containers, create a free account and get instructions on how to install the Snyk scanning tool.
For this example, I’ve set my base image to openjdk:8u121-jre , ran mvn package, and pulled the image to my laptop. Now I’ll simply run a snyk container test against it.
1$ snyk container test localhost:5000/spring-goof:latest
2
3Testing localhost:5000/spring-goof:latest...
4
5... (a bunch of scan results removed here) ...
6
7Organization: mycorp-snyk-org
8Package manager: deb
9Project name: docker-image|reg.mycorp.com/smalls/spring-goof:latest
10Docker image: reg.mycorp.com/smalls/spring-goof:latest
11Platform: linux/amd64
12Base image: openjdk:8u181-jre-stretch
13Licenses: enabled
14
15Tested 261 dependencies for known issues, found 410 issues.
16
17Base Image Vulnerabilities Severity
18openjdk:8u181-jre-stretch 410 149 high, 91 medium, 170 low
19
20Recommendations for base image upgrade:
21
22Minor upgrades
23Base Image Vulnerabilities Severity
24openjdk:8-jre-stretch 205 71 high, 36 medium, 98 low
25
26Major upgrades
27Base Image Vulnerabilities Severity
28openjdk:11.0.5-jre-stretch 178 66 high, 28 medium, 84 low
29
30Alternative image types
31Base Image Vulnerabilities Severity
32openjdk:17-ea-22-oraclelinux8 0 0 high, 0 medium, 0 low
33openjdk:16-jdk-oraclelinux7 0 0 high, 0 medium, 0 low
34openjdk:17-ea-27-jdk-oraclelinux7 0 0 high, 0 medium, 0 low
35openjdk:16-ea-29-jdk-oraclelinux8 0 0 high, 0 medium, 0 lowAs you can see, the scan automatically detected openjdk:8u181-jre-stretch as the base image (that is an alias tag to openjdk:8u181-jre) and reported its 410 vulnerabilities. It also made some recommendations to change the base image ranging from a minor version upgrade to the latest openjdk:8-jre tag — which has about half as many issues — all of the way up to newer JVMs that have no vulnerabilities at all.
So you can see that we not only can find out what vulnerabilities are present in the image we are using but we also are given advice on how to resolve them via a newer base image, all without having to write a single line of Dockerfile code.
Wrapping up
As you can see, Jib can make containerizing your Java applications a lot easier for developers by eliminating the need to learn Dockerfile syntax or install unfamiliar tools. It also helps architects manage standardization through the well-known Maven or Gradle project hierarchy facilities. Because Jib builds OCI compliant images, you also can leverage industry-standard tools — like Snyk container scanner — to inspect, deploy, and run your application.
If you are also supporting a non-Java project, there are other tools in this space that you may want to consider such as Buildah, Bazel, Earthly, and several BuildKit related projects. Additionally, my colleague, Pas Apicella, has recently published his article about Cloud Native Build Packs and it is definitely something you should read.
Don’t forget to sign up for your free account and start testing your containers, open source dependencies, and IaC code today!