Containerisation using docker

Tim Penhey tim.penhey at canonical.com
Tue Apr 30 05:21:57 UTC 2013


Hi all,

I've spent a little time looking into docker.  Not much time at the
moment, but I thought I'd share my thoughts so far.

The promise seems awesome, but there are some interesting caveats.

Docker wraps LXC and makes a nicer high level API.  I've been reading
the docs, going through their examples, and chatting on the #docker IRC
channel.

I'll start with the good news:
 * Written in Go, so fits our current language of choice
 * Ubuntu is their default supported platform, but they also work on
Arch, Windows, MacOS, and Amazon EC2 (I'm wondering if their last bullet
point is really referring to the the default Amazon linux, not EC2 as a
whole).
 * Since it uses LXC, it gives us the isolation we would want for
installing multiple units on a single machine.
 * Containers can have snapshots taken and moved between machines
(limited by architecture).  Consider the idea of someone deploying
everything to one machine to try things out, then moving units to
individual machines easily.  Obviously we'd have to make sure all the
relationships get updated properly, but the potential it there.  Another
potential would be using docker for the local provider, and moving the
deployed units to another provider (ec2 or openstack).  Obviously again,
there would be quite a bit of juju magic needed to make sure the state
is kept up to date properly, but consider the test story (use local
provider, set all things up, test, push all to ec2, and juju just works
- obviously not in the short term, but potentially something we might
want to consider).
 * The API seems quite nice and simple, and at the first look, seems
like it wouldn't be too hard to use

Not so good news, but not necessarily bad.
 * Big warning on the docker.io website saying "docker is under active
development - do not use for production"
 * The default images that you get with docker are quantal not precise.
 I don't see this as a huge issue as I'm sure there is a way to define
an image repository
 * The images for ubuntu are around 100 meg each (a bit of an overhead
to download initially) - probably not a huge problem for real
deployments if we manage the image repositories
 * We would have to manage some other images, not just use ec2 or
openstack.  I'm not entirely sure of the implications of this yet
 * One api call I made broke my terminal and failed to return for
something that should be simple - I intend to file a bug for it,
shouldn't be too much or too hard - heck I might even fix it and send
them a pull-request.
 * Docker is not in the official ubuntu repository yet, only in a ppa
with a precise build.  I downloaded the source and built it to test.  If
we end up tweaking, we have the potential to ship it with the tools
(although not necessarily desirable). On the plus side, they do want to
get docker into ubuntu officially.
 * Documentation is still very light, kind of expected at this stage.

Other comments:
 * Only real requirement (that I've found so far) is to have LXC available.
 * Should, theoretically at least, work on ARM.  Although this isn't
mentioned anywhere, and is not built for ARM in the PPA
 * We would obviously be an early adopter of docker with juju, so we'd
have to go through the pain of discovery and I'm sure we'd hit edge
cases that the current users/writers of docker haven't it.  This makes
timing harder to predict as we can't be sure that things will "just
work".  We can hope, but that's about it.


Conclusion:

The promise of docker fits very well with Juju.  I think it is
definitely worth spending more time investigating.  I think it is likely
to be easier to use than raw LXC.

Tim



More information about the Juju-dev mailing list