Added Dockerfile

[hershman]

This PR addresses Issue #305 by adding scripts/Dockerfile, which can be used to quickly launch a server instance.

[jeromekelleher]

Should we install from git or from PyPI for the default Docker install? I would say PyPI probably.

[hershman]

The current version PyPI server has a wormtable dependency that won't
compile because of a missing header.

On Thu, Apr 2, 2015 at 1:02 AM Jerome Kelleher notifications@github.com
wrote:

In scripts/Dockerfile
#326 (comment):

+# Install packages
+RUN apt-get install -y tar git curl nano wget dialog net-tools build-essential python python-dev python-distribute python-pip zlib1g-dev python-virtualenv apache2 libapache2-mod-wsgi
+
+# Enable wsgi module
+RUN a2enmod wsgi
+
+# Create cache directories
+RUN mkdir /var/cache/apache2/python-egg-cache && \

• chown www-data:www-data /var/cache/apache2/python-egg-cache/

+# Set up GA4GH server
+RUN mkdir /srv/ga4gh
+WORKDIR /srv/ga4gh
+RUN virtualenv ga4gh-server-env
+RUN /bin/bash -c "source ga4gh-server-env/bin/activate"
+RUN pip install git+https://github.com/ga4gh/server

Should we install from git or from PyPI for the default Docker install? I
would say PyPI probably.

—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/server/pull/326/files#r27638512.

[jeromekelleher]

Ah OK. This will be fixed today, when we tag and upload 0.1.0a3.

[jeromekelleher]

This is fantastic @hershman, thanks! This will make deployment a breeze, so I think we should definitely include it. I won't have a chance to test it out until next week, unfortunately, as we're concentrating on shipping the 0.1.0 beta release tomorrow.

Is scripts the right place for this to live everyone? We're currently using scripts as our location for internal-use-only development tools. The docker file is something different though. Should we make a new directory (say, deploy) for deployment stuff like this?

[jeromekelleher]

Actually, is there any point in using a virtualenv inside a Docker image?

[hershman]

This blog post has a pretty good discussion about that issue. They seem undecided.

[jeromekelleher]

Interesting... I guess we should play with both options and see what works better for us.

[dcolligan]

Closing this PR. All PRs should now be made against the develop branch, not the master branch.

[dcolligan]

(the way to do this is to push the same code with a new branch name and in the PR UI select to merge against develop instead of master -- develop will be made the default shortly)

[jeromekelleher]

Sorry about this @hershman --- we're changing over to a new development branching model as discussed in #330, and your PR got caught in the middle. The structure of the documentation has changed too, and we no longer put detailed information in the README. There's a placeholder for your information in docs/source/installation.rst. Basically, if you copy your docs code in there and reopen the PR I think we should be ready to merge quickly.