Docker compose setup

[dnephin]

Adds docker containers and a docker-compose.yml (previously known as fig) for acceptance testing and development environments.

I working on this original for a demo at Docker Global Hack Day a few months ago. It was using fig and had some issues still with build ordering. I've updated to use the latest docker compose (the first rc), and to use shipwright for building the images.

There is only one acceptance test right now. There's a lot more that can be done with this setup, but I wanted to include one just as an example.

There are still a few pain points to work out:

• items marked with TODO
• the build for the builder container is very slow because of the apt-get install. These packages are required to build the pdfs, but they are relatively large, and take a very long time to download. It's quite possible there is a better way to provide these dependencies.

This PR is mostly a preview. If you're interested in this setup, I can see about fixing up some of the pain points.

[ericholscher]

Thanks for sending this in. I'll look over it this week and comment back.

[ericholscher]

Re: the builder, presumably we just need to build the container once, and then use it with all the packages already installed?

[dnephin]

Normally yes, but with the current setup the application code is included first (from the base image), so code changes actually require it to rebuild.

There's probably a few ways to fix this. One is to share the code/virtualenv using a data volume, but that is not very production-like.

Another is to wait for docker 1.5, which I believe will let you build a dockerfile by path (instead of always Dockerfile). Then we can include a builder.dockerfile in the root, and add the code after the large apt packages.

A third option would be to have a separate build step which builds a tarball of the application code + virtualenv, and have the dockerfiles ADD this tarball instead (again after the slow apt packages). The disadvantage here is that you have to do some extra work outside the normal fig workflow.

[agjohnson]

First off, thanks for the contribution!

I'm not sure the best thing to do with this PR. It's been open for a while and though we appreciate the contribution, I'm not sure it's something that would benefit the core team.

The main issue is that we wouldn't use docker for local development or production in this way, and so this is bound to rot. Additionally, as an acceptance test framework, it's adding a number of new dependencies and testing methodologies, but doesn't really buy us anything that our unit tests aren't already doing for us. Also, because we handle provisioning in a completely separate manner, it lacks parity with our servers. So in the end, this won't be able to test anything significant.

I think this could live on it's own, as a method to stand up a RTD cluster. On it's own here, this has been on hold for a while because of a number of issues, so I think it's best to just close it. I don't like closing PRs, and realize this was a hack day project and so there was no time to ask you to discuss this with core devs, but we do appreciate the effort. Thanks again for the contribution!