Docker and Kubernetes for Java Developers

To make your container able to communicate with the outside world, whether another server or another Docker container, Docker provides different ways of configuring networking. Let's begin with the network types which are available for our containers.

Docker network types

There are three different network types Docker delivers out of the box. To list them, execute the docker network ls command:

$ docker network ls

Docker will output the list of available networks containing the unique network identifier, its name, and a driver which powers it behind the scenes:

To have an overview of the differences between various network types, let's describe them now one by one.

Bridge

This is the default network type in Docker. When the Docker service daemon starts, it configures a virtual bridge, named docker0. If you do not specify a network with the docker run -net=<NETWORK> option, the Docker daemon will connect the container to the bridge network by default. Also, if you create a new container...

The parent command for managing networks in Docker is docker network. You can list the whole command set using the docker network help command, as you can see in the following screenshot:

To have a detailed syntax and description of each option available for a specific command, use the -help switch for each of the commands. For example, to get the description of parameters available for docker network create, execute the docker network create -help.

Let's briefly describe each command available:

Let's create a network. We are going to call our network myNetwork. Execute the following command from the shell or command line:

$ docker network create myNetwork

This is the simplest form of the command, and yet it will probably be used the most often. It takes a default driver (we haven't used any option to specify a driver, we will just use the default one, which is bridge). As the output, Docker will print out the identifier of the newly created network:

You will later use this identifier to refer to this network when connecting containers to it or inspecting the network's properties. The last parameter of the command is the network's name, which is a lot more convenient and easier to remember than the ID. The network name in our case is myNetwork. The docker network create command takes more parameters, as shown in the following table:

Now we have our myNetwork ready, we can run the Docker container and attach it to the network. To launch containers, we are going to user the docker run --net=<NETWORK> option, where the <NETWORK> is the name of one of the default networks or the one you have created yourself. Let's run Apache Tomcat for example, which is an open source implementation of the Java Servlet and JavaServer pages technologies:

docker run -it --net=myNetwork tomcat

It will take a while. The Docker engine will pull all of the Tomcat's image layers from the Docker Hub and then run the Tomcat container. There's another option to attach the network to the container, you can inform Docker that you would like the container to connect to the same network as other containers use. This way, instead of specifying a network explicitly, you just instruct Docker that you want two containers run on the same network. To do this, use the container: prefix, as in the following example...

A common scenario is usually when you want your containerized application to accept incoming connections, either from other containers or from outside of Docker. It can be an application server listening on port 80 or a database accepting incoming requests.

An image can expose ports. Exposing ports means that your containerized application will listen on an exposed port. As an example, the Tomcat application server will listen on the port 8080 by default. All containers running on the same host and on the same network can communicate with Tomcat on this port. Exposing a port can be done in two ways. It can be either in the Dockerfile with the EXPOSE instruction (we will do this in the chapter about creating images later) or in the docker run command using the --expose option. Take this official Tomcat image Dockerfile fragment (note that it has been shortened for clarity of the example):

FROM openjdk:8-jre-alpineENV CATALINA_HOME /usr/local/tomcatENV PATH ...

As you remember from Chapter 1, Introduction to Docker, the Docker container filesystem is kind of temporary by default. If you start up a Docker image (that is, run the container), you'll end up with a read-write layer on top of the layers stack. You can create, modify, and delete files as you wish; if you commit the changes back into the image, they will become persisted. This is a great feature if you want to create a complete setup of your application in the image, altogether with all its environment. But, this is not very convenient when it comes to storing and retrieving data. The best option would be to separate the container life cycle and your application from the data. Ideally, you would probably want to keep these separate, so that the data generated (or being used) by your application is not destroyed or tied to the container life cycle and can thus be reused.

The perfect example would be a web application server: the Docker image contains web server software...

The basis of volume-related commands is docker volume. The commands are as follows:

Similar to network-related commands, you can get the detailed description and all the possible options for each command if you execute it with the -help switch, for example: docker volume create -help. Let's begin with creating a volume.

As you remember from Chapter 1, Introduction to Docker, there's a settings screen in Docker for Windows or Docker for Mac, that allows us to specify which drives Docker can have access to. For a start, let's mark drive D in our Docker for Windows to make it available for Docker containers:

For the purpose of our volume examples, I've created a docker_volumes/volume1 directory on my D drive and created an empty data.txt file inside:

There are two ways to create volumes. The first one is to specify the -v option when running an image. Let's run the busybox image we already know and, at the same time, create a volume for our data:

$ docker run -v d:/docker_volumes/volume1:/volume -it busybox

In the previous command, we have created a volume using the -v switch and instructed Docker that the host directory d:/docker_volumes/volume1 should be mapped into the /volume directory in the running container. If we now list the contents of the /volume directory in the running busybox container...

The same as with creating volumes, there are two ways of removing a volume in Docker. Firstly, you can remove a volume by referencing a container's name and executing the docker rm -v command:

$ docker rm -v <containerName or ID>

Docker will not warn you, when removing a container without providing the -v option, to delete its volumes. As a result, you will have dangling volumes—volumes that are no longer referenced by a container. As you remember, they are easy to get rid of using the docker volume prune command.

Another option to remove the volume is by using the docker volume rm command:

$ docker volume rm <volumeName or ID>

If the volume happens to be in use by the container, Docker Engine will not allow you to delete it and will give you a warning message:

As you can see, creating, sharing, and removing volumes in Docker is not that tricky. It's very flexible and allows the creating a setup you will need for your applications. But there's more to this flexibility...

The same as with network driver plugins, volume plugins extend the capabilities of the Docker engine and enable integration with other types of storage. There are a ton of ready to use plugins available for free on the Internet; you can find a list on Docker's GitHub page. Some of them include:

In this chapter, we have learned about Docker networking and storage volume features. We know how to differentiate between various network types, how to create a network, and expose and map network ports.

We've been through volume-related commands and can now create or remove a volume. In Chapter 3, Working with Microservices, we are going to focus on the software that we are going to deploy using Docker and Kubernetes, and later, Java microservices.