jwinter.org

A place for everything and everything in its place

A Short Talk on Docker

I gave a short talk on Docker at PhillyRB’s August meeting. These were my slides, although I went way off of them and only got through about half. What follows are the notes I used for my talk.

What’s Docker?

3 things I’d like you to take from this talk:

  • Docker provides a lot of the advantages of virtual machines without the disadvantages
  • Container-based deployment is a great way to deploy applications
  • AUFS and LXC are the chocolate and peanut butter that makes Docker so great to use

What’s a container?

It’s like a virtual machine. When your app is running inside a container, it appears to be running inside its own OS. But there could be many other containers running alongside yours, all sharing resources. It uses a combination of LXC (Linux containers) and AUFS (A union/layered/snapshotting filesystem). I’ll talk about both more later

They’re also a means of packaging. You can build a container and run it anywhere that can run docker. You can share that container with other people and know that it will run the same way.

Why are they useful?

  • Run your whole damn stack
    Run your Rails app on your laptop by grabbing a container with RVM installed, another container with PostgreSQL, another container with Redis, another with ElasticSearch or Solr. If you’ve ever tried to run multi-node Vagrant, it’s really painful and slow to spin up several nodes. Docker makes it very fast and easy.
  • Reduce dependencies by shipping dependencies inside the container
    Compile native gems or anything else once inside your container and ship that everywhere instead of building on each server.
  • Cut down on configuration errors in production
    Configure your OS inside the container then snapshot.
  • They’re fast
    Much faster and less resource intensive than VMs. As we’ll see in the demo, you can spin one up almost instantly.
  • Deploy Once, Deploy Anywhere
    Once you’ve built a container, and committed it as an image you can run it anywhere
  • Let someone else do the work for you
    The ability to package and share containers means that you can use someone else’s work to start from a known functional state. It’s like sharing chef cookbooks.
  • Easy to build
    Make a mistake building your application, no problem, every successful step is automatically snapshotted. If you’ve ever tried provisioning VMs with vagrant you know you’re almost always starting over every time.

What does working with containers look like?

Demo goes here.

How do containers work?

LXC

  • LXC gives you isolation and control over sharing of resources
  • LXC namespaces are what makes each container appear to have its own networking, process table, filesystem mount points, and hostname
  • LXC is also how you say: “Give my Rails container 4GB of RAM, but my database container 28GB”. It gives you some control over resource management including IO ops/second and bytes per second.

AUFS

  • AUFS, union or “layering” filesystem
  • The filesystem layers give each container its own view of the complete filesystem
  • Base layer is the OS and is read-only
  • Your container is read-write on top
  • When you go to do a read, it hits your container first, then reads through to the base if you haven’t made any changes
  • Unchanged files are shared
  • Buffercache is also shared, so a certain portion of what’s shared on disk is shared in memory as well.
  • This aspect is importants because it improves performance. Storage is cheap, so who really cares that AUFS saves a few gigabytes, but the fact that many dynamic libraries are shared across containers in memory means that containers spin up very quickly.

Where can I find useful prebuilt containers?

  • https://index.docker.io/
  • Search Github for Dockerfiles

How do I build containers?

  • Dockerfile, like a Gemfile but more like a shell script
  • You list what image you want to start from, then you list the commands you want to run, files you want to include, ports you want to expose

What are the downsides?

  • It’s very new, but doesn’t feel buggy. There’s just not a lot of good answers yet for common ops questions like what happens a container crashes or the daemon crashes or how to monitor?
  • Have to run your own repository to share private docker images

What’s the future?

  • Already several platforms like Heroku are popping up to support running Docker containers
  • Docker 1.0 in the fall
  • Like 100 committers on it and they just opensourced it
  • Docker is already changing how people ship software
  • Do MUCH less configuration in Chef, ship almost entirely configured containers
  • Test Chef recipes very quickly with test-kitchen-docker
  • Continuous Integration, test app inside lightweight container, ship that container