A Hitchhiker's Guide to Containerizing (Spring Boot) Java Apps

Nicolas Fränkel - Oct 11 '20 - - Dev Community

Containerizing an application based on a "scripting" language is straightforward. Add the sources, download the dependencies, and you're good to go. One could say they are WYSIWYR.

FROM python:3

ADD requirements.txt .            # 1
RUN pip install                   # 2

ADD script.py .                   # 3

CMD ["python", "./script.py"]     # 4
Enter fullscreen mode Exit fullscreen mode
  1. Copy the description of the dependencies
  2. Download the dependencies
  3. Copy the main script
  4. Run the script

With compiled languages in general and Java in particular, things are a bit different. In this post, I'd like to list some alternatives to achieve that.

A sample app

To describe those alternatives, we need a sample application. We will use a Spring Boot one, that offers a REST endpoint and store data in Hazelcast. It's built using Maven, with an existing wrapper.

Sample application architecture

The REST endpoint works like this:

curl -X PUT http://localhost:8080/John
Enter fullscreen mode Exit fullscreen mode 
{"who":"John","when":64244336297226}
Enter fullscreen mode Exit fullscreen mode 
curl http://localhost:8080/
Enter fullscreen mode Exit fullscreen mode 
[{"who":"John","when":64244336297226}]
Enter fullscreen mode Exit fullscreen mode

Compared to scripting languages, Java applications have two main differences:

  1. They require an extra compilation step, which transforms Java source code to bytecode
  2. The deployment unit is generally a self-executable JAR

The naive approach

As a first step, one could build the application outside of Docker, then add the JAR to the image.

./mvnw clean package -DskipTests
Enter fullscreen mode Exit fullscreen mode 
# docker build -t spring-in-docker:0.5 .

FROM adoptopenjdk/openjdk11:alpine-jre

COPY target/spring-in-docker-0.5.jar spring-in-docker.jar

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "spring-in-docker.jar"]
Enter fullscreen mode Exit fullscreen mode

The next logical step is to build the application inside of the Dockerfile:

# docker build -t spring-in-docker:1.0 .

FROM adoptopenjdk/openjdk11:alpine-slim

COPY .mvn .mvn
COPY mvnw .
COPY pom.xml .
COPY src src
RUN ./mvnw package -DskipTests

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "target/spring-in-docker-1.0.jar"]
Enter fullscreen mode Exit fullscreen mode

This way has several downsides:

  • The final image embeds a JDK. First, it increases the size of the final image compared to a JRE. More importantly, it allows the image to compile Java code: this can be a severe security hole in production.
  • The version in the Maven's POM needs to be manually synchronized with the image's version.
  • There's a single OCI layer for the JAR.

The dive executable highlights the last point:

Layers ├─────────────────────────────────────────────────────────────────────────────
Size     Command
5.6 MB   FROM 31609b718dd2bed
 14 MB   apk add --no-cache tzdata --virtual .build-deps curl binutils zstd     && GL
 17 kB   #(nop) COPY multi:5542ba69976bc682acd7b679c22d8a0277609ba9f5b611fd518f87f209
235 MB   set -eux;     apk add --no-cache --virtual .fetch-deps curl;     ARCH="$(apk
 56 kB   #(nop) COPY dir:20c328136da94aa01b2b6fd62c88ef506a15b545aefeb1a1e13473572aee
 10 kB   #(nop) COPY file:08c603013feae81d794c29c4c1f489cc58a32bd593154cc5e40c6afa522
1.8 kB   #(nop) COPY file:1bb01c4e5b60aae391d2efc563ead23a959701863adcf408540f33b7e40
 54 kB   #(nop) COPY dir:d2bd6e2521e5d990b16efb81ae8823e23ed2de826e833b331718b2211d6a
108 MB   ./mvnw package -DskipTests


│ ● Current Layer Contents ├─────────────────────────────────────────────────────────
Permission     UID:GID     Size  Filetree
drwx------       0:0      80 MB  ├─⊕ root
drwxr-xr-x       0:0      28 MB  └── target
drwxr-xr-x       0:0     5.8 kB      ├─⊕ classes
drwxr-xr-x       0:0        0 B      ├─⊕ generated-sources
drwxr-xr-x       0:0       64 B      ├─⊕ maven-archiver
drwxr-xr-x       0:0      364 B      ├─⊕ maven-status
-rw-r--r--       0:0      28 MB      ├── spring-in-docker-1.0.jar
-rw-r--r--       0:0     5.4 kB      └── spring-in-docker-1.0.jar.original
Enter fullscreen mode Exit fullscreen mode

The single layer doesn't look light a big issue at first, but it has a huge consequence. Every change in the source code requires the replacement of the whole OCI layer.

Multi-stage builds to the rescue

Docker multistage builds allow chaining several build steps, with steps later in the chain reusing artifacts created in earlier steps. This way, we can use a JDK for compilation, and a JRE for execution:

# docker build -t spring-in-docker:1.1 .

FROM adoptopenjdk/openjdk11:alpine-slim as build                         # 1

COPY .mvn .mvn
COPY mvnw .
COPY pom.xml .
COPY src src
RUN ./mvnw package -DskipTests

FROM adoptopenjdk/openjdk11:alpine-jre                                   # 2

COPY --from=build target/spring-in-docker-1.1.jar spring-in-docker.jar   # 3

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "spring-in-docker.jar"]
Enter fullscreen mode Exit fullscreen mode
  1. Build step uses a JDK
  2. Run step uses a JRE
  3. Copy the JAR created in the previous build step

Multistage builds create one image per step. All images but the latest are untagged.

To improve the layering, one can decouple the download of the dependencies from the compilation and the packaging.

# docker build -t spring-in-docker:1.2 .

FROM adoptopenjdk/openjdk11:alpine-slim as build

COPY .mvn .mvn                                                           # 1
COPY mvnw .                                                              # 1
COPY pom.xml .                                                           # 1
RUN ./mvnw dependency:go-offline                                          # 2

COPY src src                                                             # 3
RUN ./mvnw package -DskipTests

FROM adoptopenjdk/openjdk11:alpine-jre

COPY --from=build target/spring-in-docker-1.2.jar spring-in-docker.jar

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "spring-in-docker.jar"]
Enter fullscreen mode Exit fullscreen mode
  1. Copy all required files to download the dependencies
  2. Download the dependencies - they will be part of a dedicated layer
  3. Now copy the sources; this will add another layer

Let's dive into the build image:

Layers ├────────────────────────────────────────────────────────────────────────────
  Size  Command
5.6 MB  FROM 31609b718dd2bed
 14 MB  apk add --no-cache tzdata --virtual .build-deps curl binutils zstd     && GL
 17 kB  #(nop) COPY multi:5542ba69976bc682acd7b679c22d8a0277609ba9f5b611fd518f87f209
235 MB  set -eux;     apk add --no-cache --virtual .fetch-deps curl;     ARCH="$(apk
 56 kB  #(nop) COPY dir:20c328136da94aa01b2b6fd62c88ef506a15b545aefeb1a1e13473572aee
 10 kB  #(nop) COPY file:08c603013feae81d794c29c4c1f489cc58a32bd593154cc5e40c6afa522
1.8 kB  #(nop) COPY file:f191db2f3a7fe2e434025c321ad8106112373b1aa0fa99f1a76c884bf61
100 MB  ./mvnw dependency:go-offline
 54 kB  #(nop) COPY dir:d2bd6e2521e5d990b16efb81ae8823e23ed2de826e833b331718b2211d6a # 1
 28 MB  ./mvnw package -DskipTests
Enter fullscreen mode Exit fullscreen mode
  1. Dependencies layer

With the last Dockerfile, we managed to solve two issues: the security one coming from the JDK, and the layering one. Still, we need to set the version manually when we build the image. There's no synchronization between the POM's and the image's.

Moreover, multistage builds are not compatible with skaffold. If you're used to automatically trigger deployments to a (local) Kubernetes cluster when you change the source code, forget about them.

Jib

Jib is a Maven plugin (also available for Gradle) provided by Google that elegantly solves the above issues.

The concept behind Jib is simple but clever. Java allows running JARs, but also standard Java classes. Outside the world of containers, the JAR makes for a good deployment unit. However, in the container world, a JAR is just an extra wrapper, as the container is the deployment unit.

Jib plugins hook into the build system to compile Java sources, copy the adequate resources in layers and create an image that runs the app in "exploded" (non-JAR) format.

<plugin>
  <groupId>com.google.cloud.tools</groupId>
  <artifactId>jib-maven-plugin</artifactId>
  <version>2.5.2</version>
  <configuration>
    <to>
      <image>${project.artifactId}:${project.version}</image> <!-- 1 -->
    </to>
  </configuration>
</plugin>
Enter fullscreen mode Exit fullscreen mode
  1. Automatically sync the version of the image with the POM's

Jib offers two goals: build to upload the image to a Docker repository, and dockerBuild to build to a Docker daemon. Let's create the image locally.

mvn compile com.google.cloud.tools:jib-maven-plugin:2.6.0
Enter fullscreen mode Exit fullscreen mode

dive outputs the following:

Layers ├────────────────────────────────────────────────────────────────────────────
  Size  Command
1.8 MB  FROM 7cfeac17984f4f4
 15 MB  bazel build ...
1.9 MB  bazel build ...
8.4 MB  bazel build ...
170 MB  bazel build ...
 16 MB  jib-maven-plugin:2.5.2
 12 MB  jib-maven-plugin:2.5.2
   1 B  jib-maven-plugin:2.5.2
5.8 kB  jib-maven-plugin:2.5.2
Enter fullscreen mode Exit fullscreen mode

Jib creates 4 layers, from oldest to most recent:

  1. Dependencies
  2. Snapshot dependencies
  3. Resources
  4. Compiled code

The second layer handles the case of SNAPSHOT dependencies: those are dependencies whose content can change despite having the same version number. This might be the case during development. You shouldn't deploy snapshot dependencies to production.

The command-line of the Docker container is akin to:

java -cp /app/resources:/app/classes:/app/libs/* ch.frankel.blog.springindocker.SpringInDockerApplication
Enter fullscreen mode Exit fullscreen mode

Besides, changing the parent image of the created image is straightforward:

<plugin>
  <groupId>com.google.cloud.tools</groupId>
  <artifactId>jib-maven-plugin</artifactId>
  <version>2.5.2</version>
  <configuration>
    <from>
      <image>adoptopenjdk/openjdk11:alpine-jre</image> <!-- 1 -->
    </from>
    <to>
      <image>${project.artifactId}:${project.version}</image>
    </to>
  </configuration>
</plugin>
Enter fullscreen mode Exit fullscreen mode
  1. Change the parent image to Alpine

Jib seems to be the best alternative. But let's continue to explore other options.

Spring Boot layered JAR

With version 2.3, Spring Boot allows creating a JAR with a dedicated folder structure. You can map those folders to layers in the Dockerfile. By default, those are:

  1. Dependencies
  2. Snapshot dependencies
  3. Spring Boot runtime
  4. Resources and compiled code

It's possible to customize those folders via a specific layers.xml file.

Here's a multi-stage build file that shows how to create a Spring Boot application with the default layers:

FROM adoptopenjdk/openjdk11:alpine-slim as builder

COPY .mvn .mvn
COPY mvnw .
COPY pom.xml .
RUN ./mvnw dependency:go-offline

COPY src src
RUN ./mvnw package -DskipTests                                            # 1

FROM adoptopenjdk/openjdk11:alpine-jre as layers

COPY --from=builder target/spring-in-docker-3.0.jar spring-in-docker.jar
RUN java -Djarmode=layertools -jar spring-in-docker.jar extract           # 2

FROM adoptopenjdk/openjdk11:alpine-jre

COPY --from=layers dependencies/ .                                        # 3
COPY --from=layers snapshot-dependencies/ .                               # 3
COPY --from=layers spring-boot-loader/ .                                  # 3
COPY --from=layers application/ .                                         # 3

ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]
Enter fullscreen mode Exit fullscreen mode
  1. Create a standard self-executable JAR
  2. Extract the folder structure
  3. Copy each folder in a layer

This approach has all the downsides of the Dockerfile described above: no integration with skaffold, and no synchronization with the POM's version.

Moreover, you should be careful to create the layers in the correct order.

Cloud-Native Buildpacks

Cloud-Native Buildpacks originate from Heroku's buildpacks. Heroku is one of the early Cloud hosting platforms. It also offers Git repositories. To deploy on Heroku, you just need to push the source to a remote Heroku repository.

The platform understands how to build an executable from sources. It checks for the presence of some files as hints. For example, if the repo contains a pom.xml file at the root, it activates the Maven buildpack; if it contains a package.json, it activates the Node.js one; etc.

CNBs are the revamp of Heroku's buildpacks, targeted at OCI containers. Heroku and VMWare Tanzu - the company behind Spring Boot, are spearheading the project. It's hosted at the CNCF.

To use a buildpack, just invoke the pack command with a builder reference, and the image tag to build. It will build the application, and inherit from the default parent image. For example, here's the command-line to build the sample app:

pack build --builder gcr.io/paketo-buildpacks/builder:base-platform-api-0.3 spring-in-docker:4.0
Enter fullscreen mode Exit fullscreen mode

It triggers the buildpacks that apply to the project:

===> DETECTING
[detector] 6 of 17 buildpacks participating
[detector] paketo-buildpacks/bellsoft-liberica 4.0.0
[detector] paketo-buildpacks/maven             3.1.1
[detector] paketo-buildpacks/executable-jar    3.1.1
[detector] paketo-buildpacks/apache-tomcat     2.3.0
[detector] paketo-buildpacks/dist-zip          2.2.0
[detector] paketo-buildpacks/spring-boot       3.2.1

[builder] Paketo BellSoft Liberica Buildpack 4.0.0
[builder]   https://github.com/paketo-buildpacks/bellsoft-liberica
[builder]   Build Configuration:
[builder]     $BP_JVM_VERSION              11.*            the Java version             # 1
[builder]   Launch Configuration:
[builder]     $BPL_JVM_HEAD_ROOM           0               the headroom in memory calculation
[builder]     $BPL_JVM_LOADED_CLASS_COUNT  35% of classes  the number of loaded classes in memory calculation
[builder]     $BPL_JVM_THREAD_COUNT        250             the number of threads in memory calculation
[builder]     $JAVA_TOOL_OPTIONS                           the JVM launch flags
Enter fullscreen mode Exit fullscreen mode
  1. Detect the JVM version. The buildpack downloads the correct JDK.

I've experienced several shortcomings:

  • The base-platform-api-0.3 is not immutable. The build worked previously; at the time of this writing, it fails with a Go bug.
  • The download of the JDK happens at every run, despite having been downloaded in previous runs.
  • I didn't find any easy to change the parent image.

Besides, as with Dockerfile, you need to manually tag the version.

Spring Boot plugin

With Spring Boot, it's not necessary to invoke an external command. The plugin offers the build-image target that does the same as pack, invoking the relevant buildpack.

Let's run it:

./mvnw spring-boot:build-image
Enter fullscreen mode Exit fullscreen mode 
[INFO]  > Running creator
[INFO]     [creator]     ===> DETECTING
[INFO]     [creator]     5 of 17 buildpacks participating
[INFO]     [creator]     paketo-buildpacks/bellsoft-liberica 4.0.0
[INFO]     [creator]     paketo-buildpacks/executable-jar    3.1.1
[INFO]     [creator]     paketo-buildpacks/apache-tomcat     2.3.0
[INFO]     [creator]     paketo-buildpacks/dist-zip          2.2.0
[INFO]     [creator]     paketo-buildpacks/spring-boot       3.2.1
Enter fullscreen mode Exit fullscreen mode

This option has a lot of benefits:

  • The image's version is automatically read from the POM's version.
  • Repeated builds with no changes are fast.
  • With a build configuration parameter, the final image has the 4 Spring Boot layers described above.

Moreover, some buildpacks make it easy to customize the build process. For example, to make the final artifact a native executable is just a matter of adding the necessary environment variable:

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <layers>
      <enabled>true</enabled>
    </layers>
    <image>
      <name>${project.artifactId}:${project.version}</name>
      <env>
        <BP_BOOT_NATIVE_IMAGE>true</BP_BOOT_NATIVE_IMAGE>
      </env>
    </image>
  </configuration>
</plugin>
Enter fullscreen mode Exit fullscreen mode

The biggest issue is that it's not easy to change the parent image.

Recap

Here are the final images, with their respective size. I also tagged images used in the multistage builds.

REPOSITORY                TAG          IMAGE ID       CREATED         SIZE
spring-in-docker          0.5          ca380d4677f9   3 days ago      177MB
spring-in-docker          1.0          f16667a974f4   3 days ago      363MB
spring-in-docker/build    1.1          2f2a59f49486   3 days ago      363MB
spring-in-docker          1.1          45ae57fab5ae   3 days ago      177MB
spring-in-docker/build    1.2          b94b6a80a437   3 days ago      383MB
spring-in-docker          1.2          cbddb2300b1a   3 days ago      177MB
spring-in-docker          2.0          fb7d8501623a   50 years ago    225MB
spring-in-docker          2.1          c3b60a214da2   50 years ago    177MB
spring-in-docker/build    3.0-b        1eea78545af2   2 days ago      206MB
spring-in-docker/build    3.0-a        52c180e9f3d1   2 days ago      383MB
spring-in-docker          3.0          9e2240a4fc00   2 days ago      177MB
spring-in-docker          5.0          4cbda769276f   40 years ago    264MB
spring-in-docker          5.5          4ac2d37253ee   40 years ago    184MB
Enter fullscreen mode Exit fullscreen mode
Build Version synch Layering Comments
Multistage No Manual
Jib Configuration Yes
Buildpack No Yes Buggy
Spring Boot Maven plugin Yes Configuration
  • Less flexible than multistage builds
  • Powerful parameterization depending on the buildpack

To go further:

Originally published at A Java Geek on October 11th, 2020

Image
Woodensure Diwali Offer | Huge Savings on Wooden Decor & Storage

diwalisale, diwalioffer, woodenfurniture, diningtable
Image
Mastering Bash: Essential Commands for Everyday Use

bash, linux, discuss, ubuntu
Image
A Look Into The Future: What Will The Outdoor Heaters For Patio Electric Industry Look Like In 10 Years?
Image
It's The Bifold Door Repair Case Study You'll Never Forget
Image
The Three Greatest Moments In Folding Powered Wheelchair History
Image
15 Reasons To Not Overlook Bi Folding Door Repair
Image
Top and Trusted Accounting Companies in India – HCO & Co.
Image
The Role of AI (ChatGPT) in Coding and Debugging: Striking a Balance
Image
SaaS Cost Optimization on AWS: Effective Strategies for Managing Cloud Expenses

aws, saas, costoptimization, saascostoptimizationonaws
Image
10 Life Lessons We Can Learn From Electricpatio Heater
Image
fnforex
Image
How To Explain Repairing Bifold Doors To Your Grandparents
Image
10 Key Mobile App Features of a Successful Mobile App

mobile, appdevelopment, mobileapps, appdevelopersusa
Image
From All Over The Web Here Are 20 Amazing Infographics About ADHD Assessment UK Cost
Image
The Most Significant Issue With How Much Is An ADHD Assessment, And How You Can Fix It
Image
Deterministic Functions in PLSQL

oracle, fullstack, devops, backend
Image
PP honeycomb boxes manufacturers

ppboxmanufacturer
Image
Forget Get Assessed For ADHD: 10 Reasons Why You Don't Really Need It
Image
5 Electric Patio Heater Myths You Should Stay Clear Of
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Terabox Video Player