From Docker images to OpenShift + Docker Networks

On my last post, I talked about how to run the same set of Docker images using Docker, Docker Compose, Docker Machine, Docker Swarm and Kubernetes.

The purpose was to show a suggested learning path from raw Docker CLI to a distrubute Docker cluster (using Docker Swarm or Kubernetes).

As I promissed, I’ve updated this lab to include two new features that I want to show:

• Docker Networks

• OpenShift v3

Docker Networks

Since Docker 1.9, networking is now a first class citizen and ready to use with Docker Swarm and Compose.

With the introduction of Docker Networks, Docker Linking is expected to be deprecated and removed in a future release.

The environment consists in a WildFly container with Ticket Monster application connected to a Postgres container. To load balance the application, I use Apache httpd with mod_cluster. The overview diagram of this environment can be seen in the following picture:

Now, the docker-compose.yml file contains reference to a docker network called “mynet”. This network should be available before the execution of the container through the command docker network create mynet.

With multi-host networks available, the same docker-compose.yml file is now being used also on the Docker Swarm cluster instructions.

When a network is specified in Docker container, the /etc/hosts file of all other containers in the network is updated to include the name of the container. You can see this behaviour running the following commands:

$ docker network create mynet
$ docker run -d --name container1 --net mynet jboss/wildfly
$ docker run -d --name container2 --net mynet jboss/wildfly
$ docker run -d --name container3 --net mynet jboss/wildfly

$ docker exec container1 cat /etc/hosts
....
172.18.0.3	container2
172.18.0.3	container2.mynet
172.18.0.4	container3
172.18.0.4	container3.mynet

OpenShift v3

Another great addition was the inclusal of OpenShift instructions for the same lab.

One of the biggest differences is that OpenShift provides Routes feature that allows external host name mapping and load balancing. Due to this “native” feature, we don’t need to deploy mod_cluster as part of the lab environment.

Instead of using the default PostgreSQL image, OpenShift provides a Docker image for running PostgreSQL. This image can provide database services based on username, password, and database name settings provided via configuration.

After deploying the Database, the OpenShift README contains instructions to deploy the WildFly using two methods. Choose one:

• Using 3 CLI commands to deploy a POD, a Service and a Router, each one.
• Use a single command to deploy the POD, Service and Router defined in a YAML file.

One of the greatest contributions of this lab adition, is that it can also be used as an overview guide to run Docker images inside OpenShift.

Don’t forget to check the recently added OpenShift instructions

Conclusion

While following the instructions of github.com/rafabene/devops-demo, you will face 5 different ways to have the same environment being executed with only Docker tools (Compose, Machine, Swarm) and also with Kubernetes and OpenShift.

Executing it in the proposed order can provide you a didatic guide on how they are related to each other. This lab can also be used as a template for your most of middleware containers and applications, and at the same time, You will be in touch with the latest version and features of the Docker universe since I plan to continue updating this test environment frequently.