Docker and Kubernetes for Java Developers

Jaroslaw Krochmalski

• Publisher: Packt Publishing
• Year: 2017
• ISBN:
  9781786463906
• Edition: 1
• Topic: Computer Science
• Subtopic: Programming in Java
• Index: Computer Science

Leverage the lethal combination of Docker and Kubernetes to automate deployment and management of Java applicationsAbout This Book• Master using Docker and Kubernetes to build, deploy and manage Java applications in a jiff• Learn how to create your own Docker image and customize your own cluster using Kubernetes• Empower the journey from development to production using this practical guide.Who This Book Is ForThe book is aimed at Java developers who are eager to build, deploy, and manage applications very quickly using container technology. They need have no knowledge of Docker and Kubernetes.What You Will Learn• Package Java applications into Docker images• Understand the running of containers locally• Explore development and deployment options with Docker• Integrate Docker into Maven builds• Manage and monitor Java applications running on Kubernetes clusters• Create Continuous Delivery pipelines for Java applications deployed to KubernetesIn DetailImagine creating and testing Java EE applications on Apache Tomcat Server or Wildfly Application server in minutes along with deploying and managing Java applications swiftly. Sounds too good to be true? But you have a reason to cheer as such scenarios are only possible by leveraging Docker and Kubernetes.This book will start by introducing Docker and delve deep into its networking and persistent storage concepts. You will then proceed to learn how to refactor monolith application into separate services by building an application and then packaging it into Docker containers. Next, you will create an image containing Java Enterprise Application and later run it using Docker. Moving on, the book will focus on Kubernetes and its features and you will learn to deploy a Java application to Kubernetes using Maven and monitor a Java application in production. By the end of the book, you will get hands-on with some more advanced topics to further extend your knowledge about Docker and Kubernetes.Style and approachAn easy-to-follow, practical guide that will help Java developers develop, deploy, and manage Java applications efficiently.

Creating Images with Java Applications

Now that we have a simple, but functional Java microservice based on Spring Bootstrap, we can go further. Before we deploy it using Kubernetes, let's package it as a Docker image. In this chapter, we will create a Docker image containing our application, and we will dockerize a Spring Boot application to run it in an isolated environment, a container.

Topics covered in this chapter will be:

• Creating a Dockerfile
• Dockerfile instructions
• Building the image
• Creating and removing images

Let's begin with the definition of a Dockerfile, which will be the definition of our container.

Dockerfile

As you will remember from Chapter 1, Introduction to Docker, the Dockerfile is kind of a recipe to build an image. It's a plain text file containing instructions which are executed by Docker in the order they are placed. Each Dockerfile has a base image that the Docker engine will use to build upon. A resulting image will be a specific state of a file system: a read-only, frozen immutable snapshot of a live container, composed of layers representing changes in the filesystem at various points in time.

The image creation flow in Docker is pretty straightforward and consists basically of two steps:

1. First, you prepare a text file named Dockerfile, which contains a series of instructions on how to build the image. The set of instructions you can use in the Dockerfile is not very broad, but sufficient to fully instruct Docker how to create an image.
2. Next, you execute the docker build command to create a Docker image based on the Dockerfile that you have just created. The docker build command runs within the context. The build's context is the files at a specified location, which can be a PATH or a URL. The PATH is a directory on your local filesystem and the URL is a Git repository location. A context is processed recursively. PATH will include any subdirectories. The URL will include the repository and its submodules.

If you create an image containing a Java application, you can also skip the second step and utilize one of the Docker Maven plugins available. After we learn how to build images using the docker build command, we will also create our image using Maven. When building using Maven, the context to the docker build command (or a build process, in this case) will be provided automatically by Maven itself. Actually, there is no need for the Dockerfile at all, it will be created automatically during the build process. We will get to this in a short while.

The standard name for a Dockerfile is just Dockerfile. It's just a plain text file. Depending on the IDE you use, there are plugins to provide Dockerfile syntax highlighting and autocompletion, which makes editing them a breeze. Dockerfile instructions use simple and clear syntax which makes them quite easy to understand, create, and use. They are designed to be self-explanatory, especially because they allow commenting just as properly written application source code. Let's get to know the Dockerfile instructions now.

Dockerfile instructions

We will begin with the instruction that every Dockerfile must have at the top, the FROM instruction.

FROM

This is the first instruction in the Dockerfile. It sets the base image for every subsequent instruction coming next in the file. The syntax for the FROM instruction is straightforward. It's just:

FROM <image>, or FROM <image>:<tag>, or FROM <image>@<digest>

The FROM instruction takes a tag or digest as a parameter. If you decide to skip them, Docker will assume you want to build your image from the latest tag. Be aware that latest will not always be the latest version of the image you want to build upon. The latest tag is kind of a special one. Also, it may not work as you may expect. Well, to cut a long story short, it doesn't mean anything special unless the image creator (openjdk or fabric8, for example) has a specific build, tag, and push pattern. The latest tag assigned to an image simply means that it's the image that was last built and executed without a specific tag provided. It's easy to understand that it may be confusing, pulling the image tagged latest will not fetch the latest version of the software.

Docker will not take care of checking if you are getting the newest version of the software when pulling the image tagged latest.

Docker will throw an error during the build if it cannot find a tag or digest you provide. You should choose the base image wisely. My recommendation would be to always prefer the official repositories that can be found on Docker Hub. By choosing an official image you can be pretty sure it will be of high quality, tested, supported, and maintained.

For containerizing a Java application, we have two options. The first one is to use a base Linux image and install Java using the RUN instruction (we will cover RUN in a while). The second option will be to pull an image containing the Java runtime already installed. Here you have a lot more to choose from. For example:

• openjdk: An official repository containing an open-source implementation of the Java platform, Standard Edition. The tag latest, which will be used if you do not specify any tag, points to the 8u121-alpine OpenJDK release, as of the time of writing this book
• fabric8/java-alpine-openjdk8-jdk: This base image is actually also being used by the fabric8 Maven plugin
• frolvlad/alpine-oraclejdk8: There are three tags you can choose from: full (only src tarballs get removed), cleaned (desktop parts get cleaned), slim, everything but the compiler and JVM is removed. The tag latest points to the cleaned one
• jeanblanchard/java: A repository containing images based on Alpine Linux to keep the size minimal (about 25% of an Ubuntu-based image). The tag latest points to Oracle Java 8 (Server JRE)

By registering and creating your account on the Docker Hub at https://hub.docker.com, you will get access to the Docker Store. It's available at https://store.docker.com. Try searching the Docker Store for Java-related images. You will find a lot of useful images to choose from, and one of them is the official Oracle Java 8 SE (Server JRE) image. This Docker image provides the Server JRE, a runtime environment specifically targeted for deploying Java in server environments. The Server JRE includes tools for JVM monitoring and tools commonly required for server applications. You can get this official Java Docker image by buying it on the Docker Store. Click Get Content, it's priced $0.00, so it will be available for your development purposes free of charge.

Take note that images coming from the Docker Store are bound to your Docker Hub account. Before you pull them or build your own images having them as the base image, you will need to the authenticate to Docker Store using the docker login command and your Docker Hub credentials.

For our purposes, let's choose jeanblanchard/java. It's the official Oracle Java running on top of the Alpine Linux distribution. The base image is small and fast to download. Our FROM instruction will look the same as this:

FROM jeanblanchard/java:8

If a FROM image is not found on your Docker host (on your local machine, for example), Docker will try to find and pull it out from the Docker Hub (or your private repository if you have it set up). All subsequent instructions in the Dockerfile will use the image specified in the FROM as a base starting point. That's why it's mandatory; a valid Dockerfile must have it at the top.

MAINTAINER

By using the MAINTAINER instruction, you set the Author field of the generated image. This can be your name, username, or whatever you would like as an author of the image that will be created by using the Dockerfile you are writing. This command can be placed anywhere in a Dockerfile, but good practice is to place it on the top of the file, just after the FROM instruction. This is a so-called, non-executing command, meaning that it will not make any changes to the generated image. The syntax, again, is very simple:

MAINTAINER authors_name

WORKDIR

The WORKDIR instruction adds a working directory for any CMD, RUN, ENTRYPOINT, COPY, and ADD instructions that comes after it in the Dockerfile. The syntax for the instruction is WORKDIR /PATH. You can have multiple WORKDIR instructions in one Dockerfile, if the relative path is provided; it will be relative to the path of the previous WORKDIR instruction.

ADD

What ADD basically does is copy the files from the source into the container's own filesystem at the desired destination. It takes two arguments: the source (<source path or URL>) and a destination (<destination path>):

ADD <source path or URL> <destination path >

The source can have two forms: it can be a path to a file, a directory, or the URL. The path is rel...