{"id":20674622,"url":"https://github.com/bgruening/docker-galaxy","last_synced_at":"2025-05-16T00:06:29.788Z","repository":{"id":19626359,"uuid":"22878143","full_name":"bgruening/docker-galaxy","owner":"bgruening","description":":whale::bar_chart::books: Docker Images tracking the stable Galaxy releases.","archived":false,"fork":false,"pushed_at":"2025-02-25T21:43:12.000Z","size":2496,"stargazers_count":233,"open_issues_count":36,"forks_count":137,"subscribers_count":18,"default_branch":"main","last_synced_at":"2025-05-14T18:17:06.117Z","etag":null,"topics":["data-science","docker-image","galaxy","galaxyproject","science"],"latest_commit_sha":null,"homepage":"http://bgruening.github.io/docker-galaxy","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/bgruening.png","metadata":{"files":{"readme":"README.md","changelog":"Changelog.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2014-08-12T13:26:14.000Z","updated_at":"2025-05-10T20:30:47.000Z","dependencies_parsed_at":"2024-12-22T19:32:50.034Z","dependency_job_id":"a92e44ef-b55a-4877-bfff-8cd28d985f45","html_url":"https://github.com/bgruening/docker-galaxy","commit_stats":null,"previous_names":[],"tags_count":26,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bgruening%2Fdocker-galaxy","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bgruening%2Fdocker-galaxy/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bgruening%2Fdocker-galaxy/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bgruening%2Fdocker-galaxy/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/bgruening","download_url":"https://codeload.github.com/bgruening/docker-galaxy/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254404268,"owners_count":22065641,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["data-science","docker-image","galaxy","galaxyproject","science"],"created_at":"2024-11-16T21:04:13.039Z","updated_at":"2025-05-16T00:06:29.757Z","avatar_url":"https://github.com/bgruening.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"[![DOI](https://zenodo.org/badge/5466/bgruening/docker-galaxy-stable.svg)](https://zenodo.org/badge/latestdoi/5466/bgruening/docker-galaxy-stable)\n[![Build Status](https://travis-ci.org/bgruening/docker-galaxy-stable.svg?branch=master)](https://travis-ci.org/bgruening/docker-galaxy-stable)\n[![Docker Repository on Quay](https://quay.io/repository/bgruening/galaxy/status \"Docker Repository on Quay\")](https://quay.io/repository/bgruening/galaxy)\n[![Gitter](https://badges.gitter.im/bgruening/docker-galaxy-stable.svg)](https://gitter.im/bgruening/docker-galaxy-stable?utm_source=badge\u0026utm_medium=badge\u0026utm_campaign=pr-badge)\n![docker pulls](https://img.shields.io/docker/pulls/bgruening/galaxy-stable.svg) ![docker stars](https://img.shields.io/docker/stars/bgruening/galaxy-stable.svg)\n[![docker image stats](https://images.microbadger.com/badges/image/bgruening/galaxy-stable.svg)](https://microbadger.com/images/bgruening/galaxy-stable \"Get your own image badge on microbadger.com\")\n\nGalaxy Docker Image\n===================\n\nThe [Galaxy](http://www.galaxyproject.org) [Docker](http://www.docker.io) Image is an easy distributable full-fledged Galaxy installation, that can be used for testing, teaching and presenting new tools and features.\n\nOne of the main goals is to make access to entire tool suites as easy as possible. Usually,\nthis includes the setup of a public available web-service that needs to be maintained, or that the Tool-user needs to either setup a Galaxy Server by its own or to have Admin access to a local Galaxy server.\nWith docker, tool developers can create their own Image with all dependencies and the user only needs to run it within docker.\n\nThe Image is based on [Ubuntu 22.04 LTS](http://releases.ubuntu.com/22.04/) and all recommended Galaxy requirements are installed. The following chart should illustrate the [Docker](http://www.docker.io) image hierarchy we have build to make is as easy as possible to build on different layers of our stack and create many exciting Galaxy flavors.\n\n![Docker hierarchy](https://raw.githubusercontent.com/bgruening/docker-galaxy-stable/master/chart.png)\n\nBreaking changes\n================\n\n:information_source: After a long pause, due to interesting times at the beginning of the \"golden 2020s\", we are finally back with release `24.1`. Many things have changed in Galaxy.\nIt is deployed completely differently and gained many new features with many new dependencies. We recommend starting with a fresh `/export` folder and contacting us if you encounter any problems. \n\n# Table of Contents \u003ca name=\"toc\" /\u003e\n\n- [Usage](#Usage)\n  - [Upgrading images](#Upgrading-images)\n    - [PostgreSQL migration](#Postgresql-migration)\n  - [Enabling Interactive Tools in Galaxy](#Enabling-Interactive-Tools-in-Galaxy)\n  - [Using passive mode FTP or SFTP](#Using-passive-mode-FTP-or-SFTP)\n  - [Using Parent docker](#Using-Parent-docker)\n  - [Galaxy Report Webapp](#Galaxy-Report-Webapp)\n  - [RabbitMQ Management](#RabbitMQ-Management)\n  - [Flower Webapp](#Flower-Webapp)\n  - [Galaxy's config settings](#Galaxys-config-settings)\n  - [Configuring Galaxy's behind a proxy](#Galaxy-behind-proxy)\n  - [On-demand reference data with CVMFS](#cvmfs)\n  - [Personalize your Galaxy](#Personalize-your-Galaxy)\n  - [Deactivating services](#Deactivating-services)\n  - [Restarting Galaxy](#Restarting-Galaxy)\n  - [Advanced Logging](#Advanced-Logging)\n  - [Running on an external cluster (DRM)](#Running-on-an-external-cluster-(DRM))\n    - [Basic setup for the filesystem](#Basic-setup-for-the-filesystem)\n    - [Using an external Slurm cluster](#Using-an-external-Slurm-cluster)\n    - [Using an external Grid Engine cluster](#Using-an-external-Grid-Engine-cluster)\n    - [Tips for Running Jobs Outside the Container](#Tips-for-Running-Jobs-Outside-the-Container)\n- [Enable Galaxy to use BioContainers (Docker)](#auto-exec-tools-in-docker)\n- [Magic Environment variables](#Magic-Environment-variables)\n- [HTTPS Support](#HTTPS-Support)\n- [Lite Mode](#Lite-Mode)\n- [Extending the Docker Image](#Extending-the-Docker-Image)\n  - [List of Galaxy flavours](#List-of-Galaxy-flavours)\n- [Integrating non-Tool Shed tools into the container](#Integrating-non-Tool-Shed-tools-into-the-container)\n- [Users \u0026 Passwords](#Users-Passwords)\n- [Development](#Development)\n- [Requirements](#Requirements)\n- [Changelog](./Changelog.md)\n- [Support \u0026 Bug Reports](#Support-Bug-Reports)\n\n\n# Usage \u003ca name=\"Usage\" /\u003e [[toc]](#toc)\nThis chapter explains how to launch the container manually.\n\nAt first you need to install docker. Please follow the [very good instructions](https://docs.docker.com/installation/) from the Docker project.\n\nAfter the successful installation, all you need to do is:\n\n```sh\ndocker run -d -p 8080:80 -p 8021:21 -p 8022:22 quay.io/bgruening/galaxy\n```\n\nI will shortly explain the meaning of all the parameters. For a more detailed description please consult the [docker manual](http://docs.docker.io/), it's really worth reading.\n\nLet's start:\n- `docker run` will run the Image/Container for you.\n\n    In case you do not have the Container stored locally, docker will download it for you.\n\n- `-p 8080:80` will make the port 80 (inside of the container) available on port 8080 on your host. Same holds for port 8021 and 8022, that can be used to transfer data via the FTP or SFTP protocol, respectively.\n\n    Inside the container a nginx Webserver is running on port 80 and that port can be bound to a local port on your host computer. With this parameter you can access your Galaxy\n    instance via `http://localhost:8080` immediately after executing the command above. If you work with the [Docker Toolbox](https://www.docker.com/products/docker-toolbox) on Mac or Windows,\n    you need to connect to the machine generated by 'Docker Quickstart'. You get its IP address from `docker-machine ls` or from the first line in the terminal, e.g.: `docker is configured to use the default machine with IP 192.168.99.100`.\n\n- `quay.io/bgruening/galaxy` is the Image/Container name, that directs docker to the correct path in the [docker index](https://quay.io/repository/bgruening/galaxy?tab=tags).\n- `-d` will start the docker container in daemon mode.\n\nFor an interactive session, you can execute:\n\n```sh\ndocker run -i -t -p 8080:80 \\\n    quay.io/bgruening/galaxy \\\n    /bin/bash\n```\n\nand run the `startup` script by yourself, to start PostgreSQL, nginx and Galaxy.\n\nDocker images are \"read-only\", all your changes inside one session will be lost after restart. This mode is useful to present Galaxy to your colleagues or to run workshops with it. To install Tool Shed repositories or to save your data you need to export the calculated data to the host computer.\n\nFortunately, this is as easy as:\n\n```sh\ndocker run -d -p 8080:80 \\\n    -v /home/user/galaxy_storage/:/export/ \\\n    quay.io/bgruening/galaxy\n```\n\nWith the additional `-v /home/user/galaxy_storage/:/export/` parameter, Docker will mount the local folder `/home/user/galaxy_storage` into the Container under `/export/`. A `startup.sh` script, that is usually starting nginx, PostgreSQL and Galaxy, will recognize the export directory with one of the following outcomes:\n\n- In case of an empty `/export/` directory, it will move the [PostgreSQL](http://www.postgresql.org/) database, the Galaxy database directory, Shed Tools and Tool Dependencies and various config scripts to /export/ and symlink back to the original location.\n- In case of a non-empty `/export/`, for example if you continue a previous session within the same folder, nothing will be moved, but the symlinks will be created.\n\nThis enables you to have different export folders for different sessions - means real separation of your different projects.\n\nYou can also collect and store `/export/` data of Galaxy instances in a dedicated docker [Data  volume Container](https://docs.docker.com/engine/userguide/dockervolumes/) created by:\n\n```sh\ndocker create -v /export \\\n    --name galaxy-store \\\n    quay.io/bgruening/galaxy \\\n    /bin/true\n```\n\nTo mount this data volume in a Galaxy container, use the  `--volumes-from` parameter:\n\n```sh\ndocker run -d -p 8080:80 \\\n    --volumes-from galaxy-store \\\n    quay.io/bgruening/galaxy\n```\n\nThis also allows for data separation, but keeps everything encapsulated within the docker engine (e.g. on OS X within your `$HOME/.docker` folder - easy to backup, archive and restore. This approach, albeit at the expense of disk space, avoids the problems with permissions [reported](https://github.com/bgruening/docker-galaxy-stable/issues/68) for data export on non-Linux hosts.\n\n\n## Upgrading images \u003ca name=\"Upgrading-images\" /\u003e [[toc]](#toc)\n\nWe will release a new version of this image concurrent with every new Galaxy release. For upgrading an image to a new version we have assembled a few hints for you. Please, take in account that upgrading may vary depending on your Galaxy installation, and the changes in new versions. Use this example carefully!\n\n* Create a test instance with only the database and configuration files. This will allow testing to ensure that things run but won't require copying all of the data.\n* New unmodified configuration files are always stored in a hidden directory called `.distribution_config`. Use this folder to diff your configurations with the new configuration files shipped with Galaxy. This prevents needing to go through the change log files to find out which new files were added or which new features you can activate.\n\nHere are 2 suggested upgrade methods, a quick one, and a safer one.\n\n### The quick upgrade method\n\nThis method involves less data copying, which makes the process quicker, but makes it impossible to downgrade in case of problems.\n\nIf you are upgrading from \u003c19.05 to \u003e=19.05, you need to migrate the PostgreSQL database, have a look at [PostgreSQL migration](#Postgresql-migration).\n\n\n1. Stop the old Galaxy container\n\n```sh\ndocker stop \u003cold_container_name\u003e\ndocker pull quay.io/bgruening/galaxy\n```\n\n2. Run the container with the updated image\n\n```sh\ndocker run -p 8080:80 -v /data/galaxy-data:/export --name \u003cnew_container_name\u003e quay.io/bgruening/galaxy\n```\n\n3. Use diff to find changes in the config files (only if you changed any config file).\n\n```sh\ncd /data/galaxy-data/.distribution_config\nfor f in *; do echo $f; diff $f ../galaxy/config/$f; read; done\n```\n\n4. Upgrade the database schema\n\n```sh\ndocker exec -it \u003cnew_container_name\u003e bash\ngalaxyctl stop\nsh manage_db.sh upgrade\nexit\n```\n5. Restart Galaxy\n\n```sh\ndocker exec -it \u003cnew_container_name\u003e galaxyctl start\n```\n\n(Alternatively, restart the whole container)\n\n\n### The safe upgrade method\n\nWith this method, you keep a backup in case you decide to downgrade, but requires some potentially long data copying.\n\n* Note that copying database and datasets can be expensive if you have many GB of data.\n* If you are upgrading from \u003c19.05 to \u003e=19.05, you need to migrate the PostgreSQL database, have a look at [PostgreSQL migration](#Postgresql-migration).\n\n1. Download newer version of the Galaxy image\n\n  ```\n  $ sudo docker pull quay.io/bgruening/galaxy\n  ```\n2. Stop and rename the current galaxy container\n\n  ```\n  $ sudo docker stop galaxy-instance\n  $ sudo docker rename galaxy-instance galaxy-instance-old\n  ```\n3. Rename the data directory (the one that is mounted to /export in the docker)\n\n  ```\n  $ sudo mv /data/galaxy-data /data/galaxy-data-old\n  ```\n4. Run a new Galaxy container using newer image and wait while Galaxy generates the default content for /export\n\n  ```\n  $ sudo docker run -p 8080:80 -v /data/galaxy-data:/export --name galaxy-instance quay.io/bgruening/galaxy\n  ```\n5. Stop the Galaxy container\n\n  ```\n  $ sudo docker stop galaxy-instance\n  ```\n6. Replace the content of the postgres database by the old db data\n\n  ```\n  $ sudo rm -r /data/galaxy-data/postgresql/\n  $ sudo rsync -var /data/galaxy-data-old/postgresql/  /data/galaxy-data/postgresql/\n  ```\n7. Use diff to find changes in the config files (only if you changed any config file).\n\n  ```\n  $ cd /data/galaxy-data/.distribution_config\n  $ for f in *; do echo $f; diff $f ../../galaxy-data-old/galaxy/config/$f; read; done\n  ```\n8. Copy all the users' datasets to the new instance\n\n  ```\n  $ sudo rsync -var /data/galaxy-data-old/galaxy/database/files/* /data/galaxy-data/galaxy/database/files/\n  ```\n9. Copy all the installed tools\n\n  ```\n  $ sudo rsync -var /data/galaxy-data-old/tool_deps/* /data/galaxy-data/tool_deps/\n  $ sudo rsync -var /data/galaxy-data-old/galaxy/database/shed_tools/* /data/galaxy-data/galaxy/database/shed_tools/\n  $ sudo rsync -var /data/galaxy-data-old/galaxy/database/config/* /data/galaxy-data/galaxy/database/config/\n  ```\n10. Copy the welcome page and all its files.\n\n  ```\n  $ sudo rsync -var /data/galaxy-data-old/welcome* /data/galaxy-data/\n  ```\n11. Create an auxiliary docker in interactive mode and upgrade the database.\n\n  ```\n  $ sudo docker run -it --rm -v /data/galaxy-data:/export quay.io/bgruening/galaxy /bin/bash\n  # Startup all processes\n  \u003e startup \u0026\n  #Upgrade the database to the most recent version\n  \u003e sh manage_db.sh upgrade\n  #Logout\n  \u003e exit\n  ```\n12. Start the docker and test\n\n  ```\n  $ sudo docker start galaxy-instance\n  ```\n13. Clean the old container and image\n\n\n### Postgresql migration \u003ca name=\"Postgresql-migration\" /\u003e [[toc]](#toc)\n\nIn the 19.05 version, Postgresql was updated from version 9.3 to version 11.5. If you are upgrading from a version \u003c19.05, you will need to migrate the database.\nYou can do it the following way (based on the \"The quick upgrade method\" above):\n\n1. Stop Galaxy in the old container\n\n```sh\ndocker exec -it \u003cold_container_name\u003e galaxyctl stop\n```\n\n2. Dump the old database\n\n```sh\ndocker exec -it \u003cold_container_name\u003e bash\nsu postgres\npg_dumpall --clean \u003e /export/postgresql/9.3dump.sql\nexit\nexit\n```\n\n3. Update the container (= step 1 of the \"The quick upgrade method\" above)\n\n```sh\ndocker stop \u003cold_container_name\u003e\ndocker pull quay.io/bgruening/galaxy\n```\n\n4. Run the container with the updated image (= step 2 of the \"The quick upgrade method\" above)\n\n```sh\ndocker run -p 8080:80 -v /data/galaxy-data:/export --name \u003cnew_container_name\u003e quay.io/bgruening/galaxy\n```\n\n5. Restore the dump to the new postgres version\n\nWait for the startup process to finish (Galaxy should be accessible)\n\n```sh\ndocker exec -it \u003cnew_container_name\u003e bash\ngalaxyctl stop\nsu postgres\npsql -f /export/postgresql/9.3dump.sql postgres\nexit\nexit\n```\n\n6. Use diff to find changes in the config files (only if you changed any config file). (= step 3 of the \"The quick upgrade method\" above)\n\n```sh\ncd /data/galaxy-data/.distribution_config\nfor f in *; do echo $f; diff $f ../galaxy/config/$f; read; done\n```\n\n7. Upgrade the database schema (= step 4 of the \"The quick upgrade method\" above)\n\n```sh\ndocker exec -it \u003cnew_container_name\u003e bash\ngalaxyctl stop\nsh manage_db.sh upgrade\nexit\n```\n\n5. Restart Galaxy (= step 5 of the \"The quick upgrade method\" above)\n\n```sh\ndocker exec -it \u003cnew_container_name\u003e galaxyctl start\n```\n\n(Alternatively, restart the whole container)\n\n6. Clean old files\n\nIf you are *very* sure that everything went well, you can delete `/export/postgresql/9.3dump.sql` and `/export/postgresql/9.3/` to save some space.\n\n## Enabling Interactive Tools in Galaxy \u003ca name=\"Enabling-Interactive-Tools-in-Galaxy\" /\u003e [[toc]](#toc)\n\nInteractive Tools (IT) are sophisticated ways to extend Galaxy with powerful services, like [Jupyter](http://jupyter.org/), in a secure and reproducible way.\n\nFor this we need to be able to launch Docker containers inside our Galaxy Docker container.\n\n```sh\ndocker run -d -p 8080:80 -p 8021:21 -p 4002:4002 \\\n    --privileged=true \\\n    -v /home/user/galaxy_storage/:/export/ \\\n    quay.io/bgruening/galaxy\n```\n\nThe port 4002 is the proxy port that is used to handle Interactive Tools. `--privileged` is needed to start docker containers inside docker.\n\nAdditionally, you can set the `GALAXY_DOMAIN` environment variable to specify the domain name for your Galaxy instance to ensure that domain-based ITs work correctly. By default, it is set to `localhost`. If you have your own domain, you can specify it instead.\n\nIf you're using the default job configuration, set the `GALAXY_DESTINATIONS_DEFAULT` environment variable to a Docker-enabled destination. By default, this is set to `slurm_cluster`, so you'll need to update it accordingly. Alternatively, you can also provide your own job configuration file. \n\n```sh\ndocker run -d -p 8080:80 -p 8021:21 -p 4002:4002 \\\n    --privileged=true \\\n    -v /home/user/galaxy_storage/:/export/ \\\n    -e \"GALAXY_DOMAIN=your.domain.com\" \\\n    -e \"GALAXY_DESTINATIONS_DEFAULT=slurm_cluster_docker\" \\\n    quay.io/bgruening/galaxy\n```\n\n\n## Using passive mode FTP or SFTP \u003ca name=\"Using-passive-mode-FTP-or-SFTP\" /\u003e [[toc]](#toc)\n\nBy default, FTP servers running inside of docker containers are not accessible via passive mode FTP, due to not being able to expose extra ports. To circumvent this, you can use the `--net=host` option to allow Docker to directly open ports on the host server:\n\n```sh\ndocker run -d \\\n    --net=host \\\n    -v /home/user/galaxy_storage/:/export/ \\\n    quay.io/bgruening/galaxy\n```\n\nNote that there is no need to specifically bind individual ports (e.g., `-p 80:80`) if you use `--net`.\n\nAn alternative to FTP and it's shortcomings it to use the SFTP protocol via port 22. Start your Galaxy container with a port binding to 22.\n\n```sh\ndocker run -i -t -p 8080:80 -p 8022:22 \\\n    -v /home/user/galaxy_storage/:/export/ \\\n    quay.io/bgruening/galaxy\n```\n\nAnd use for example [Filezilla](https://filezilla-project.org/) or the `sftp` program to transfer data:\n\n```sh\nsftp -v -P 8022 -o User=admin@example.org localhost \u003c\u003c\u003c $'put \u003cYOUR FILE HERE\u003e'\n```\n\n\n## Using Parent docker \u003ca name=\"Using-Parent-docker\" /\u003e [[toc]](#toc)\n\nOn some linux distributions, Docker-In-Docker can run into issues (such as running out of loopback interfaces). If this is an issue, you can use a 'legacy' mode that use a docker socket for the parent docker installation mounted inside the container. To engage, set the environmental variable `DOCKER_PARENT`\n\n```sh\ndocker run -p 8080:80 -p 8021:21 \\\n    --privileged=true -e DOCKER_PARENT=True \\\n    -v /var/run/docker.sock:/var/run/docker.sock \\\n    -v /home/user/galaxy_storage/:/export/ \\\n    quay.io/bgruening/galaxy\n```\n\n## Galaxy Report Webapp \u003ca name=\"Galaxy-Report-Webapp\" /\u003e [[toc]](#toc)\n\nFor admins wishing to have more information on the status of a galaxy instance, the Galaxy Report Webapp is served on `http://localhost:8080/reports`. As default this site is password protected with `admin:admin`. You can change this by providing a `common_htpasswd` file in `/home/user/galaxy_storage/`.\n\nYou can disable the Report Webapp entirely by providing the environment variable `NONUSE` during container startup.\n\n```sh\ndocker run -p 8080:80 \\\n    -e \"NONUSE=reports\" \\\n    quay.io/bgruening/galaxy\n```\n\n## RabbitMQ Management \u003ca name=\"RabbitMQ-Management\" /\u003e [[toc]](#toc)\n\nRabbitMQ is used as the broker for services like Celery. RabbitMQ provides a dedicated web interface for managing message queues, accessible at `http://localhost:8080/rabbitmq/`. This interface allows you to monitor queues, exchanges, bindings, and more. By default, it is password protected with `admin:admin`, but the credentials can be changed after logging in.\n\nTo completely disable RabbitMQ, you can set the `NONUSE` environment variable during container startup.\n\n```sh\ndocker run -p 8080:80 \\\n    -e \"NONUSE=rabbitmq\" \\\n    quay.io/bgruening/galaxy\n```\n\n## Flower Webapp \u003ca name=\"Flower-Webapp\" /\u003e [[toc]](#toc)\n\nFlower is a web-based tool for monitoring and administering Celery. It is accessible at `http://localhost:8080/flower`. By default, this site is password protected with `admin:admin`. You can change this by providing a `common_htpasswd` file in `/home/user/galaxy_storage/`.\n\nThe Flower Webapp will only be available if both Celery and RabbitMQ are enabled, meaning the environment variable `NONUSE` does not include `celery` and `rabbitmq`. To completely disable the Flower Webapp, you can set the `NONUSE` environment variable during container startup.\n\n```sh\ndocker run -p 8080:80 \\\n    -e \"NONUSE=flower\" \\\n    quay.io/bgruening/galaxy\n```\n\n## Galaxy's config settings \u003ca name=\"Galaxys-config-settings\" /\u003e [[toc]](#toc)\n\nEvery Galaxy configuration parameter in `config/galaxy.yml` can be overwritten by passing an environment variable to the `docker run` command during startup. The name of the environment variable has to be:\n`GALAXY_CONFIG`+ *the_original_parameter_name_in_capital_letters*\nFor example, you can set the Galaxy session timeout to 5 minutes and set your own Galaxy brand by invoking the `docker run` like this:\n\n```sh\ndocker run -p 8080:80 \\\n    -e \"GALAXY_CONFIG_BRAND='My own Galaxy flavour'\" \\\n    -e \"GALAXY_CONFIG_SESSION_DURATION=5\" \\\n    quay.io/bgruening/galaxy\n```\n\nNote, that if you would like to run any of the [cleanup scripts](https://galaxyproject.org/admin/config/performance/purge-histories-and-datasets/), you will need to add the following to `/export/galaxy/config/galaxy.yml`:\n\n```\ndatabase_connection = postgresql://galaxy:galaxy@localhost:5432/galaxy\nfile_path = /export/galaxy/database/files\n```\n\n## Security Configuration\n\n*By default* the `admin_users` and `bootstrap_admin_api_key` variables are set to:\n\n```\nadmin_users: admin@example.org\nbootstrap_admin_api_key: HSNiugRFvgT574F43jZ7N9F3\n```\n\nAdditionally, Galaxy encodes various internal values that can be part of output using a secret string configurable as `id_secret` in the config file (use 5-65 bytes long string).\nThis prevents 'guessing' of Galaxy's internal database sequences. Example:\n\n```\nid_secret: d5c910cc6e32cad08599987ab64dcfae\n```\n\nYou should manually change all three configuration variables above in `/export/galaxy/config/galaxy.yml`.\n\nAlternatively, you can pass the security configuration when running the image but please note that it is a security problem.\nE.g. if a tool exposes all `env`'s your secret API key will also be exposed.\n\nIn addition with 24.2 we enabled Galaxy Vault configuration. This enables users to store secrets in a user-owned password safe, called vault.\nIt is highly recommended to change the pre-configured key under `$GALAXY_CONFIG_DIR/vault_conf.yml` following the instructions inside the file.\n\n\n## Configuring Galaxy's behind a proxy \u003ca name=\"Galaxy-behind-proxy\" /\u003e [[toc]](#toc)\n\nIf your Galaxy docker instance is running behind an HTTP proxy server, and if you're accessing it with a specific path prefix (e.g. http://www.example.org/some/prefix/), you need to make Galaxy aware of it. There is an environment variable available to do so:\n\n```\nPROXY_PREFIX=/some/prefix\n```\n\nYou can and should overwrite these during launching your container:\n\n```sh\ndocker run -p 8080:80 \\\n    -e \"PROXY_PREFIX=/some/prefix\" \\\n    quay.io/bgruening/galaxy\n```\n\n## On-demand reference data with CVMFS \u003ca name=\"cvmfs\" /\u003e [[toc]](#toc)\nBy default, Galaxy instances launched with this image will have on-demand access to approximately 4TB of\nreference genomes and indexes. These are the same reference data available on the main Galaxy server.\nThis is achieved by connecting to Galaxy's CernVM filesystem (CVMFS) at `cvmfs-config.galaxyproject.org` repository, which provides automatic configuration for all galaxyproject.org CVMFS repositories, including `data.galaxyproject.org`, and ensures they remain up to date.\nThe CVMFS capability doesn't add to the size of the Docker image, but when running, CVMFS maintains\na cache to keep the most recently used data on the local disk.\n\n*Note*: for CVMFS directories to be mounted-on-demand with `autofs`, you must launch Docker as `--privileged`\n\n\n## Personalize your Galaxy \u003ca name=\"Personalize-your-Galaxy\" /\u003e [[toc]](#toc)\n\nThe Galaxy welcome screen can be changed by providing a `welcome.html` page in `/home/user/galaxy_storage/`. All files starting with `welcome` will be copied during startup and served as introduction page. If you want to include images or other media, name them `welcome_*` and link them relative to your `welcome.html` ([example](`https://github.com/bgruening/docker-galaxy-stable/blob/master/galaxy/welcome.html`)).\n\n\n## Deactivating services \u003ca name=\"Deactivating-services\" /\u003e [[toc]](#toc)\n\nNon-essential services can be deactivated during startup. Set the environment variable `NONUSE` to a comma separated list of services. Currently, `postgres`, `cron`, `proftp`, `reports`, `nodejs`, `condor`, `slurmd`, `slurmctld`, `celery`, `rabbitmq`, `redis`, `flower` and `tusd` are supported.\n\n```sh\ndocker run -d -p 8080:80 -p 9002:9002 \\\n    -e \"NONUSE=cron,proftp,reports,nodejs,condor,slurmd,slurmctld,celery,rabbitmq,redis,flower,tusd\" \\\n    quay.io/bgruening/galaxy\n```\n\nA graphical user interface, to start and stop your services, is available on port `9002` if you run your container like above.\n\n\n## Restarting Galaxy \u003ca name=\"Restarting-Galaxy\" /\u003e [[toc]](#toc)\n\nIf you want to restart Galaxy without restarting the entire Galaxy container you can use `docker exec` (docker \u003e 1.3).\n\n```sh\ndocker exec \u003ccontainer name\u003e galaxyctl restart\n```\n\nIn addition, you can start/stop every supervisord process using a web interface on port `9002`. Start your container with:\n\n```sh\ndocker run -p 9002:9002 quay.io/bgruening/galaxy\n```\n\n\n## Advanced Logging \u003ca name=\"Advanced-Logging\" /\u003e [[toc]](#toc)\n\nYou can set the environment variable $GALAXY_LOGGING to FULL to access all logs from supervisor. For example start your container with:\n\n```sh\ndocker run -d -p 8080:80 -p 8021:21 \\\n    -e \"GALAXY_LOGGING=full\" \\\n    quay.io/bgruening/galaxy\n```\n\nThen, you can access the supervisord web interface on port `9002` and get access to log files. To do so, start your container with:\n\n```sh\ndocker run -d -p 8080:80 -p 8021:21 -p 9002:9002 \\\n    -e \"GALAXY_LOGGING=full\" \\\n    quay.io/bgruening/galaxy\n```\n\nAlternatively, you can access the container directly using the following command:\n\n```sh\ndocker exec -it \u003ccontainer name\u003e bash\n```\n\nOnce connected to the container, log files are available in `/home/galaxy/logs`.\n\nA volume can also be used to map this directory to one external to the container - for instance if logs need to be persisted for auditing reasons (security, debugging, performance testing, etc...).:\n\n```sh\nmkdir gx_logs\ndocker run -d -p 8080:80 -p 8021:21 -e \"GALAXY_LOGGING=full\" -v `pwd`/gx_logs:/home/galaxy/logs quay.io/bgruening/galaxy\n```\n\n## Running on an external cluster (DRM)  \u003ca name=\"Running-on-an-external-cluster-(DRM)\" /\u003e[[toc]](#toc)\n\n### Basic setup for the filesystem  \u003ca name=\"Basic-setup-for-the-filesystem\" /\u003e [[toc]](#toc)\n\n#### The easy way\nThe easiest way is to create a `/export` mount point on the cluster and mount the container with `/export:/export`.\n\n#### Not using the /export mount point on the cluster.\nThe docker container sets up all its files on the /export directory, but this directory may not exist on the cluster filesystem. This can be solved with symbolic links on the cluster filesystem but it can also be solved within the container itself.\n\nIn this example configuration the cluster file system has a directory `/cluster_storage/galaxy_data` which is accessible for the galaxy user in the container (UID 1450) and the user starting the container.\n\nThe container should be started with the following settings configured:\n```bash\ndocker run -d -p 8080:80 -p 8021:21\n-v /cluster_storage/galaxy_data/galaxy_export:/export # This makes sure all galaxy files are on the cluster filesystem\n-v /cluster_storage/galaxy_data:/cluster_storage/galaxy_data # This ensures the links within the docker container and on the cluster fs are the same\n# The following settings make sure that each job is configured with the paths on the cluster fs instead of /export\n-e GALAXY_CONFIG_TOOL_DEPENDENCY_DIR=\"/cluster_storage/galaxy_data/galaxy_export/tool_deps\"\n-e GALAXY_CONFIG_TOOL_DEPENDENCY_CACHE_DIR=\"/cluster_storage/galaxy_data/galaxy_export/tool_deps/_cache\"\n-e GALAXY_CONFIG_FILE_PATH=\"/cluster_storage/galaxy_data/galaxy_export/galaxy/database/files\"\n-e GALAXY_CONFIG_TOOL_PATH=\"/cluster_storage/galaxy_data/galaxy_export/galaxy/tools\"\n-e GALAXY_CONFIG_TOOL_DATA_PATH=\"/cluster_storage/galaxy_data/galaxy_export/galaxy/tool-data\"\n-e GALAXY_CONFIG_SHED_TOOL_DATA_PATH=\"/cluster_storage/galaxy_data/galaxy_export/galaxy/tool-data\"\n# The following settings are for directories that can be anywhere on the cluster fs.\n-e GALAXY_CONFIG_JOB_WORKING_DIRECTORY=\"/cluster_storage/galaxy_data/galaxy_export/galaxy/database/job_working_directory\" #IMPORTANT: needs to be created manually. Can also be placed elsewhere, but is originally located here\n-e GALAXY_CONFIG_NEW_FILE_PATH=\"/cluster_storage/galaxy_data/tmp\" # IMPORTANT: needs to be created manually. This needs to be writable by UID=1450 and have its flippy bit set (chmod 1777 for world-writable with flippy bit)\n-e GALAXY_CONFIG_OUTPUTS_TO_WORKING_DIRECTORY=False # Writes Job scripts, stdout and stderr to job_working_directory.\n-e GALAXY_CONFIG_RETRY_JOB_OUTPUT_COLLECTION=5 #IF your cluster fs uses nfs this may introduce latency. You can set galaxy to retry if a job output is not yet created.\n# Conda settings. IMPORTANT!\n-e GALAXY_CONFIG_CONDA_PREFIX=\"/cluster_storage/galaxy_data/_conda\" # Can be anywhere EXCEPT cluster_storage/galaxy/galaxy_export!\n# Conda uses $PWD to determine where the virtual environment is. If placed inside the export directory conda will determine $PWD to be a subirectory of the  /export folder which does not exist on the cluster!\n-e GALAXY_CONFIG_CONDA_AUTO_INIT=True # When the necessary environment can not be found a new one will automatically be created\n```\n### Setting up a Python virtual environment on the cluster  \u003ca name=\"Setting-up-a-python-virtual-environment-on-the-cluster\" /\u003e[[toc]](#toc)\nThe Python environment in the container is not accessible from the cluster. So it needs to be created beforehand.\nIn this example configuration the Python virtual environment is created on  `/cluster_storage/galaxy_data/galaxy_venv` and the export folder on `/cluster_storage/galaxy_data/galaxy_export`. To create the virtual environment:\n1. Create the virtual environment `virtualenv /cluster_storage/galaxy_data/galaxy_venv`\n2. Activate the virtual environment `source /cluster_storage/galaxy_data/galaxy_venv/bin/activate`\n3. Install the galaxy requirements `pip install --index-url https://wheels.galaxyproject.org/simple --only-binary all -r /cluster_storage/galaxy_data/galaxy/lib/galaxy/dependencies/pinned-requirements.txt`\n  * Make sure to upgrade the environment with the new requirements when a new version of galaxy is released.\n\nTo make the Python environment usable on the cluster, create your custom `job_conf.xml` file and put it in `/cluster_storage/galaxy_data/galaxy_export/galaxy/config`.\nIn the destination section the following code should be added:\n```xml\n\u003cdestinations default=\"cluster\"\u003e\n  \u003cdestination id=\"cluster\" runner=\"your_cluster_runner\"\u003e\n    \u003cenv file=\"/cluster_storage/galaxy_data/galaxy_venv/bin/activate\"/\u003e\n    \u003cenv id=\"GALAXY_ROOT_DIR\"\u003e/cluster_storage/galaxy_data/galaxy_export/galaxy\u003c/env\u003e\n    \u003cenv id=\"GALAXY_LIB\"\u003e/cluster_storage/galaxy_data/galaxy_export/galaxy/lib\u003c/env\u003e\n    \u003cenv id=\"PYTHONPATH\"\u003e/cluster_storage/galaxy_data/galaxy_export/galaxy/lib\u003c/env\u003e\n    \u003cparam id=\"embed_metadata_in_job\"\u003eTrue\u003c/param\u003e\n  \u003c/destination\u003e\n```\nIn this way, Python tools on the cluster are able to use the Galaxy libraries.\n\nMore information can be found [here](https://github.com/galaxyproject/galaxy/blob/dev/doc/source/admin/framework_dependencies.rst#managing-dependencies-manually)\nand\n[here](https://github.com/galaxyproject/galaxy/blob/dev/doc/source/admin/framework_dependencies.rst#galaxy-job-handlers).\n\n### Using an external Slurm cluster \u003ca name=\"Using-an-external-Slurm-cluster\" /\u003e [[toc]](#toc)\n\nIt is often convenient to configure Galaxy to use a high-performance cluster for running jobs. To do so, two files are required:\n\n1. munge.key\n2. slurm.conf\n\nThese files from the cluster must be copied to the `/export` mount point (i.e., `/cluster_storage/galaxy_data/galaxy_export/` on the host if using below command) accessible to Galaxy before starting the container. This must be done regardless of which Slurm daemons are running within Docker. At start, symbolic links will be created to these files to `/etc` within the container, allowing the various Slurm functions to communicate properly with your cluster. In such cases, there's no reason to run `slurmctld`, the Slurm controller daemon, from within Docker, so specify `-e \"NONUSE=slurmctld\"`. Unless you would like to also use Slurm (rather than the local job runner) to run jobs within the Docker container, then alternatively specify `-e \"NONUSE=slurmctld,slurmd\"`.\n\nImportantly, Slurm relies on a shared filesystem between the Docker container and the execution nodes. To allow things to function correctly, checkout the basic filesystem setup above.\n\nA brief note is in order regarding the version of Slurm installed. This Docker image uses Ubuntu 14.04 as its base image. The version of Slurm in the Ubuntu 14.04 repository is 2.6.5 and that is what is installed in this image. If your cluster is using an incompatible version of Slurm then you will likely need to modify this Docker image.\n\nThe following is an example for how to specify a destination in `job_conf.xml` that uses a custom partition (\"work\", rather than \"debug\") and 4 cores rather than 1:\n\n```\n\u003cdestination id=\"slurm4threads\" runner=\"slurm\"\u003e\n    \u003cparam id=\"embed_metadata_in_job\"\u003eFalse\u003c/param\u003e\n    \u003cparam id=\"nativeSpecification\"\u003e-p work -n 4\u003c/param\u003e\n\u003c/destination\u003e\n```\n\nThe usage of `-n` can be confusing. Note that it will specify the number of cores, not the number of tasks (i.e., it's not equivalent to `srun -n 4`).\n\n### Using an external Grid Engine cluster \u003ca name=\"Using-an-external-Grid-Engine-cluster\"/\u003e [[toc]](#toc)\n\nSet up the filesystem on the cluster as mentioned above.\nTo use Grid Engine (Sun Grid Engine, Open Grid Scheduler), one configuration file and an environment variable are required:\n\n\n1. create an `act_qmaster` file in the /export folder.\n  * In ***act_qmaster*** is something like this.\n\n  ```\n  YOUR_GRIDENGINE_MASTER_HOST\n  ```\n  * this file will automatically be installed in the container's `/var/lib/gridengine` folder.\n2. set the environment variable `SGE_ROOT`\n  * By default\n  ```\n  -e SGE_ROOT=/var/lib/gridengine\n  ```\n3. Make sure that YOUR_GRIDENGINE_MASTER_HOST can be pinged from the docker container. If this is not the case you can put the qmaster's hostname and ip in the containers `/etc/hosts`\nYour Grid Engine needs to accept job submissions from inside the container. If your container is already on a host that can submit jobs, set the hostname of the container to be exactly the same as the host. (The hostname can be changed by using the --hostname flag when starting the container).\n\n\n Alternatively, you can add the container's hostname (default=galaxy-docker) to the /etc/hosts file on the gridengine head node. And setting the container's hostname as a submit host.\n\n\n### Tips for Running Jobs Outside the Container \u003ca name=\"Tips-for-Running-Jobs-Outside-the-Container\"/\u003e [[toc]](#toc)\n\nIn its default state Galaxy assumes both the Galaxy source code and\nvarious temporary files are available on shared file systems across the\ncluster. When using Condor or SLURM (as described above) to run jobs outside\nof the Docker container one can take steps to mitigate these assumptions.\n\nThe `embed_metadata_in_job` option on job destinations in `job_conf.xml`\nforces Galaxy collect metadata inside the container instead of on the\ncluster:\n\n```\n\u003cparam id=\"embed_metadata_in_job\"\u003eFalse\u003c/param\u003e\n```\n\nThis has performance implications and may not scale as well as performing\nthese calculations on the remote cluster - but this should not be a problem\nfor most Galaxy instances.\n\n# Enable Galaxy to use BioContainers (Docker) \u003ca name=\"auto-exec-tools-in-docker\"/\u003e [[toc]](#toc)\nThis is a very cool feature where Galaxy automatically detects that your tool has an associated docker image, pulls it and runs it for you. These images (when available) have been generated using [mulled](https://docs.galaxyproject.org/en/latest/admin/special_topics/mulled_containers.html).\nTo test, install the [IUC bedtools](https://toolshed.g2.bx.psu.edu/repository?repository_id=8d84903cc667dbe7\u0026changeset_revision=7b3aaff0d78c) from the toolshed. When you try to execute *ClusterBed* for example. You may get a missing dependancy error for *bedtools*. But bedtools has an associated docker image on [quay.io](https://quay.io/).  Now configure Galaxy as follows:\n\n- Add this environment variable to `docker run`: `-e GALAXY_CONFIG_ENABLE_MULLED_CONTAINERS=True`\n- In `job_conf.xml` configure a Docker enabled destination as follows:\n\n```xml\n\u003cdestination id=\"docker_local\" runner=\"local\"\u003e\n    \u003cparam id=\"docker_enabled\"\u003etrue\u003c/param\u003e\n    \u003cparam id=\"docker_volumes\"\u003e$galaxy_root:ro,$galaxy_root/database/tmp:rw,$tool_directory:ro,$job_directory:ro,$working_directory:rw,$default_file_path:rw\u003c/param\u003e\n    \u003cparam id=\"docker_sudo\"\u003efalse\u003c/param\u003e\n\u003c/destination\u003e\n```\n\nWhen you execute the tool again, Galaxy will pull the image from Biocontainers ([quay.io/biocontainers](https://quay.io/organization/biocontainers)), run the tool inside of this container to produce the desired output.\n\n# Magic Environment variables \u003ca name=\"Magic-Environment-variables\"/\u003e [[toc]](#toc)\n\n| Name   | Description   |\n|---|---|\n| `ENABLE_TTS_INSTALL`  | Enables the Test Tool Shed during container startup. This change is not persistent. (`ENABLE_TTS_INSTALL=True`)  |\n| `GALAXY_LOGGING` | Enables for verbose logging at Docker stdout. (`GALAXY_LOGGING=full`)  |\n| `BARE` | Disables all default Galaxy tools. (`BARE=True`)  |\n| `NONUSE` |  Disable services during container startup. (`NONUSE=cron,proftp,reports,nodejs,condor,slurmd,slurmctld,celery,rabbitmq,redis,flower,tusd`) |\n| `GUNICORN_WORKERS` | Set the number of gunicorn workers (`GUNICORN_WORKERS=2`) |\n| `CELERY_WORKERS` | Set the number of celery workers (`CELERY_WORKERS=2`) |\n| `GALAXY_DOCKER_ENABLED` | Enable Galaxy to use Docker containers if annotated in tools (`GALAXY_DOCKER_ENABLED=False`) |\n| `GALAXY_DOCKER_VOLUMES` | Specify volumes that should be mounted into tool containers (`GALAXY_DOCKER_VOLUMES=\"\"`) |\n| `GALAXY_HANDLER_NUMPROCS` | Set the number of Galaxy handler (`GALAXY_HANDLER_NUMPROCS=2`) |\n| `LOAD_GALAXY_CONDITIONAL_DEPENDENCIES` | Installing optional dependencies into the Galaxy virtual environment |\n| `LOAD_PYTHON_DEV_DEPENDENCIES` | Installation of Galaxy's dev dependencies. Needs `LOAD_GALAXY_CONDITIONAL_DEPENDENCIES` as well |\n| `GALAXY_AUTO_UPDATE_DB` | Run the Galaxy database migration script during startup |\n\n\n# HTTPS Support \u003ca name=\"HTTPS-Support\"/\u003e [[toc]](#toc)\n\nIt's possible to automatically configure your container with HTTPS, either with\ncertificates of your own or by automatically requesting an HTTPS certificate from\nLetsencrypt with the following environment variables:\n\n| Name   | Description   |\n|---|---|\n| `USE_HTTPS` | Set `USE_HTTPS=True` to set up HTTPS via self-signed certificates (CN is set to the value of `GALAXY_DOMAIN` variable, defaulting to `localhost` if no value is provided). If you have your own certificates, copy them to `/export/{server.key,server.crt}`. |\n| `USE_HTTPS_LETSENCRYPT` | Set `USE_HTTPS_LETSENCRYPT=True` to automatically set up HTTPS using Letsencrypt as a certificate authority. (Requires you to also set `GALAXY_DOMAIN`) Note: only set one of `USE_HTTPS` and `USE_HTTPS_LETSENCRYPT` to true. |\n| `GALAXY_DOMAIN` | Set `GALAXY_DOMAIN=\u003cyour_domain\u003e` so that Letsencrypt can test your that you own the domain you claim to own in order to issue you your HTTPS cert. |\n\n\n# Lite Mode \u003ca name=\"Lite-Mode\" /\u003e [[toc]](#toc)\n\nThe lite mode will only start postgresql and a single Galaxy process, without nginx, gunicorn or any other special feature from the normal mode. In particular there is no support for the export folder or any Magic Environment variables.\n\n```sh\ndocker run -i -t -p 8080:8080 quay.io/bgruening/galaxy startup_lite\n```\n\nThis will also use the standard `job_conf.xml.sample_basic` shipped by Galaxy. If you want to use the regular one from the normal mode you can pass `-j` to the `startup_lite` script.\n\n\n# Extending the Docker Image \u003ca name=\"Extending-the-Docker-Image\" /\u003e [[toc]](#toc)\n\nIf the desired tools are already included in the Tool Shed, building your own personalised Galaxy docker Image (Galaxy flavour) can be done using the following steps:\n\n1. Create a file named `Dockerfile`\n2. Include `FROM quay.io/bgruening/galaxy` at the top of the file. This means that you use the Galaxy Docker Image as base Image and build your own extensions on top of it.\n3. Supply the list of desired tools in a file (`my_tool_list.yml` below). See [this page](https://github.com/galaxyproject/ansible-galaxy-tools/blob/master/files/tool_list.yaml.sample) for the file format requirements.\n4. Execute `docker build -t my-docker-test .`\n4a. (if behind proxy). Add the ENV http_proxy and https_proxy variables as IPs (to avoid nameserver resolution problems) as in the example below.\n5. Run your container with `docker run -p 8080:80 my-docker-test`\n6. Open your web browser on `http://localhost:8080`\n\nFor a working example, have a look at these  Dockerfiles.\n- [deepTools](http://deeptools.github.io/) [Dockerfile](https://github.com/bgruening/docker-recipes/blob/master/galaxy-deeptools/Dockerfile)\n- [ChemicalToolBox](https://github.com/bgruening/galaxytools/tree/master/chemicaltoolbox) [Dockerfile](https://github.com/bgruening/docker-recipes/blob/master/galaxy-chemicaltoolbox/Dockerfile)\n\n```\n# Galaxy - deepTools\n#\n# VERSION       0.2\n\nFROM quay.io/bgruening/galaxy\n\nMAINTAINER Björn A. Grüning, bjoern.gruening@gmail.com\n\nENV GALAXY_CONFIG_BRAND deepTools\n# The following two lines are optional and can be given during runtime\n# with the -e http_proxy='http://yourproxyIP:8080' parameter\nENV http_proxy 'http://yourproxyIP:8080'\nENV https_proxy 'http://yourproxyIP:8080'\n\nWORKDIR /galaxy\n\nRUN add-tool-shed --url 'http://testtoolshed.g2.bx.psu.edu/' --name 'Test Tool Shed'\n\n# Install Visualisation\nRUN install-biojs msa\n\n# Adding the tool definitions to the container\nADD my_tool_list.yml $GALAXY_ROOT_DIR/my_tool_list.yml\n\n# Install deepTools\nRUN install-tools $GALAXY_ROOT_DIR/my_tool_list.yml\n\n# Mark folders as imported from the host.\nVOLUME [\"/export/\", \"/data/\", \"/var/lib/docker\"]\n\n# Expose port 80 (webserver), 21 (FTP server)\nEXPOSE :80\nEXPOSE :21\n\n# Autostart script that is invoked during container start\nCMD [\"/usr/bin/startup\"]\n```\n\nor the [RNA-workbench](https://github.com/bgruening/galaxy-rna-workbench/blob/master/Dockerfile).\nThe RNA-workbench has advanced examples about:\n\n- populating Galaxy data libraries\n\n  ```bash\n    setup-data-libraries -i $GALAXY_ROOT_DIR/library_data.yaml -g http://localhost:8080\n        -u $GALAXY_DEFAULT_ADMIN_USER -p $GALAXY_DEFAULT_ADMIN_PASSWORD\n  ```\n\nThe actual data is references in a YAML file similar this [one](https://github.com/bgruening/galaxy-rna-workbench/blob/master/library_data.yaml).\n\n- installing workflows\n\n  ```bash\n      workflow-install --workflow_path $GALAXY_HOME/workflows/ -g http://localhost:8080\n          -u $GALAXY_DEFAULT_ADMIN_USER -p $GALAXY_DEFAULT_ADMIN_PASSWORD\n  ```\n\nWhere all Galaxy workflows needs to be in one directory, here the `$GALAXY_HOME/workflows/`.\n\n- running Galaxy data-managers to create indices or download data\n\n  ```bash\n      run-data-managers -u $GALAXY_DEFAULT_ADMIN_USER -p $GALAXY_DEFAULT_ADMIN_PASSWORD -g http://localhost:8080\n          --config data_manager_rna_seq.yaml\n  ```\n\nThe data-managers can be configured and specified in a YAML file similar to this [one](https://github.com/galaxyproject/training-material/blob/master/RNA-Seq/docker/data_manager_rna_seq.yaml).\n\n\nIf you host your flavor on GitHub consider to test our build with Travis-CI. This project will help you:\nhttps://github.com/bgruening/galaxy-flavor-testing\n\n\n\n## List of Galaxy flavours \u003ca name=\"List-of-Galaxy-flavours\" /\u003e [[toc]](#toc)\n\n- [Aurora Galaxy](https://github.com/statonlab/aurora-galaxy-tools)\n- [SNP analysis Workflows on Docker (sniplay)](https://github.com/ValentinMarcon/docker-galaxy-sniplay)\n- [NCBI-Blast](https://github.com/bgruening/docker-galaxy-blast)\n- [ChemicalToolBox](https://github.com/bgruening/docker-recipes/blob/master/galaxy-chemicaltoolbox)\n- [ballaxy](https://github.com/anhi/docker-scripts/tree/master/ballaxy)\n- [NGS-deepTools](https://github.com/bgruening/docker-recipes/blob/master/galaxy-deeptools)\n- [Galaxy ChIP-exo](https://github.com/gregvonkuster/docker-galaxy-ChIP-exo)\n- [Galaxy Proteomics](https://github.com/bgruening/docker-galaxyp)\n- [Imaging](https://github.com/bgruening/docker-galaxy-imaging)\n- [Constructive Solid Geometry](https://github.com/gregvonkuster/docker-galaxy-csg)\n- [Galaxy for metagenomics](https://github.com/bgruening/galaxy-metagenomics)\n- [Galaxy with the Language Application Grid tools](https://github.com/lappsgrid-incubator/docker-galaxy-lappsgrid)\n- [RNAcommender](https://github.com/gianlucacorrado/galaxy-RNAcommender)\n- [OpenMoleculeGenerator](https://github.com/bgruening/galaxy-open-molecule-generator)\n- [Workflow4Metabolomics](https://github.com/workflow4metabolomics/w4m-docker)\n- [HiC-Explorer](https://github.com/maxplanck-ie/docker-galaxy-hicexplorer)\n- [SNVPhyl](https://github.com/phac-nml/snvphyl-galaxy)\n- [GraphClust](https://github.com/BackofenLab/docker-galaxy-graphclust)\n- [RNA workbench](https://github.com/bgruening/galaxy-rna-workbench)\n- [Cancer Genomics Toolkit](https://github.com/morinlab/tools-morinlab/tree/master/docker)\n- [Clustered Heatmaps for Interactive Exploration of Molecular Profiling Data](http://cancerres.aacrjournals.org/content/77/21/e23)\n\n# Integrating non-Tool Shed tools into the container \u003ca name=\"Integrating-non-Tool-Shed-tools-into-the-container\" /\u003e [[toc]](#toc)\n\nWe recommend to use the [Main Galaxy Tool Shed](https://toolshed.g2.bx.psu.edu/) for all your tools and workflows that you would like to share.\nIn rare situations where you cannot share your tools but still want to include them into your Galaxy Docker instance, please follow the next steps.\n\n- Get your tools into the container.\n\n    Mount your tool directory into the container with a separate `-v /home/user/my_galaxy_tools/:/local_tools`.\n\n- Create a `tool_conf.xml` file for your tools.\n\n    This should look similar to the main [`tool_conf.xml`](https://github.com/galaxyproject/galaxy/blob/dev/lib/galaxy/config/sample/tool_conf.xml.sample) file, but references your tools from the new directory. In other words a tool entry should look like this `\u003ctool file=\"/local_tools/application_foo/foo.xml\" /\u003e`.\n    Your `tool_conf.xml` should be available from inside of the container. We assume you have it stored under `/local_tools/my_tools.xml`.\n\n- Add the new tool config file to the Galaxy configuration.\n\n    To make Galaxy aware of your new tool configuration file you need to add the path to `tool_config_file`, which is set to `/etc/galaxy/tool_conf.xml`. You can do this during container start by setting the environment variable `-e GALAXY_CONFIG_TOOL_CONFIG_FILE=/etc/galaxy/tool_conf.xml,/local_tools/my_tools.xml`.\n\n\n# Users \u0026 Passwords \u003ca name=\"Users-Passwords\" /\u003e [[toc]](#toc)\n\nThe Galaxy Admin User has the username `admin@example.org` and the password `password`.\nThe PostgreSQL username is `galaxy`, the password is `galaxy` and the database name is `galaxy` (I know I was really creative ;)).\nIf you want to create new users, please make sure to use the `/export/` volume. Otherwise your user will be removed after your docker session is finished.\n\nThe proftpd server is configured to use the main galaxy PostgreSQL user to access the database and select the username and password. If you want to run the\ndocker container in production, please do not forget to change the user credentials in `/etc/proftpd/proftpd.conf` too.\n\nThe Galaxy Report and Flower Webapps are `htpasswd` protected with username and password set to `admin`.\n\nRabbitMQ is configured with:\n  - Admin username: `admin`\n  - Admin password: `admin`\n  - Galaxy vhost: `galaxy`\n  - Galaxy username: `galaxy`\n  - Galaxy password: `galaxy`\n  - Flower username: `flower`\n  - Flower password: `flower`\n\n\n# Development \u003ca name=\"Development\" /\u003e [[toc]](#toc)\n\nYou can clone this repository with:\n\n```sh\ngit clone https://github.com/bgruening/docker-galaxy-stable.git\n```\n\nThis repository uses various [Ansible](http://www.ansible.com/) roles as specified in [requirements.yml](galaxy/ansible/requirements.yml) to manage configurations and dependencies. You can install these roles with the following command:\n\n```sh\ncd galaxy/ansible/ \u0026\u0026 ansible-galaxy install -r requirements.yml -p roles\n```\n\nIf you simply want to change the Galaxy repository and/or the Galaxy branch, from which the container is build you can do this with Docker `--build-arg` during the `docker build` step. For example you can use these parameters during container build:\n\n```\n --build-arg GALAXY_RELEASE=install_workflow_and_tools\n --build-arg GALAXY_REPO=https://github.com/manabuishii/galaxy\n```\n\nTo keep docker images lean and optimize storage, we recommend using [Dive](https://github.com/wagoodman/dive). It provides an interactive UI that lets you explore each layer of the image, helping you quickly identify files and directories that take up significant space. To install Dive, follow the installation instructions provided in the [Dive GitHub repository](https://github.com/wagoodman/dive?tab=readme-ov-file#installation). After building your docker image, use Dive to analyze it:\n\n```bash\ndive \u003cyour-docker-image-name\u003e\n```\n\n# Requirements \u003ca name=\"Requirements\" /\u003e [[toc]](#toc)\n\n- [Docker](https://www.docker.io/gettingstarted/#h_installation)\n\n\n# Support \u0026 Bug Reports \u003ca name=\"Support-Bug-Reports\" /\u003e [[toc]](#toc)\n\nYou can file an [github issue](https://github.com/bgruening/docker-galaxy-stable/issues) or ask\nus on the [Galaxy development list](http://lists.bx.psu.edu/listinfo/galaxy-dev).\n\nIf you like this service please fill out this survey: https://www.surveymonkey.de/r/denbi-service?sc=rbc\u0026tool=galaxy-docker\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbgruening%2Fdocker-galaxy","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbgruening%2Fdocker-galaxy","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbgruening%2Fdocker-galaxy/lists"}