A Docker container will enable flexible, reproducible development of DXR, while also setting the stage for a decoupled application and storage architecture (forthcoming ElasticSearch). This bug is meant to track any issues that arise as DXR is spun up as a docker image. The first issue is that of how to make it easy for Windows and OSX developers to work with their IDE of choice on a codebase that is shared with their Host system, the boot2docker VirtualBox shim, and the Docker container itself. boot2docker developers have opted not to include the required VirtualBox guest additions in the shim VM per https://github.com/boot2docker/boot2docker/issues/282#issuecomment-44601104 My initial suggestion is thorough documentation to manually share files between systems, or providing a custom ISO. From there Docker & DXR can be married together and development can proceed apace.
We had some more motivations for this, not all of which I remember right now. One of them was the ability to run tests on TravisCI, once they get their Docker support going. Remember any others?
Linking to the pull request: https://github.com/mozilla/dxr/pull/336
Also, Kendall's got our indexing process using Docker containers now, so he's written scripts to add DXR and its requirements to a pretty blank Ubuntu image: https://github.com/klibby/dxr-docker. Perhaps we could move those scripts into DXR's repo, combine them with the best of vagrant_provision.sh, and use them for both the indexing nodes and to provision our dev environment.
Here's how to use Docker on OS X without Virtualbox (using xhyve instead): https://github.com/ailispaw/boot2docker-xhyve. No more manually allocating RAM!
Commit pushed to master at https://github.com/mozilla/dxr https://github.com/mozilla/dxr/commit/a7e2e99072eb8d58ccd93049a8ce60e49e3d5c50 Replace Vagrant with Docker. Fix bug 1139516. Fix bug 1068854. Fix bug 1220965. Fix bug 964460. Close #494, close #488, and close #415. Future: * Refactor things so they're more reusable in prod. * Maybe publish docker images. What use is this? Will it make deploys any faster or more reliable? How do people trust them? * Pass ES_HEAP_SIZE (or something) env var through to the es container, as described at https://hub.docker.com/r/library/elasticsearch/. * Make sure ES data persists across container instantiations. * Call docker-machine automatically on the Mac. * Maybe we can move the venv back out of the source dir for performance. With docker-compose in the picture now, we may be able to convince it with volumes-from or something to not evaporate things outside the source dir from one "make shell" to the next. * When docker-compose supports --build-arg (docker/compose#2111), we can add one for UID so we can, from an env var on the host, set the UID of the unprivileged user in the container. This will solve the problem of non-matching UIDs for Linux devs and let us get rid of the chmod in Travis.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.