How to build a docker container for a Java application

Question

What I want to do is build a docker image for my Java application but the following considerations should be true for most compiled languages.

problem

On my build server I want to produce a docker image for my application as the deliverable. For this I have to compile the application using some build tool (typically Gradle, Maven or Ant) and then add the created JAR file to the docker image. As I want the docker image to just execute the JAR file I will of course start from a base image with Java already installed.

There are three ways of doing this:

let the build tool control the process

In this case my build tool controls the whole process. So it prepares the JAR file and after the JAR is created it calls Docker to create the image. This works as the JAR is created beforehand and Docker can be oblivious of the build process needed to create the JAR.

But my Dockerfile is no longer standalone. It depends on steps to happen outside of Docker for it work. In my Dockerfile I will have a COPY or ADD statement that is supposed to copy the JAR file to the image. This statement will fail when the jar is not created beforehand. So just executing the Dockerfile might not work. This becomes a problem if you want to integrate with services that just build using the present Dockerfile like the auto-build feature on DockerHub.

let Docker control the build

In this case all necessary steps to create the image are added to the Dockerfile so the image can be created by just executing the Docker build.

The main problem with this approach is that there is no way to add to a Dockerfile commands that should be executed outside the docker image being created. This means I have to add my source code and my build tools to the docker image and build my JAR file inside the image. This will result in my image being bigger than it has to be due to all the files added that will be unnecessary at runtime. This will also add extra layers to my image.

Edit:

As @adrian-mouat pointed out if I would add the sources, build the application and deleted the sources in one RUN statement I could avoid adding unnecessary files and layers to the Docker image. This would mean creating some insane chained command.

two separate builds

In this case we split our build in two: first we create the JAR file using our build tool and upload it to a repository (Maven or Ivy repository). We then trigger a separate Docker build that just adds the JAR file from the repository.

conclusion

In my opinion the better way would be letting the build tool control the process. This is will result in a clean docker image and as the image is what we want to deliver this is of importance. To avoid having a potentially not working Dockerfile lying around this should be created as part of the build. So no one would accidentally use it to start a broken build.

But this will not allow me to integrate with DockerHub.

question

Is there another way I am missing?

update June 2020

In the years since I first created this question a lot of stuff has changed. At this point I would advocate using Googel's JIB Tool. It integrates with the most common Java Build Tools (Maven and Gradle) and allows you to create container directly from your build. This is much more concise than any of the old approaches I considered all these years ago.

update February 2021

I found this blog post and video from James Ward that reflects better what is currently state of the art. https://cloud.google.com/blog/topics/developers-practitioners/comparing-containerization-methods-buildpacks-jib-and-dockerfile

Solution 1

The docker registry hub has a Maven image that can be used to create java containers.

Using this approach the build machine does not need to have either Java or Maven pre-installed, Docker controls the entire build process.

Example

├── Dockerfile
├── pom.xml
└── src
    ├── main
    │   ├── java
    │   │   └── org
    │   │       └── demo
    │   │           └── App.java
    │   └── resources
    │       └── log4j.properties
    └── test
        └── java
            └── org
                └── demo
                    └── AppTest.java

Image is built as follows:

docker build -t my-maven .

And run as follows:

$ docker run -it --rm my-maven
0    [main] INFO  org.demo.App  - hello world

Dockerfile

FROM maven:3.3-jdk-8-onbuild
CMD ["java","-jar","/usr/src/app/target/demo-1.0-SNAPSHOT-jar-with-dependencies.jar"]

---

Update

If you wanted to optimize your image to exclude the source you could create a Dockerfile that only includes the built jar:

FROM java:8
ADD target/demo-1.0-SNAPSHOT-jar-with-dependencies.jar /opt/demo/demo-1.0-SNAPSHOT-jar-with-dependencies.jar
CMD ["java","-jar","/opt/demo/demo-1.0-SNAPSHOT-jar-with-dependencies.jar"]

And build the image in two steps:

docker run -it --rm -w /opt/maven \
   -v $PWD:/opt/maven \
   -v $HOME/.m2:/root/.m2 \
   maven:3.3-jdk-8 \
   mvn clean install

docker build -t my-app .

__

Update (2017-07-27)

Docker now has a multi-stage build capability. This enables Docker to build an image containing the build tools but only the runtime dependencies.

The following example demonstrates this concept, note how the jar is copied from target directory of the first build phase

FROM maven:3.3-jdk-8-onbuild 

FROM java:8
COPY --from=0 /usr/src/app/target/demo-1.0-SNAPSHOT.jar /opt/demo.jar
CMD ["java","-jar","/opt/demo.jar"]

Solution 2

Structure of java aplication

Demo
└── src
|    ├── main
|    │   ├── java
|    │   │   └── org
|    │   │       └── demo
|    │   │           └── App.java
|    │   └── resources
|    │       └── application.properties
|    └── test
|         └── java
|               └── org
|                   └── demo
|                         └── App.java  
├──── Dockerfile
├──── pom.xml

Content of Dockerfile

FROM java:8
EXPOSE 8080
ADD /target/demo.jar demo.jar
ENTRYPOINT ["java","-jar","demo.jar"]

Commands to build and run image

• Go to the directory of project.Lets say D:/Demo

$ cd D/demo
$ mvn clean install
$ docker build demo .
$ docker run -p 8080:8080 -t demo

Check that container is running or not

$ docker ps

The output will be

CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                    NAMES
55c11a464f5a        demo1               "java -jar demo.jar"   21 seconds ago      Up About a minute   0.0.0.0:8080->8080/tcp   cranky_mayer

Solution 3

The easiest way is to let the build tool control the process. Otherwise, you would have to maintain your build tool's build file (like pom.xml for Maven or build.gradle for Gradle) as well as a Dockerfile.

A simple way to build a Docker container for your Java app is to use Jib, which is available as Maven and Gradle plugins.

For example, if you are using Maven and want to build your container to your running Docker daemon, you can just run this one command:

mvn compile com.google.cloud.tools:jib-maven-plugin:0.9.2:dockerBuild

You can also build directly to a Docker registry with Jib without needing to install docker, run a Docker daemon (which requires root privileges), or write a Dockerfile. It's also faster and builds images reproducibly.

See more about Jib at its Github repo: https://github.com/GoogleContainerTools/jib

Solution 4

We used the Spotify Docker Maven Plugin for a while. The plugin allows you to bind a Docker build it to a phase of the Maven lifecycle.

An example: Run the Docker build after packaging (phase: package) your application by configuring the plugin to add your built application as a resource to the Docker build context. In the deploy phase run the Docker push goal to push your Docker image to a registry. This can run beside the normal deploy plugin, which publishes the artifact into a repository like Nexus.

Later on, we splitted the build into two separate jobs on the CI server. Since Docker is just a one way to run your application (sometimes we need the released application on different environments not only Docker), the Maven build should not rely on Docker.

So the first job releases the application in Nexus (via Maven deploy). The second job (which can be a downstream dependency of the first job) downloads the latest release artifact, performs the Docker build and pushes the image to the registry. For downloading the latest release we use the Versions Maven Plugin (versions:use-latest-releases) as well as the Maven Dependency Plugin (dependency:get and dependency:copy).

The second job can also be started for specific version of the application to (re)build the Docker image for an older release. Moreover you can use a build pipeline (on Jenkins), which executes both jobs and passes the release version or the release artifact to the Docker build.

Solution 5

Containerize your java application using Jib tool without writing dockerfile

Jib is an open-source Java tool maintained by Google for building Docker images of Java applications. It simplifies containerization since with it, we don’t need to write a dockerfile. And actually, we don’t even have to have docker installed to create and publish the docker images ourselves.

Google publishes Jib as both a Maven and a Gradle plugin. https://github.com/GoogleContainerTools/jib

Containerize your java application using Maven project

https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#quickstart

Containerize your java application using Gradle project

https://github.com/GoogleContainerTools/jib/tree/master/jib-gradle-plugin#quickstart

View more solutions

Comments

[Tobias Kremer]

How is this different from installing the build tools (in this case Maven) myself? You would still end up with a docker image that does contain not required files like the sources and Maven.

[Mark O'Connor]

@TobiasKremer Updated example to illustrate how to build a container excluding the source.

[Stephane]

Where is this my-maven coming from ? How is the Maven build tool present if we use the updated Dockerfile that is based on java:8 only ?

[Mark O'Connor]

@Stephane The first example uses a base image that contains both Java and Maven. The source code is built inside the container. The second example is in response to Tobias comment that he preferred the source not to be inside the container, requiring a two step process, firstly to build the jar secondly to create a container containing a Java base image and the built jar.

[DarioBB]

I have a question to Mark O'Connor regarding this: In bold part Dockerfile, where you used onbuild image, you've put path to .jar like: "/usr/src/app/". I wonder how to you know is correct path? I'm trying to make mvn package inside docker but I can't figure out where docker actually stores .jar inside of it. How to find out that?

[Mark O'Connor]

@DarioBB The Docker file used to build the "maven:3.3-jdk-8-onbuild" image sets the working directory to /usr/src/app and copies the local files into this location. See: github.com/carlossg/docker-maven/blob/…. How did I discover this Docker file? Linked from DockerHub: hub.docker.com/_/maven

[DarioBB]

Mark, and without onbuild it doesen't have working directory.. how is that so? github.com/carlossg/docker-maven/blob/… Does it mean that if I'm using it files will nowhere be saved (for example my jar which I am trying to do with mvn package inside docker?

[DarioBB]

What if you try to generate your .jar inside docker, what would be path for it? For example using: RUN ["mvn", "verify"] See please if you can answer to this question: stackoverflow.com/questions/41491698/…

[Mark O'Connor]

@DarioBB You've quoted the Docker file for the "maven:3-jdk-8" image, used to build the base image of "maven:3.3-jdk-8-onbuild". One creates an image with Maven installed, the second layers on top the ONBUILD instructions. The result is cumulative. Docker images are multi-layered

[Mark O'Connor]

@DarioBB Yes, you could use the "maven:3-jdk-8" as your base, place the source code wherever you want, set your own working directory and run your own "mvn" command. Personally I prefer the convenience of using the onbuild image. Nice to have options :-)

[DarioBB]

But where would be my .jar stored in docker? I just cannot grab proper .jar or something is wrong in maven compilation on docker side in my example

[Mark O'Connor]

@DarioBB Review the Dockerfile for the onbuild image again. It sets the working directory to "/usr/src/app". Secondly it provides two ONBUILD instructions. The first will copy your source code to "/usr/src/app" and the second will run "mvn install". What does that mean? Your jar file will be created inside the "/usr/src/app/target" directory

[Mark O'Connor]

Let us continue this discussion in chat.

[Mike D]

Looks like that maven repo is no longer providing "onbuild" images for new versions of maven.

[Koray Tugay]

Is this answer up to date?

[Mark O'Connor]

This answer has been updated recently. stackoverflow.com/questions/27767264/…

[Jacques Koorts]

Docker images. Not Docker containers. Your link points to building images, but you write containers.

[Jacques Koorts]

I prefer jib. As baeldung said: "There are a couple of other tools out there, too, like Spotify’s docker-maven-plugin and dockerfile-maven plugins, though the former is now deprecated and the latter requires a dockerfile."

[Galigator]

You save my day, the command you give is better than the one in the documentation.

[matbrgz]

Note that Maven is not designed for sharing ~/.m2/repo. You should only do this in situations where it is certain only one instance run at a time.