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/aa07c5f684d55499a87e77c62a... 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 <http://matsen.fhcrc.org/> Fred Hutchinson Cancer Research Center