On Sun, Aug 2, 2015 at 4:59 AM, Oksana <oko...@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`:


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?



Brian Claywell | programmer/analyst
Matsen Group   | http://matsen.fredhutch.org <http://matsen.fhcrc.org/>
Fred Hutchinson Cancer Research Center
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

To search Galaxy mailing lists use the unified search at:

Reply via email to