Docker 1.8.3 on developerWorks

The Linux on z Systems Docker page on developerWorks now carry links to new binaries -- version 1.8.3 is available for SLES 12 and RHEL 7.1.

docker-machine on z Systems

Recent posts have shown how to get compose, swarm, and the registry working. Of the prominent docker tools, the last one missing is docker-machine. machine is a tool that turns a Linux server into a Docker host. It can even create the server in the first place, e.g. in various public Cloud environments or through OpenStack. https://docs.docker.com/machine/ is the starting point of the documentation.

Let's see how docker-machine can be adapted for Linux on z Systems. Caution: long post.
We will use the generic driver which uses an existing Linux image as starting point, and uses its ssh access to make it a Docker host. First step -- let's setup the build environment for machine.

Container Patterns

Containers can be deployed in several ways, depending on goals and usage scenarios. Let's have a look at typical patterns and view this in light of z Systems:

New Docker Binaries on developerWorks

The Docker page on developerWorks provides links to new Docker binaries. They are now at version 1.8.2 and provided for SLES 12 and RHEL 7.1.
Building this took a while: for proper operation, two fixes from glibc (1 and 2) would be required. However, installing a modified glibc on your system is not required, since the Docker binaries come with code working around the defects in glibc.

Docker and z/VM or KVM?

At LinuxCon, KVM for z has been announced. From a Docker perspective, what does KVM change over a z/VM environment? There's a pretty short answer: nothing. KVM is cool for a number of things, z/VM is still king of the road, PR/SM still has got some bragging rights, and Docker doesn't care, as long as a Linux runs in it. Docker under both z/VM and KVM benefits from complementing technologies.

Closing Another Base Image Gap

Most recently, I mentioned (here and here) how to best deal with the fact that Ubuntu is widely used as base image, but does not exist on z Systems. A sufficiently close Debian is a decent solution for that.

Today's announcement at LinuxCon shows how this will get even easier: Ubuntu will be made available on z Systems. This will make all "FROM ubuntu" images no-brainers.

Image Decomposition

Looking at the swarm image we built previously, it's a couple of hundred MB in size -- for a small application. This image size will not slow down execution, since only files are touched which are needed when the application starts, but it will still be offending an aesthete's eye. Specifically for mainframers who have tried to save on every bit, because their core memory only had a couple of them (my knowledge is entirely anecdotal...). How can we kill that pain?