Docker

This field of container orchestration is moving incredibly fast even by the normal standards of software development. There has been a cambrian explosion of container startups and competition is heating up in a really big way. This is good for innovation, but makes it difficult to choose a technology. As such, I’m keeping my eye on both Docker and Swarm.

My goal was to choose an orchestration technology and to commit to a technology that is innovative, stable, and would be maintained for while. I’ve decided that working in a healthy community was critical to fulfill all three objectives. I’ve chose Kubernetes after a long technical, community and business evaluation (formally with Kismatic and previously Mesosphere) of different container orchestration solutions. However, as other container cluster management options become available, it’s important to recognize what capabilities they provide and compare them to the strengths of Kubernetes.

So let’s take a moment and look at the most recent release of Docker (version 1.12) which now competes directly with Kubernetes with SwarmKit (based on Swarm) now part of the core of Docker and providing the capability of instantiating a Swarm cluster directly from the console.

Worth noting is that once you create a new Swarm cluster it also creates the swarm manager which in turn creates a certificate authority (if an external store isn’t provided) so for now transparent security is built-in directly.

The command line console also has the ability to join a node to an existing Swarm cluster as either the manager or worker and seamlessly the worker can be promoted to a manager and a manager can be demoted back to the role of worker as needed providing much needed additional flexibility. The Swarm manager uses the RAFT protocol to elect a leader and determine consensus which is very similar to how Kubernetes works today with its internal use of etcd. Also worth pointing out is how the Swarm workers use a gossip protocol to communicate their respective state amongst themselves so Docker users no longer require external entities or key-value stores to keep track of the cluster topology.

Also new to this most recent Docker release is the concept of a logical service — consisting of 1-to-many container instances and with the introduction of this logical view it makes management of services much easier overall. You can now create and update as well as scale a service which results in containers being either deployed updated or ultimately destroyed when no longer required.

Yet one weakness in the Docker 1.12 release in my opinion is its service discovery, which works quite elegantly in Kubernetes. Important to note, that the notion of a “Service” proxy for containers has existed in Kubernetes since the beginning of the project you simply connect to service name in your cluster and Kubernetes will make sure you reach the correct pod (or one or more containers)(s) behind the service. Kubernetes is also designed to be modular and extensible so that its components can be easily swappable, which allows for some interesting opportunities to tailor its use to your needs overall.

This new release from Docker will definitely face competition from Kubernetes, which is intended to help automate the deployment, scaling, and operation of containers across clusters of hosts. Already many companies are using Kubernete because of its ultra strong community. Kube, as the community calls it, is also gaining widespread acceptance from enterprise customers that are looking to build containerized applications using the new cloud native paradigms.

Kubernetes describes itself as a way to “manage a cluster of containers as a single system to accelerate development and simplify operations”. Kubernetes is open source, but also community developed and stewarded by the CNCF. This is fundamentally different than Docker/Swarm, which is ultimately controlled by a single start up and and is not governed by an open source community. Kubernetes is awesome because it brings Google’s decade plus experience of running containers at scale, Red Hat’s years of experience deploying and managing open source in the enterprise, the nimble development experience of CoreOS as well as advantages from many, many other organizations and community members.

Because of a powerful and diverse community, Kubernetes is as flexible as a Swiss Army Chainsaw. You can run Kubernetes on bare metal or on just about any cloud provider out there. Another amazing feature of Kubernetes is that it supports both Docker and Rocket containers as well as providing the ability to address additional cluster runtimes moving forward.

The wonderful experience and drive of the community cements our dedication to our choice and it’s place in the overall container orchestration space. Just the shear velocity of the project is amazing and the community is extremely vibrant.

So, in the end, I’m choosing to rally behind Kubernetes. It was the most robust solution we tried and we’re confident that it’ll support us as we grow in the future. Red Hat along with others are looking forward to providing Windows support for Kubernetes and the ability to run Windows containers directly as well. But it’s important to keep in mind that the other cluster orchestration services aren’t necessarily bad but as I stated earlier this field is moving quite fast and we want to ensure that we’re working with the most active as well as stable and mature project available to us. We’ve been extremely happy with Kubernetes and been using it in production for awhile now in fact ever since the 1.0 release.

We’re excited about the 1.3 release of Kubernetes and the new PetSet (was nominal services) feature providing the new stateful primitives for running your pods which need strong identity and storage capabilities. Looking forward to everything to come with the addition of cluster federation (a.k.a. “Ubernetes”) in Kubernetes 1.3 as well. I for one am very grateful to the entire Kubernetes community for everything they’ve done on this project thus far and everything that they continue to do. It’s truly an amazing piece of technology and a great building block for my needs.

Vagrant

Vagrant is an amazing tool for managing virtual machines via a simple to use command line interface.

Install

Vagrant uses Virtualbox to manage the virtual dependencies by default. (You can directly download virtualbox and install or use homebrew for it.) But I like using VMware Fusion 7 Professional with the Vagrant VMware provider.

I’m assuming you know how to download and install VMware Fusion the typical way.

SSHFS

Installation

An easy-to-use installer package for the latest version of SSHFS can be downloaded from the SSHFS repository’s download section. The package installs a self-contained (as in “does not depend on external libraries”) version of SSHFS. It supports Mac OS X 10.5 (Intel, PowerPC) and later.

Note: This build of SSHFS is based on the “FUSE for OS X” software, that is not contained in the installer package and has to be installed separately. The latest release of “FUSE for OS X” can be downloaded from http://osxfuse.github.com.

Macfusion

To use Macfusion with the newer “FUSE for OS X”-based version of SSHFS, put Macfusion in your Applications folder and run the following commands in Terminal. See 3. under “Frequently Asked Questions” for more information as to why you might want to use Macfusion.

I ran into a problem though. I mount some of my servers via SSH, and even though the SSH account has write access to some files, OS X doesn’t let me open them with the standard “permission denied” error. This is because the user on the server has another UID than the local user on my mac. To get around this issue, I’ve entered the following line into the Extra Options (Advanced) field of MacFusion:

-o idmap=user -o uid=501 -o gid=501

This maps the remote UIDs to match those of the local system. If you’re on a mac, your user ID will most likely be 501. If not, make sure you enter the right ID.

So now I can use the Macfusion menu item to mount my Vagrant image as a local volume:

cd /Volumes/vagrant/

and use the editor of my choice to work with my home directory in Vagrant.

Docker

Prerequisites

Docker requires a 64-bit installation regardless of your Ubuntu version. Additionally, your kernel must be 3.10 at minimum. The latest 3.10 minor version or a newer maintained version are also acceptable.

Kernels older than 3.10 lack some of the features required to run Docker containers. These older versions are known to have bugs which cause data loss and frequently panic under certain conditions.

To check your current kernel version, open a terminal and use uname -r to display your kernel version: