Machines, media & miscellanea by Kevin Carmody
Despite some initial misgivings, I really fell for Vagrant. Consistent repeatable develoment environments, what’s not to love? Well, mostly the lack of speed. There are tricks that help, like nfs, but a full VM is comparatively slow compared to running native. Also, though I try to keep things consistent by using provisioners like Ansible, there still seems to be some discrepencies between environments. Maybe there is another way…
I’ve heard great things about Docker’s speed. There are also several services now offering Docker based deploys. So as part of a blog revivial (that time of year again) I thought I’d give it a go.
There are already some great docs and articles out there on working with Docker.
If you wanna start using Docker, certainly read the docker userguide
There is also this great article by Ron Dahlgren that gives side by side comparison of Vagrant and Docker builds.
That said, I think there are some concepts that it’s good to get your head around first, especially if you’re expecting it to act like a drop-in for Vagrant.
A VM is a totally independent system. An LXC (LinuXContainer) (for which Docker is just a wrapper) is an operating system level virtualisation, which means…
It is using the base system libs where available - unlike a full blown VM. So if you’re using a Mac, you’ll need either boot2docker (a mini Linux VM) or a Vagrant style VM to run it in.
There are many community containers for various starting points. But if you just start with an ubuntu:14.04 container, it is really really minimal. Like, no python, build-essentials, nothing. You do have apt-get, so start building from there.
Every step in a Dockerfile will create a new container from the last step. These intermediary containers get cached, which makes for super fast rebuilds. It also allows you to create a shared base system, or to start from someone else’s snapshot if you like. There are loads on the docker hub
Once a VM is up, it’s up. You ssh in/out as you please. However, unless you deamonise
docker run or keep reading from stdout, it will exit as soon as it’s commands have run.
With VMs, you can also do things like auto-mounting network shares/magic sync stuff. In Docker, you need to mount your working dir to the image at runtime. You also need to use an absolute path.
# Example docker run with interactive tty and project folder mounted sudo docker run -it -v /home/kevin/projects/app:/app my_container /bin/bash
That said, you can import a dir using
ADD, but changes in the container wont reflect in your local filesystem, as ADD just copies the files over.
You could also just clone your repo straight in to the container if you want. Y’know, for building deploys or whatevs.
Ok, I’m just up to building dev workspaces at the moment. Making Dockerfiles currently feels a bit like provisioning with bash scripts. Not bad I guess, but I’d really like to hook it up with Ansible next so I can start provisioning containers like a boss.