David Currie

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:

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.

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:

Last night I headed up to London for the December meetup of Docker London. The evening didn’t get off to a great start as I managed to cycle over a screw on the way to the station. Despite this, and the subsequent efforts of the Jubilee Line, I did just make the start in time.

The evening kicked off with Chad Metcalf from Docker demoing Tutum. It was just a slight variant of one of the demos from DockerCon so nothing really new for me here although he did talk a little about the extensions to the Compose syntax that Tutum uses. The HIGH_AVAILABILITY strategy being something that’s obviously missing from Compose/Swarm today.

Next up was Alois Mayr, a Developer Advocate at Ruxit, who did a nice job of not explicitly pushing his company’s offering but instead talked more generally about some issues experienced by a Brazillian customer of theirs that has a large deployment of Docker running on Mesos. The underlying theme was undoubtedly that, in a large microservices based architecture, you need to have a good understanding of the relationships between your services and their dependencies in order to be able to track problems back to the root cause.

Last up was an entertaining pitch by Chris Urwin, an engineering lead at HSCIC (part of the NHS) and consultant Ed Marshall. They talked about a project to move from a Microsoft VMM (and Excel spreadsheet) based setup to one using Docker and Rancher for container management. They were undoubtedly pleased with the outcomes in terms of developer productivity and the manageability of the deployed environment, not to mention reduction in cost and complexity. Although the system is not live in production yet, it is live in an environment that they share with partners that is subject to SLAs etc. Particularly striking for me was the reduction in the amount of disk space and memory that the new solution entailed.

I picked up a copy of Docker in Production – Lessons from the Trenches during a recent O’Reilly sale, hoping to pick up some tips to pass on to customers that I work with. I have to say that I was disappointed! It’s not that the book isn’t full of useful information. It is. After a good start, it just failed to deliver on the title for me.

After covering the basics and the likely areas of concern, it introduces an example with the wise words that not everyone is looking to deploy a platform for running tens of thousands of containers and that even small deployments can benefit from their use. The example describes a simple environment using systemd to stand up a static topology with the ability to provide environment specific configuration. Just the sort of concrete material I was hoping for.

The next couple of chapters provided further examples from a second company: one using a simple scripted approach and another using AWS Beanstalk. So far, so good. At this point the book changed tack though and switched to covering different subject areas such as security, building and storing images, configuration management, networking, scheduling, service discovery, and concluding with logging and monitoring. Although, as I say, there was lots of good information scattered throughout, these chapters somehow felt like they were just giving an overview of the current state of the Docker ecosystem without giving much in the way of guidance as to how to select from the myriad of options to create a production-ready solution.

Perhaps I’m being unfair and this is simply a reflection on the current state of play. Whilst the Docker feature set is still being fleshed out there are still many compromises to be made and over time we may see more repeatable deployment patterns emerging. The fact that much of the material in the book was not new to me is probably a reflection of the efforts I am taking to keep up with what is a rapidly transforming area.

One final thought: it will be interesting to contrast this book with the free eBooks series that The New Stack has just begun. The first book, entitled “The Docker and Container Ecosystem”, includes some interesting metrics to suggest who are the main players. The catalogue of services and projects that form the second half of the book is truly eye-watering and whilst it can be seen as an indicator of vibrancy, it does indicate a real need to be able to provide guidance to those who do not have the time or inclination to immerse themselves in this world.

On Friday I made my way up to the Barbican Centre for this year’s edition of Container Camp London. After a slow start (no-one seemed to know that we were supposed to descend five floors to the cinema in the bowls of the building) things finally got under way. Here’s a quick summary of the day’s sessions:

• Bryan Cantrill, CTO at Joyent kicked off the day with a animated romp through the history of containers ending with the view that containers deserve better than to be run in virtual machines and, perhaps not surprisingly, Joyent’s Triton project gives you the ability to turn the bare metal in your datacenter in to one large virtualized container host.
• Next up (after another hiatus to sort out projector woes) was Shannon Williams, co-founder of Rancher Labs. He talked about what you should be looking for in a private container service which again, not surprisingly, read much like a feature list for Rancher.
• Lack of network connectivity was the next issue which saw Bryan Boreham from Weaveworks take to the stage. Byran gave a technical presentation describing why consensus (as used by Consul or etcd) may be overkill and why Weave uses conflict-free replicated data types (CRDT) for service discovery and IP address management.
• Mandy Waite from Google gave an introduction to Kubernetes – nothing new there.
• Stephane Graber, who is the project lead for LXD at Canonical, gave a nice demo of some of the capabilities of LXD. He stressed that LXD is aimed aimed at system (i.e. whole OS) containers rather than application containers, suggesting, for example, that you might run Kubernetes under LXD. He failed, however, to explain what features differentiated it in this respect.
• There was selection of lightning talks over lunchtime, most of which now escape me. Ben Corrie from VMware spoke about Project Bonneville, demonstrating vSphere as a container host. Liz Rice would have demonstrated the real-time scaling of force12.io if she’d been able to connect to the screen.
• After lunch, Arjan Schaaf from Luminis illustrated that, as always, you should performance test. In this case, to understand the inter-container networking characteristics of your IaaS and SDN.
• Alissa Bonas from Redhat demonstrated the OpenShift/Kubernetes integration in ManageIQ that allows you to drill down from a container view of the world in to the underlying infrastructure (virtual or physical).
• Miek Gieben spoke about the dynamic, container-based infrastructure that powers Improbable.io based on Core OS, fleet, etcd and DNS.
• After yet another coffee break (queue trek back up five flights of stairs), Ben Hall gave an entertaining pitch on attempting to keep nefarious users at bay whilst giving them free reign over a Docker setup in his Scrapbook learning environment.
• This was followed by Diogo Monica of Docker cover the Notary and the Trusted Update Framework as integrated with Docker 1.8. I was just glad that I had saved watching Docker Online Meetup #24 for the journey home as it was the same slidedeck.
• Perhaps the most impressive session of the day was by Loris Degioanni, CEO at Sysdig. He started by talking about monitoring through tools such as Google’s cadvisor and Docker logs before giving a really powerful demonstration of the sort of information you could collate and navigate by inserting the sysdig kernel module on the Docker host.
• Last up was Juan Batiz-Benet who, although his presentation was entitled ‘Containers at Hyperspeed’ was, I suspect, going a little too fast for most people to keep up! The net was though that we should all be using IPFS to shift images around so that deduplication doesn’t stop at container layers but goes down to the individual file level.

As you can probably tell from my comments, the conference could have been slicker but it was still well worth the trip up to London. I’d say I learnt less than last year but that’s more because my own level of understanding has moved on. I’d also suggest that this year there was more of a focus on ‘doing with Docker’ than simply on the technology itself which indicates an increase in the maturity of the ecosystem.

I headed up to the London PaaS User Group Meetup yesterday evening. There were two speakers on the agenda. First up was Jeff Hobbs, CTO & VP Engineering at ActiveState with a pitch entitled Docker is not Enough (pretty much this deck). The main tenet being that Docker is not enough in itself as it just addresses packaging and execution. You need a PaaS to provide all of those other niceties like load balancing, auto-scaling, monitoring, centralised logging, audit, … My main issue with this pitch was simply that I don’t think anyone has ever claimed that Docker is enough. That’s why there’s a wealth of ecosystem projects surrounding Docker. And why does stackato (ActiveState’s Cloud Foundry based PaaS) use Docker for containerisation? Jeff stated that this was because the ops team would feel more comfortable dealing with this technology on the back end.

Second up was a late breaking change, my colleague Julz Friedman had stepped in to give a re-run of his Building a Docker backend for Garden presentation from the Cloud Foundry Summit. It was perhaps no great surprise to discover that, when you swap in Docker behind the Garden API, you don’t really see any benefits over the existing implementation (and, indeed, there are significant disadvantages for a multi-tenant PaaS such as the current lack of user namespace support in Docker). The one potential benefit that Julz did highlight was an increase in security, given that there are more eyes on the Docker codebase than Garden.

So why do I make the five hour round-trip in to London for a couple of sessions that I could have got off the internet? Was it the free beer and pizza? Well, no, although welcome, I think the train fare would have more than covered those. It is, of course, to meet people and to hear the Q&A where perhaps much of the interesting information is exchanged (and I caught up on some reading on the train!). There was a lively debate on the relative merits of Docker. One point that Jeff and Julz agreed upon was that the use of Docker images was a retrograde step versus the application centric view of PaaS, letting things that should be the responsibility of ops (e.g. patching OS images) become a part of the developer’s domain (Jeff quoted a stat that some 70% of images on Docker Hub were subject to vulnerabilities).