Elastic Stack on Z

The Elastic Stack, also known as ELK stack, is a popular choice to manage logs. ELK is an acronym for its three main components Elasticsearch, Logstash and Kibana; Elastic Stack is the more recent name for it. ELK is written in Java and maintained by Elastic. The three building blocks have a clear separation of duty:

• Elasticsearch is a database for storing
• Logstash ingests logs in various formats and can transform them for efficient processing with Elasticsearch
• Kibana is a graphical, web-based front end to Elasticsearch

E, L and K can operate in a Linux on IBM Z environment. IBM's Common Data Provider can even handle z/OS logs like SMF data. Here's how to run ELK on the mainframe -- of course in containers:

"FROM golang" -- revisited

In this post, we created an image that deals with go-based containers. When tagging it golang, building works out of the box for most Dockerfiles.
Now that golang has been ported to s390x, we can look at this again, creating a golang image that bases on golang rather than gccgo:

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:

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.

Portability Series: A Go Environment

Previously we looked at the portability of container setups. One of the observations is that a lot of containers are based on a Go environment -- take swarm or the registry. On x86, that usually means golang, but we have gccgo on s390. Let's see, how we can deal with this difference.

Portability Series: Usage of a Debian Base Image: compose

So we have created a Debian base image and are looking at some of the steps to run containers which may have platform dependencies. An example which brings this together is one of the Docker ecosystem components: compose. Docker compose lets you define applications which consist of several containers. You can the manage your entire multi-container application with single commands.
Let's get the code for compose:

Portability Series: Another Base Image

In the previous post, we looked at various challenges when moving existing (read: x86) container setups onto z Systems. One challenge is the widespread use of Ubuntu as Docker base images. The closest thing on z is Debian having roughly the same packaging structure and naming.

Let's have a look how we can easily get to such an environment.

A Look at Docker and Portability

Often enough, Docker is mentioned in one breath with portability. However, there are two dimensions of portability: first, running a container on any system of the same platform. Here, Docker really simplifies deploying applications on any system (of the same instruction set architecture). From a Linux on z Systems perspective, the second aspect of cross platform portability is more interesting: portability across platforms. Often enough, getting a container to run on z is not a big deal, but sometimes it is. Let's decompose this: