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/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.

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
> 
___________________________________________________________
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:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to