Recently, I started ramping up on a little something called Docker. In its simplest form, Docker lets you treat a runtime environment like a codebase under source control.
Want to record how an environment looks?
docker commit <container> <tag>
Made a few unfortunate changes, and want to roll it back?
docker rm <container> docker run <tag> <command>
It's more than a little intruiging and I'll definitely get back to how to make the most of it, but first an admission. Early on, I was routinely confused by all of the terms. "Images, containers and processes, oh my," I recall saying to myself on more than one occasion while staring aimlessly at an
xterm. To help me keep all this straight in my head, I whipped up a simple analogy.
An image is like a blueprint for a jail cell.
A docker image contains a starting point for a runtime environment. This includes all of the files on disk at the time that environment starts. In there as well are tips on what network ports the process in the environment may need to listen on, the current working directory of this process, as well as a default command to run when the environment is started.
A container is like a completed jail cell...with internet access.
A dockerized process is like a prisoner.
A docker container is the runtime environment mentioned above. Processes bound to a container may do whatever they want—create or delete files on disk, produce diagnostics, create users, bind network ports, or even create new processes. The useful thing is that the effects of these actions will extend no further than the container walls. This means that processes in two different containers can simultaneously, e.g. write different content to
/etc/foo.conf or listen on port
8080 without conflict.
The docker daemon is part prison guard; part construction crew.
The docker daemon does a lot of work. But the important bits involve creating containers from images, running dockerized processes, and recording their output. The daemon also manages network traffic destined to containers (connections from other containers as well as ones routed in through the docker host), and helps manage requests to turn containers into new images.
Docker is effectively a thin veneer over a still maturing set of kernel features collectively called Linux Containers. Containers are a not so easy way to setup isolated zones of execution on a Linux machine. Docker makes these features extremely easy to use.
And that's it—Docker in a nutshell. This will definitely save the day the next time I'm staring at my
xterm. Hope it saves yours, too :-)