Incorrect galaxy.yml location

[innovate-invent]

Should the path not be to /export/config/? Starting an instance requires me to bash in and symlink /etc/galaxy/galaxy.yml -> /export/config/galaxy.yml in order to set the #admin_users: ''

https://github.com/bgruening/docker-galaxy-stable/blob/729d2a86db0416e3acb8e2ae1b9b3b9f771c54e3/compose/galaxy-base/Dockerfile#L20

[abretaud]

The easiest way to change the config is to set environment variables, for example for admin_users: GALAXY_CONFIG_ADMIN_USERS Every config key in the config.yml file have a corresponding GALAXYCONFIG* variable

[pcm32]

I agree with @abretaud the preferred way for you to make any settings changes is to use env variables.

[innovate-invent]

It seems a little odd to move the galaxy config out of the standard yml file and into an env file. What is the benefit of maintaining a separate file?

[pcm32]

The compose setup is meant to be used within container orchestration setups (docker compose, kubernetes, mesos, etc), where the most typical and flexible way to inject configurations for containerised running applications is through environment variables. There is no such a thing as an environment variables file per-se, normally you will instruct the container orchestrator to establish those variables on certain values. These settings can be injected at multiple levels (container build time, orchestrator init, runtime, orchestration package manager, etc) or inferred by scripts at those same levels (and hence they are not set at a single file or point).

[innovate-invent]

Wouldn't that be a env_file? That would imply you have to rebuild the container to change a galaxy config rather than just restart it.

[pcm32]

You could as well use a single file with all your environment vars, BUT the whole point is that using injection of environment variables gives us the flexibility to be able to do it not through a single file/point, but at different stages of the process. On our helm deployments with have variables defined by default inside the chart, others set on the provided config file when installing the application, on top of variables that get set at the Dockerfile, at container build time (build script), variables that get set through ansible and variables that get set by scripts when running (like the workflow installing scripts).

[innovate-invent]

Would it make sense to inject those env variable values into the /export/config/galaxy.yml at the end of the build process to allow native run time configuration?

[innovate-invent]

@abretaud @pcm32 As per #495 environment variables are not the preferred method to configure galaxy

[bgruening]

@innovate-invent that is not true. It depends on your use-case and for most of the configuration settings, it's perfectly fine to use them.

[innovate-invent]

I agree, environment variables are acceptable when Galaxy is being run for internal use only. The issue arises when people start building Galaxy based services that are distributed with the intent of being publicly accessible and using the 'preferred' method of environment variables for deployment. I am already seeing docker files with ENV commands with the intent of being used as off the shelf services labs can set up to host public processing of their databases.

You can argue that the developers are just not configuring the docker properly and it is their problem, but the whole point is to encourage secure configuration practices so nothing leaks downstream by non-expert users.

This should be the preferred method: https://github.com/bgruening/docker-galaxy-stable/issues/495#issuecomment-481032228

[chambm]

Could the sensitive environment variables be removed from Galaxy's environment after being used to configure galaxy.ym land start Galaxy?

[innovate-invent]

The environment variable values are not written to the yml, Galaxy reads them directly. I am not sure but I believe you can not unset an environment variable for a running process.

[bgruening]

The new 24.1 image contains a lot of changes and reflects the latest developments in Galaxy. I would like to close this PR, but please feel free to reopen and rebase against the latest version.

Please give it a try:

docker run -p 8080:80 -p 8021:21 -p 4002:4002 --privileged=true -e "GALAXY_DESTINATIONS_DEFAULT=slurm_cluster_docker"   -v /tmp/galaxy-data/:/export/ quay.io/bgruening/galaxy:24.1

... or any other combination. The readme has been updated. Please add any useful tip to it.

For a list of changes, see the Changelog.