[WIP] Add support for Docker

[toolness]

I'm not sure if this is actually a good idea or not, but after looking at the requirements for setting up the development server, I thought it might be useful to have a Docker setup for development.

Advantages:

• Eliminates the need for Ruby 2.2.3 and/or a Ruby version manager on the host machine
• Eliminates the need for a specific version of Node on the host machine
• Eliminates the need for XCode tools/a C++ compiler on the host machine

Disadvantages:

• Uses the official Ruby 2.2.3 docker image, which weighs in at 274 MB. It's possible we could use the slim or alpine alternatives to reduce the size, but regardless, people on a slow internet connection will be at a disadvantage here.
• Currently, Docker on OS X and Windows is a bit confusing because Docker Machine is used to launch a VirtualBox linux VM behind-the-scenes in which the "real" Docker runs. This can be a source of confusion, but fortunately Docker is going native on Mac and Windows so this shouldn't be an issue for long.
• Changing the Gemfile could become a bit of a hassle, because it requires the fs layer containing all the gems to be completely rebuilt. In other words, while adding or changing a single gem in the Gemfile on a non-Docker setup would just require running ./go init and then the building of a single gem, with Docker it'd require a re-run of docker-compose build, which would then trigger a rebuilding of all gems.
• Generating the site takes longer on my machine: about 37 seconds compared to 20 seconds when run without Docker. I'm guessing this is due to extra I/O overhead incurred by docker-machine, which will go away eventually, but I could be wrong.
• The docker container is running as root, not as the current user, which could mean weird file permissions for generated files. There's ways we can get around this, though.

Anyways, not sure if the pros outweigh the cons but figured I'd throw it out here for feedback.

To try this out on OS X:

1. Install Docker Toolbox.
2. Run the Docker Quickstart Terminal (available via Spotlight). This is a really annoying step but will go away once Docker goes native on OS X, I think.
3. Run docker-compose up.
4. Visit http://192.168.99.100:4000 in your browser.

Still to do:

• Add instructions in README for using Docker.

[gboone]

I think this is a good idea. I suspect once Docker goes native it will greatly simplify the process of getting the site set up. Right now it sort of feels like you're learning how to be a ruby developer and I think the advantages here are great. Since we host the site (or will hopefully soon) on Federalist, it might make sense to look at how that project has handled some of these disadvantages. Addressing those specifically:

Uses the official Ruby 2.2.3 docker image, which weighs in at 274 MB. It's possible we could use the slim or alpine alternatives to reduce the size, but regardless, people on a slow internet connection will be at a disadvantage here.

I see this as sort of a neutral issue. Since the repo itself is huge, it's already going to disadvantage people with slow connections but it is good to know where these slow points area.

Docker Machine is used to launch a VirtualBox linux VM behind-the-scenes in which the "real" Docker runs.

Is there anything we should document around this?

With Docker it'd require a re-run of docker-compose build, which would then trigger a rebuilding of all gems.

We don't often add new gems, so we'd do this pretty infrequently and if we make sure to document when and how to do this, it seems pretty manageable. Plus, we get a lot of errors with gems and the gemfile right now because we're managing it on our own.

I'm guessing this is due to extra I/O overhead incurred by docker-machine, which will go away eventually

The docker container is running as root, not as the current user, which could mean weird file permissions for generated files. There's ways we can get around this, though.

When Docker is native to Mac will these change?

[toolness]

I think this is a good idea. I suspect once Docker goes native it will greatly simplify the process of getting the site set up.

Yay! 💃

Uses the official Ruby 2.2.3 docker image, which weighs in at 274 MB. It's possible we could use the slim or alpine alternatives to reduce the size, but regardless, people on a slow internet connection will be at a disadvantage here.

I see this as sort of a neutral issue. Since the repo itself is huge, it's already going to disadvantage people with slow connections but it is good to know where these slow points area.

Ah, yeah, that makes sense. Cool, good to know!

Docker Machine is used to launch a VirtualBox linux VM behind-the-scenes in which the "real" Docker runs.

Is there anything we should document around this?

Hmm, good question. I think there are a few common issues we could document, which I'm happy to take care of.

With Docker it'd require a re-run of docker-compose build, which would then trigger a rebuilding of all gems.

We don't often add new gems, so we'd do this pretty infrequently and if we make sure to document when and how to do this, it seems pretty manageable. Plus, we get a lot of errors with gems and the gemfile right now because we're managing it on our own.

Ok, sounds good! On another project I've "hacked" this by making two separate Dockerfiles that build on each other: one contains the vast majority of dependencies and is actually downloadable from Docker Hub for quick install, while the other builds on the first and contains only the latest dependencies that haven't yet been added to the first. This generally allows new dependencies to be easily experimented with, though I'm not sure if this "hack" is used elsewhere.

The docker container is running as root, not as the current user, which could mean weird file permissions for generated files. There's ways we can get around this, though.

When Docker is native to Mac will these change?

Good question--unless Docker has added better support for uid/gid mapping in the past several months, then the answer is no. Hopefully better uid/gid mapping is a high priority for them, or has been fixed already; but if not, at this point I've written scripts in node, python, and ruby that do it for us, so no worries either way!

[toolness]

Alright, I've just added an entrypoint that maps the uid of the container running the service to the uid of the host user. That way everything in _site, and any other files created by the docker container, aren't owned by root (and thus made annoyingly hard to delete by the host user).

@gboone, is there anything else you'd like me to change in this PR?

[gboone]

Gaaaah! Was going to review this yesterday, then got stuck doing something else. Hopefully I'll get to it today but if not I'll review it when I'm back on Tuesday. Thanks @toolness and sorry left you on the hook.

[toolness]

No worries @gboone, thanks for the update!

[toolness]

By the way, I was just reminded that our dev standardization guides exist, so instead of putting Docker advice on every single repository that uses Docker, I thought it might be a better idea to improve the Docker guide and link to that. Here's the PR for it if you're interested:

18F/dev-environment-standardization#16

[NoahKunin]

@toolness Looks like Docker for Mac native is now out of beta. Should this issue still be open?

http://www.docker.com/products/docker#/mac

[toolness]

Woot! I think it just means the instructions we add to the README will be nice and simple? I don't think it means this issue should be closed without merging though... @gboone have you been able to take a look at this? Or was I supposed to do something?

[gboone]

Yeah, I think just updating the README should be good. We should port this over to the beta.18f.gov repo, too

[gboone]

@toolness can you change the target branch of this PR to master?

[gemfarmer]

Closed in favor of #1945