David Currie

As part of a script that I was writing today I was attempting to count the number of times that a containerised Liberty server had started. I started with the following command:

docker logs test | grep "CWWKF0011I" | wc -l

(where CWWKF0011I is the code for Liberty’s “ready to run a smarter planet” message) but it was giving me an answer one greater than I anticipated. Stripping off the line count at the end quickly showed why: in addition to the messages that I was expecting, grep also appeared to be returning an error message from the logs. It took me a little while longer to get my head around what was going on. grep wasn’t passing the error at all. Indeed, the error wasn’t even getting as far as grep. Instead, docker logs was trying to be helpful and recreating the stdout and stderr streams from the container; stdout was getting piped to grep, and stderr, where Liberty was outputting its error message, was just going straight to the console. This was also going to cause me a headache elsewhere when I was actually trying to grep for errors.

When I first learnt bash, 2>&1 was the way to redirect stderr to stdout but, just to prove that you can teach an old dog new tricks, here’s the working version of my original command using the Bash 4 syntactic sugar to merge stderr in to a pipe:

docker logs test |& grep "CWWKF0011I" | wc -l

As a further aside (which certainly added to my confusion when trying to debug this), if you allocate a TTY to a container via the -t flag on the run command, stderr will be merged in to stdout before it hits the logs so you won’t see this behaviour at all!

I’m slowly working my way through the list of Docker publications that I stacked my tablet with when IBM restarted its subscription to Safari Books Online. One of these was Docker Containers: Build and Deploy with Kubernetes, Flannel, Cockpit, and Atomic by Christopher Negus. The last two projects in the title are a clue to the underlying theme of the book. Cockpit and Atomic being Red Hat projects, this is really a guide to doing containers the Red Hat way. This I was expecting – they do employ the author after all. What really disappointed me was that the four technologies cited in the title occupied so little of the book’s content. Of the 18 chapters, there was one on Super Privileged Containers (an Atomic concept), one on Cockpit, two on Kubernetes, and one paragraph on Flannel. Hardly comprehensive coverage!

The first part of the book covers the basic concepts, setting up an OS and a private registry. This reminded me of one key fact that I’d forgotten: that Red Hat ships its own Docker distribution. One of the Red Hat specific features is the ability to specify multiple default registries (with Red Hat placing their own registry ahead of Docker Hub in the default search order). This is at odds with Docker’s view that the image name (including registry host) should be a unique identifier. Personally, I would side with Red Hat on this one. I suspect many customers will be using their own private registries and would prefer to be able to specify ‘myimage’ and have it resolve against the correct image in the local registry for the environment.

The bulk of the content is in the second part that covers building, running and working with individual containers. There were a few errors that crept in to this section. For example, the author suggests that setting the environment variable HOST on a container somehow magically mount the host filesystem (it’s actually used to tell Atomic where the host filesystem is mounted). He also states incorrectly more than once that removing files introduced in one layer in a subsequent layer will reduce the size of the image. In general though, it provides a good coverage of working with containers. I picked up a few interesting command options that I wasn’t aware of. For example, ‘-a’ on a ‘pull’ to retrieve all of the images for a repository, the fact that you can use ‘inspect’ on images as well as containers, and a couple of commands that had previously escaped me completely: ‘rename’ and ‘wait’. There was also some useful information on the use of Docker with SELinux.

The third part covers Super Privileged Containers in Atomic (the way in which Atomic extends the basic capability of the OS via containerized tools) and management of Docker hosts and containers through the Cockpit browser based administration tool. The fourth part then covers the basic concepts of Kubernetes and the steps for setting up an ‘all-in-one’ environment and a cluster. These steps seem destined to be out-of-date before the ink is dried and the space would have been better spent covering the concepts in more depth and talking about usage scenarios.

The final part seems a little out of place. One chapter covers best practices for developing containers. The cynic in me suspects this may have just been an opportunity to introduce some OpenShift content. It certainly glosses over the entirety of Machine, Compose and Swarm in just a single section. Then there is a closing chapter looking at some example Dockerfiles.

All-in-all, the book offers a good introduction to the topic of Docker, particularly if you are looking to deploy on Fedora, RHEL or CentOS. Look elsewhere though if you really want to get to grips with Kubernetes.

I was excited to see Docker announce a beta for ‘native’ support for Docker on Windows and Mac where ‘native’ means that Docker appears as a native application utilising built-in virtualisation technology (Hyper-V on Windows and a project called xhyve on Mac) rather than requiring Virtual Box. Sadly this isn’t much use to me at work where I run the corporate standard Windows 7 on my laptop and Linux on my desktop. (The Register had an article indicating that, although Windows 7 is declining in the enterprise, its market share is still 45%+ so I hope Docker don’t do anything rash like ceasing to develop Docker Toolbox.) I do have a Mac at home though so I signed up for an invite.

The install went very smoothly although the promised migration of images and containers from my existing default Docker Toolbox image failed to happen. My best guess was that this was because the VM was back-level from the version of the client that the native app had installed although I’m only guessing. Docker Machine and the native app sit happily alongside one another although obviously I then needed to upgrade the VM to match the newer client version.

Needless to say, the first thing I tried to run was the websphere-liberty image. This started flawlessly and, having mapped port 9080 to 9080, I was then able to access the Liberty welcome page at docker.local:9080. So far so good.

Having been out on vacation at the time, I went back and listened to the online meetup covering the beta. Given that we have websphere-liberty images for PPC and z/Linux, I was particularly intrigued to see that it promised the ability to run images for multiple architectures. The example given in the meetup worked like a charm:

$ docker run justincormack/ppc64le-debian uname -a
Linux 9a41dded6970 4.4.6 #1 SMP Mon Apr 4 15:12:22 UTC 2016 ppc64le GNU/Linux

Unfortunately trying to run anything against other images such as ppc64le/ubuntu resulted in a ‘command not found’ from Docker so I need to do some more digging to see what’s going on here.

Whilst browsing the beta forums, a common complaint was the speed of the file system mounts which has also been a problem with the Virtual Box approach. I decided to test this out by trying to use the maven image to compile our DayTrader sample. To keep things ‘fair’, my maven cache was pre-populated and, when running the image, I mounted the cache.

Natively on the host a ‘mvn compile’ takes around 12 seconds. With Docker running in a Docker Machine VM using the following command, the time was surprisingly close, typically of the order of 14 seconds.

$ docker run -v $HOME/.m2:/root/.m2 -v $(pwd):/usr/src -w /usr/src \
    maven mvn compile

Running the same command against the beta unfortunately took over 30 seconds. Whether that’s down to the file system driver I can’t say. It’s certainly an appreciable difference but, hey, this is a beta so there’s still plenty of hope for the future!

One tip that I picked up on the way: ‘docker-machine env’ has an  ‘–unset’ option which means that, if you want to switch back to the native Docker install after using Machine, then you can use the following command:

$ eval $(docker-machine env -u)