On Sun, Aug 2, 2015 at 4:59 AM, Oksana <okorol@gmail.com> wrote:

We only have one cluster, so we will have both test and production environments running on it. I understand that at a minimum we'd need different Galaxy home dir and UID/GID.

For our local deployment of Galaxy with Docker, which was inspired by a very early version of Björn's docker-galaxy-stable, we use an entrypoint script to remap the Galaxy user's UID and GID inside the container from environment variables GALAXY_UID and GALAXY_GID passed to `docker run`:

https://github.com/fredhutchio/docker-galaxy/blob/aa07c5f684d55499a87e77c62aceda707b63077f/docker-entrypoint.sh#L30

Just below that, starting at line 42, is an admittedly hacky way of relocating the Galaxy directory hierarchy (exported data and/or code) from its container default location /galaxy to another location specified by the GALAXY_ROOT environment variable. It essentially turns the container into an installer when `--reroot` or `--upgrade` is passed to the entrypoint script. `--reroot` copies the container's entire /galaxy hierarchy to $GALAXY_ROOT for initializing an instance from the container. `--upgrade` copies just the container's Galaxy distribution in /galaxy/stable to $GALAXY_ROOT/stable (aka $GALAXY_HOME) for upgrading an existing instance from a more recent image.

It's definitely nice being able to configure things like this at runtime for e.g. differentiating between test and production! Would functionality like this be useful/welcome in docker-galaxy-stable?

Cheers,

Brian

Brian Claywell | programmer/analyst

Matsen Group | http://matsen.fredhutch.org

Fred Hutchinson Cancer Research Center