Hi Brian, thanks for you mail! Very appreciated, please see my comments inline.
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`:
Is this really needed. We could do this in the main image as well, but currently I haven't seen a compelling usecase for this. The downside is that we need to do a lot of `chown/chmod` magic during container startup. But I'm totally willing to do so, if this is was the community is needed. Please also see this latest PR: https://github.com/bgruening/docker-galaxy-stable/pull/71
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.
Interesting! At least for easier upgrading we took a slightly different approach, described here: https://github.com/bgruening/docker-galaxy-stable/tree/dev#upgrading-images Also we store nowadays many original config files in /etc/galaxy/ to make the upgrading smoother. I would be interested in your opinion and if these latest developments would solve your use-cases.
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?
I'm all for it, if this is what is needed by the community. I would just like to keep the initial startup magic by default as minimal as possible. Thanks a lot for your comments, Bjoern
Cheers,
Brian