Once again this year, we’ll be making use of docker on the robot. Docker is a linux container system. I’ll explain how we use Docker in the next post, this post will concentrate on introducing Docker.
Containers are a way of segregating processes. A docker container has its own filesystem, separate from the hosts (though you can mount part of the hosts filesystem into the container if you want to). Processes running inside the container cannot see processes running outside the container (either on the host or in other containers). If you use an appropriate network plugin, it is possible to set up networking for the container too (e.g. so that you can run a web application on port 80 in multiple containers on the same host). The only thing that gets shared between the host and the containers is the host hardware and the linux kernel.
One way of looking at Docker (if you’re used to python) is that its virtualenv on steroids. Virtualenv gives you a local python environment that you can install libraries into without affecting the systemwide python environment (and potentially breaking other packages). A docker container gives you a whole filesystem to do stuff in that’s independent of all the other containers and the host. An example of this: if you have code built to run on Centos, you can install it (and all its dependencies) in a container with Centos and it’ll just work on a Raspbian host. Or code which worked on an old version of Raspbian, but doesn’t work on the latest. It makes your code totally independent of what’s on the host, so long as the host is running the Docker daemon. So I no longer need to be careful about how I setup my SD cards for my robot – so long as they have Docker, the container will run just the same – which makes collaborating on different Pis much easier. You never run into problems where “well it worked on my machine”.