In previous segments, we discussed how to collect project dependencies, and use Maven, Gradle, and the Spring Maven Gradle plugin to organize your project dependencies in a maintainable and traceable fashion. In this post, we’re going to take that setup and create a clean, reproducible build using Docker.
A containerized application’s lifecycle is composed of several steps:
- Defining the container
- Building the container
- Tagging the container
- Pushing the container to a registry
- Running the container
We’ll be using Docker as our containerization technology, but it’s not the only option. Ensure that it’s installed for your platform before you continue.
Note that these instructions are intended for Linux-based machines. Containers differ from VMs in a very important way, namely that containers share the OS kernel of their container host.
What this means is that, say that my host operating system is Debian, based on Linux Kernel 126.96.36.199-amd64 x86_64. Even if my container uses a different OS base (say, Ubuntu), the container and the host should be kernel-compatible (so, no Linux Kernel 3.10.x-ARM, for instance.)
These considerations are rarely an issue for many software projects. We use Debian-based containers because they’re similar to our dev environments and tooling, but Alpine is a really good option for many projects and has some advantages in production (e.g. resource utilization is anecdotally better.)
Step 1: Defining the Container
In the same way that we identified the compile and runtime dependencies of our project in the first series, let’s think about what we need to build the project. On my development system, I typically build a project by building and publishing the project’s Bill-Of-Materials POMs (
mvn clean install -f bom), then by building the project’s artifacts with Gradle and publishing them to my local Maven repository (
gradle clean build publishToMavenLocal, or, with Gradle’s nifty shortcuts
gradle cle b pTML). So, I obviously need Gradle and Maven installed in my container.
So, what we’re going to do here is:
- Install the correct version of Java
- Download Maven from the Maven project site and install it into the container
- Download Gradle from the Maven project site and install it into the container
Let’s see if we can get rid of any of these steps by selecting the correct base container. Searching Docker hub, I see that Oracle provides JDK images.
My Dockerfile becomes simply:
FROM openjdk:8u141-jdk ENTRYPOINT /bin/bash
Breaking down these instructions:
FROM openjdk:8u141-jdk says, “ask the local Docker registry to find an image with ID
openjdk:8u141-jdk and derive from that. If you can’t find that image locally, reach out to hub.docker.com and see if it’s there`
Building the container pulls the base image, then executes all of the commands in the Dockerfile, which produces a new container:
Sending build context to Docker daemon 220.7kB Step 1/2 : FROM openjdk:8u141-jdk 8u141-jdk: Pulling from library/openjdk 3e17c6eae66c: Already exists 74d44b20f851: Already exists a156217f3fa4: Already exists 4a1ed13b6faa: Already exists 77980e5d0a6d: Already exists 5458607a81d3: Already exists e34cf8338f42: Already exists 2f3d3da5c56e: Already exists 2ade7a861e3f: Already exists Digest: sha256:4b0c879909b729d67d13e5004f5564df85a5f9c1c3820c13e41151edf1f1b1c0 Status: Downloaded newer image for openjdk:8u141-jdk ---> 74c95c985a85 Step 2/2 : ENTRYPOINT /bin/bash ---> Running in a4bd5943abcd Removing intermediate container a4bd5943abcd ---> b1c22add1692 Successfully built b1c22add1692 # <-- IMPORTANT, this is your container ID, referenced as $CID.
We can check this new container out by running
docker run -it --rm $CID which will drop you into a shell that looks something like:
Now, most base containers don’t have many programs installed. The JDK base containers do have Java, which is the important one.
Now, we can install Maven and Gradle really quickly.
Installing the Prerequisites
I like wget for simple downloads, but curl would work just as well. But we need to install Git anyway, so add:
RUN apt-get update RUN apt-get install -y git-core wget
To your Dockerfile and build:
Sending build context to Docker daemon 220.7kB Step 1/4 : FROM openjdk:8u141-jdk ---> 74c95c985a85 Step 2/4 : RUN apt-get update ---> Running in 2bfa3d396ac6 Get:1 http://security.debian.org stretch/updates InRelease [94.3 kB] Ign:2 http://deb.debian.org/debian stretch InRelease Get:3 http://deb.debian.org/debian stretch-updates InRelease [91.0 kB] Get:4 http://deb.debian.org/debian stretch Release [118 kB] Get:5 http://deb.debian.org/debian stretch Release.gpg [2434 B] Get:6 http://deb.debian.org/debian stretch-updates/main amd64 Packages [12.1 kB] Get:7 http://deb.debian.org/debian stretch/main amd64 Packages [9530 kB] Get:8 http://security.debian.org stretch/updates/main amd64 Packages [468 kB] Fetched 10.3 MB in 1s (5807 kB/s) Reading package lists... Removing intermediate container 2bfa3d396ac6 ---> 4984ada9d0c8 Step 3/4 : RUN apt-get install -y git-core wget ---> Running in 6e6a79b1c1ab Reading package lists... Building dependency tree... Reading state information... The following NEW packages will be installed: git-core The following packages will be upgraded: wget 1 upgraded, 1 newly installed, 0 to remove and 64 not upgraded. Need to get 801 kB of archives. After this operation, 8192 B of additional disk space will be used. Get:1 http://deb.debian.org/debian stretch/main amd64 wget amd64 1.18-5+deb9u1 [800 kB] Get:2 http://deb.debian.org/debian stretch/main amd64 git-core all 1:2.11.0-3+deb9u2 [1410 B] debconf: delaying package configuration, since apt-utils is not installed Fetched 801 kB in 0s (3242 kB/s) (Reading database ... 29522 files and directories currently installed.) Preparing to unpack .../wget_1.18-5+deb9u1_amd64.deb ... Unpacking wget (1.18-5+deb9u1) over (1.18-5) ... Selecting previously unselected package git-core. Preparing to unpack .../git-core_1%3a2.11.0-3+deb9u2_all.deb ... Unpacking git-core (1:2.11.0-3+deb9u2) ... Setting up wget (1.18-5+deb9u1) ... Setting up git-core (1:2.11.0-3+deb9u2) ... Removing intermediate container 6e6a79b1c1ab ---> 67169937ccdd Step 4/4 : ENTRYPOINT ["/bin/bash"] ---> Running in cd4e07152d23 Removing intermediate container cd4e07152d23 ---> 2c1ab0b17981 Successfully built 2c1ab0b17981
Now, your container will have both
Setting Environment Variables
If you define an
ENV variable in Docker, the value of that
ENV can either be passed into the container, or you can specify a default value (or both). We want to be able to reference (and change) both the Gradle version and the Maven version so that if we want to upgrade either, we just pass in new versions when we’re building the container and viola!
# Environment Variables ENV PROJECT_NAME workspace ENV GRADLE_VERSION 4.3.1 ENV MAVEN_VERSION 3.5.2 ENV BASE_PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Now, when we run the container, we have access to those environment variables:
echo $GRADLE_VERSION 4.3.1
RUN mkdir -p /opt/build/tools/gradle #Create directory for gradle RUN wget https://services.gradle.org/distributions/gradle-$GRADLE_VERSION-bin.zip -O /opt/build/tools/gradle.zip # Download gradle from gradle.org RUN unzip -d /opt/build/tools/gradle /opt/build/tools/gradle.zip # Unzip gradle ENV GRADLE_HOME=/opt/build/tools/gradle/gradle-$GRADLE_VERSION/bin #Export gradle location as GRADLE_HOME
Now, one really sweet thing about Docker is that, each of these commands defines a new layer. If the textual value of the command that builds a layer doesn’t change, then that layer is retrieved from the layer cache upon subsequent builds. What this means is that the URL for the Gradle download could change, and that wouldn’t break our container.
RUN mkdir -p /opt/build/tools/maven RUN wget http://www-eu.apache.org/dist/maven/maven-3/$MAVEN_VERSION/binaries/apache-maven-$MAVEN_VERSION-bin.zip \ -O /opt/build/tools/maven.zip RUN unzip -d /opt/build/tools/maven /opt/build/tools/maven.zip ENV MAVEN_HOME=/opt/build/tools/maven/apache-maven-$MAVEN_VERSION/bin
Once these have all executed, we have a container with Maven, Gradle, and Git installed and ready to use! In the next post, I’ll discuss how to store credentials securely and pass them into the container so that we can pull our project from source-control and build it.
Of course, if you don’t want to maintain your own, this base image is available on docker hub as