So I’ve been at Linux Conf AU all this week and this is the first of a series of articles based on the ideas bouncing around there. There’s been lots of talk about lightweight containers and about the ways implement, manage and roll them out, from the relatively well established Docker to more far-out things like Unikernels and CloudABI.
I’m a bit leery of a few of these things – “Interestingly Wrong” is my initial feeling –but I feel that it isn’t really right to say that without putting on the table a proposal of my own, so here goes:
Get all your state into Git
Every bit of state, be it code or config, has to be available in the repo so it can all be checked out at once.
All the dependencies too …
This is possible using Git Submodules which pull an external repo into a sub-tree of your repo. I haven’t worked with this myself, and it looks a little fraught (“you must be careful or Git will get angry at you”). (( If it turns out submodule doesn’t really work here, you could always just put all the repos side by side )).
But assuming that the gods smile upon you, you should now submodule in every dependency of your project, including languages, libraries, webservers, init, the kernel, everything.
Now build that repo
Your git repo is now the total state of your server.
You’ll need a script which can build everything together into a container of some kind. At this point, I’m thinking an LXC image.
Boot, test, run, kill.
These machines are ephemeral and immutable. Don’t even bother putting opensshd on there. They should pass logging off to a log server and they shouldn’t write anything back to their filesystems. Ephemeral machines are crash-only … there’s no need to turn them off carefully.
Right, so there’s my modest proposal. As time permits, I’m going to have an experiment with LXC and see how it works …