Thoughts inspired by the abstract idea of Docker-like things

October 20, 2013

One of the things that's been in the 'devops' ambient lately is Docker. The vague and probably partially inaccurate things I've heard about it and the general idea of 'containers' have inspired some thoughts, which I will summarize by saying that I'm all for the abstract idea.

The thing is, I don't really want to be managing machines. It's a pain in the rear. Nor do I really want to have virtualization because that actually means managing more machines (now I get to manage not just the virtual servers but also some more real ones as the hosts). By contrast containers seem like a great abstraction to me if they work.

The way I like to imagine this is that I have a a substrate of container-running machines, which are all generic and effectively identical (although you might have ones with more or less CPU power and RAM, depending). Containers get rolled on to these generic building block machines, one or more to a machine. Containers are lightweight and minimal (so they capture only what is important to the system they implement) and they're isolated from the underlying machine so I can maintain them separately (and maintain machines without worrying about the containers on them). Installing a machine to do X becomes 'install base machine; run command to roll container X on to machine'. If I'm lucky, most containers might even be basically indifferent of the underlying distribution and OS release we run them on.

(There are a bunch of issues here, of course. For example, I suspect that containers need to be able to come with their own IP aliases.)

And while I'm imagining lovely features, another nice advantage of a well done container system is that I could manage things in larger abstractions than 'a daemon'. Again I'd love it if I could just say 'start container X' or 'stop container X' and not have to remember the exact daemons that are needed for it and so on.

(I couldn't expect to do all management at the container level precisely because it is generic. For the foreseeable future there will still be daemon-specific management that needs to be done.)

This is a future that would simplify my life. It'd do so by decoupling two things that are currently entangled together (base OS and the applications on top of it) and allowing me to handle them separately.

To answer a potential question: I don't think you can get quite this with automation tools like Puppet or Chef. You can get close but the problem is that those tools are still intrinsically entangled in the host machine state because they have to install and manage things in the host machine, not in something that is deliberately isolated from it the way that containers should be.


Comments on this page:

i played with docker a little and the big problem to me is it cannot init a full stack of processes... i.e. you can't just run /etc/rc3.d. i vaguely understand this as a problem containerizing process group ids or pid 0. with a virtual machine, you get to use all the third party init scripts, you don't have to write them all yourself, which i believe makes them superior until the docker team figures this out.

Written on 20 October 2013.
« I should never have allowed 'outside' content to break my layout
Thinking about how I want to test disk IO on an iSCSI backend »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Oct 20 01:25:01 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.