The Journey Continues

This blog has been silent for a while. Reason is that I moved into a different role at IBM, with more focus on Cloud solutions, and less focus on the mainframe. Therefore, the blog will remain silent. I will let the blog active, as I still see quite a number of hits from search engines, so some articles seem a good reference.

However, there is a now blog on the horizon, that continues the exciting topic how Mainframe and Cloud technologies are a great complement: Alice Frosi blogs at https://containersonibmz.com/. I strongly suggest to take a look there and follow Alice's blog, as she is right at the cutting edge of this journey.

Thank you for visiting this place, for your questions and feedback. Enjoy how the future is shaped.

Book about Docker on Z

IBM has published a very nice document about Docker on the mainframe.

It is available as PDF download as well as via Knowledge Center. You can read one of the best container/Docker introductions I've seen on the Internet, as well as a good coverage of basic concepts around containers and Docker in the context of Z.
Chapter overiew:

SLES12 officially supports Docker

Since end of 2015, SUSE also provides Docker on z through their "containers module" on top of SLES 12 (SP1). This makes SUSE the first one of the big enterprise distributions to support Docker on z Systems commercially. The package also contains base images for conveniently starting. Having decoupled Docker from the SLES 12 base vehicle through a module is a goodness, this allows for independent updates on a potentially higher frequency.

The Mainframes of Real Containers

In some time off, I was able to study some serious container setups. Here are some impressions of the mainframes of real world containers (so you might be able to figure out where I have been to).
IMHO it becomes apparent that large scale deployments provide the best economics for container service providers, and the entire world's economy relies on it.

Drilling Holes Into Containers

Container management software is often deployed in containers itself. But how can code running inside a container look at other containers? Let's have a look how components like cAdvisor and datadog agents can gather that sort of data.

Virtualization vs. Containerization

Containers provide isolated runtime environments for applications: the entire user space environment is exclusively presented to the container, and any changes to it do not impact other containers' environments. To provide this isolation, a combination of OS-based mechanisms is used: Linux name spaces are used for isolation and scoping mechanism. File system mounts define what files are accessible to the container. cgroups define resource consumption of containers. Still all containers share the same OS kernel which can realize memory footprint efficiencies when identical libraries are used by multiple containers.

With system virtualization, the hypervisor provides a full virtual machine to a guest: the entire OS image including the kernel is now dedicated to the virtual machine. CPU virtualization is used to provide each guest with an exclusive view of a full system environment, and these mechanisms also ensure isolation from other guests. Hypervisor-based management of virtual CPUs, memory and I/O devices is used to define resource consumption of guests.

Which one is better?

Dockerfiles

Starting a container, doing manual changes to it and committing into a new image is error-prone and does not scale for handling many images. In this post, I will show a powerful and more precise way of shaping new images.

This method uses a file called Dockerfile to control how new images are built. It is placed in a directory and consists of keyword-parameter lines. Let's take a look:

[root@r1745042 ~]# cat apache/Dockerfile
FROM rhel7-yum
RUN yum -y install httpd
COPY index.html /var/www/html/index.html

First Steps with Docker

Docker is platform-agnostic and relies on Linux kernel functionality which is present on most platforms, including s390x (IBM z Systems). Its commands are identical on every platform, so there are lots of resources on the Internet which work for z Systems z.
However, Docker only executes native z code and does not emulate anything: you need to work with containers which contain s390(x) binaries, not e.g. x86 binaries.

This post shows how containers are created, used, and modified. For all of these commands, an online help is available: docker --help shows an overview of all commands, and docker COMMAND --help shows more specifics on the specified command.

Docker

Docker provides a comprehensive tool to create, deploy, manage and run containers. In a normal setup, it bases on container technology as well as on Linux control groups and copy-on-write file systems to achieve good manageability and efficiency during execution of containers. Docker distinguishes between images and containers: images are a set of files used to run a container instance. A container is a runnable instance of an image.

What Are Containers?

A container provides an envelope for running an application. Only resources assigned to the container are visible inside the container. All containers running in a system use the same OS kernel, but they don't have visibility to each other. A containerized application usually comes as a set of self-contained files, eliminating all dependencies into the host OS environment.