Search This Blog

Thursday 2 July 2015

Docker & Consul Lab

In my spare time I've been building a small Docker lab.  I wanted to see what all the fuss is about and also to bring some reality to the kool-aid drinkers in the office.

I've been around long enough to know that theres no magic pill, variations of really good ones have appeared over time but they all need to be mixed with something else.

Docker expands on the Linux LXC built into most kernels from 2.6 which allows a process to exist within its own space within the system.  Similar to virtualisation but without the hypervisor and the overhead a hypervisor brings needing to be all things for all people.

Docker allows you to create & package a container.  Lets say we have a simple JAVA SMTP service.  All the components needed to run that service,  Tomcat, code files run within the container, which can be moved, copied to somewhere else and function in exactly the same manner.

Also comes with a registry, either public or private which acts as a repository for Docker images.  Now you can easily distribute containers or pass them along the dev pipeline to QA, Ops.

DevOps nirvana! The excitement is palatable!

And yes, if your service is 100% self contained then thats a valid statement.

It's when you start to try and build a bigger solution, and this is probably where my inexperience comes in, that you start to think, and find some of the down sides.

Docker deals with networking within the Docker binary.  It serves local DHCP addresses to containers which are then port mapped to the hosts IP.  If a container is moved to a new host, its end point changes.

Intra container communication is via tunnels built between them, not via the network.

How do you find a service?

The answer to that question has already been dealt with by others doing true SOA or web scale.  Write a service registry, use queuing, load balancers/API, zoo keeper.  It's a problem thats been solved by anyone doing dynamic scale but this tweet/blog post:


Led me to look at Consul

At its core is a really clever service registry.  But also layered with health checks, clustering, multiple locale support that can be queried using an API or via name lookups (DNS) to the Consul service port.  Also able to integrate with something like DNSMASQ to redirect queries, this would allow seamless integration into an existing environment where DNS is being used to locate services.

Consul is a small binary, which in my case is within the container or could just as simply exist on the OS that uses a config file to determine what to register with the consul servers. In my lab its using a static config but in reality you would use a CM, puppet, chef, salt, ansible or automatically generate the config using a handy add-on consul-template.

The local consul binary deals with health-checks, nice, immediately a distributed system.  The consul servers (min of 3) run in a clustered mode which the local consul agent is aware of so theres registry HA built in.

In summary pretty impressed with consul, it's early days but something to keep an eye on.

But back to Docker.

Docker in itself is not yet a one stop shop, maybe its not supposed to be, but other players are entering the game to add to the package and I think will continue to.  Is Docker a death bell to virtualisation? If your a web scale company and all you do is web services then yes, it probably is.  For the enterprise or shops that are not developing apps then probably not.  But you can of course run Docker on hypervisors.

It also requires the dev teams to shift their model.  I know lots of places are SOA and micro services, but lots aren't.  Docker to them is not that magic pill.

Something that hadn't occurred to me until I watched this talk AppSec is eating security is the security benefits containerization brings.  The host can be a massively cut down OS and each container only contains the bare minimum to run the services.  The service also has no state, its IP is dynamic, it has no fixed abode.  The attack surface is not only reduced it becomes all slippery.  Patching also (in theory, and if you code correctly) a breeze.

But on the flip side :


Docker is potentially a game changer, but not without work and consideration.

A decent book is The Docker Book: Containerization is the new virtualization