Propellor has supported docker containers for a "long" time, and it works great. This week I've worked on adding more container support.
docker containers (revisited)
The syntax for docker containers has changed slightly. Here's how it looks now:
example :: Host example = host "example.com" & Docker.docked webserverContainer webserverContainer :: Docker.Container webserverContainer = Docker.container "webserver" "joeyh/debian-stable" & os (System (Debian (Stable "wheezy")) "amd64") & Docker.publish "80:80" & Apt.serviceInstalledRunning "apache2" & alias "www.example.com"
That makes example.com have a web server in a docker container, as you'd expect, and when propellor is used to deploy the DNS server it'll automatically make www.example.com point to the host (or hosts!) where this container is docked.
I use docker a lot, but I have drank little of the Docker KoolAid. I'm not keen on using random blobs created by random third parties using either unreproducible methods, or the weirdly underpowered dockerfiles. (As for vast complicated collections of containers that each run one program and talk to one another etc ... I'll wait and see.)
That's why propellor runs inside the docker container and deploys whatever configuration I tell it to, in a way that's both replicatable later and lets me use the full power of Haskell.
Which turns out to be useful when moving on from docker containers to something else...
Propellor now supports containers using systemd-nspawn. It looks a lot like the docker example.
example :: Host example = host "example.com" & Systemd.persistentJournal & Systemd.nspawned webserverContainer webserverContainer :: Systemd.Container webserverContainer = Systemd.container "webserver" chroot & Apt.serviceInstalledRunning "apache2" & alias "www.example.com" where chroot = Chroot.debootstrapped (System (Debian Unstable) "amd64") Debootstrap.MinBase
Notice how I specified the Debian Unstable chroot that forms the basis of this container. Propellor sets up the container by running debootstrap, boots it up using systemd-nspawn, and then runs inside the container to provision it.
Unlike docker containers, systemd-nspawn containers use systemd as their
init, and it all integrates rather beautifully. You can see the container
systemctl status, including the services running inside it,
journalctl to examine its logs, etc.
But no, systemd is the devil, and docker is too trendy...
Propellor now also supports deploying good old chroots. It looks a lot like the other containers. Rather than repeat myself a third time, and because we don't really run webservers inside chroots much, here's a slightly different example.
example :: Host example = host "mylaptop" & Chroot.provisioned (buildDepChroot "git-annex") buildDepChroot :: Apt.Package -> Chroot.Chroot buildDepChroot pkg = Chroot.debootstrapped system Debootstrap.buildd dir & Apt.buildDep pkg where dir = /srv/chroot/builddep/"++pkg system = System (Debian Unstable) "amd64"
Again this uses debootstrap to build the chroot, and then it runs propellor inside the chroot to provision it (btw without bothering to install propellor there, thanks to the magic of bind mounts and completely linux distribution-independent packaging).
In fact, the systemd-nspawn container code reuses the chroot code, and so turns out to be really rather simple. 132 lines for the chroot support, and 167 lines for the systemd support (which goes somewhat beyond the nspawn containers shown above).
Which leads to the hardest part of all this...
Making a propellor property for debootstrap should be easy. And it was, for Debian systems. However, I have crazy plans that involve running propellor on non-Debian systems, to debootstrap something, and installing debootstrap on an arbitrary linux system is ... too hard.
In the end, I needed 253 lines of code to do it, which is barely one magnitude less code than the size of debootstrap itself. I won't go into the ugly details, but this could be made a lot easier if debootstrap catered more to being used outside of Debian.
Docker and systemd-nspawn have different strengths and weaknesses, and there are sure to be more container systems to come. I'm pleased that Propellor can add support for a new container system in a few hundred lines of code, and that it abstracts away all the unimportant differences between these systems.
Seems likely that systemd-nspawn containers can be nested to any depth. So, here's a new kind of fork bomb!
infinitelyNestedContainer :: Systemd.Container infinitelyNestedContainer = Systemd.container "evil-systemd" (Chroot.debootstrapped (System (Debian Unstable) "amd64") Debootstrap.MinBase) & Systemd.nspawned infinitelyNestedContainer
Strongly typed purely functional container deployment can only protect us against a certian subset of all badly thought out systems. ;)