.. _interactivetools:
Galaxy InteractiveTools
=======================
Galaxy Interactive Tools allows launching a container-backed Galaxy Tool
and enabling a Galaxy User to gain access to content inside in real-time.
How Galaxy InteractiveTools work
--------------------------------
A InteractiveTool is defined in the same familiar way as standard Galaxy Tools,
but are specified with ``tool_type="interactive"``, and providing additional
entry point information:
.. code-block:: xml
80
**Note** that name, port, and url are each able to be templated from the InteractiveTool's parameter dictionary.
Some important benefits of using Galaxy InteractiveTools
--------------------------------------------------------
- You can have and access **any number of InteractiveTools at a time** (admin configurable)
- If you accidentally close the **InteractiveTool browser window**, you can **regain access** by selecting from a **list of active InteractiveTools**
- A single **InteractiveTool** can **grant access** to **multiple running applications, servers, and interfaces**
- **InteractiveTools** can be **added to** Galaxy **Workflows**
- **Native, out-of-the box support for InteractiveTools** in Galaxy via uWSGI proxying
- **InteractiveTools** are **bonafide Galaxy Tools**; just specify **tool_type as "interactive"** and list the ports you want to expose
- **InteractiveTools** can be **added** to and **installed from the ToolShed**.
- **R Shiny apps**, **Javascript-based VNC** access to desktop environments, **genome-browsers-in-a-box**, **interactive notebook environments**, etc, are all possible with **InteractiveTools**
Server-side configuration of Galaxy InteractiveTools
----------------------------------------------------
For production deployments and additional considerations please see the `Galaxy Interactive Tools Tutorial `__.
The ``galaxy.yml`` file will need to be populated as seen in
``config/galaxy.yml.interactivetools``.
Galaxy InteractiveTool routing relies on wildcard subdomain routes and a proxy server that forwards requests to a running container.
For users who manage their own DNS, you can set the appropriate A records to redirect
``*.interactivetool.yourdomain``.
`gravity` will automatically start the needed proxy server.
The following configuration is only recommended for local testing, as users will directly connect to the InteractiveTool Proxy.
In a production setup an upstream proxy should route requests to the proxy via the ``*.interactivetool.yourdomain`` subdomain.
Set these values in `galaxy.yml`:
.. code-block:: yaml
gravity:
# ...
gx_it_proxy:
enable: true
proxy_port: 4002
galaxy:
# ...
interactivetools_enable: true
interactivetools_map: database/interactivetools_map.sqlite
galaxy_infrastructure_url: http://localhost:8080
# Do not set the following 2 options if you are using an upstream proxy server like nginx
interactivetools_upstream_proxy: false
interactivetools_proxy_host: localhost:4002
# ...
If you do want to use nginx as an upstream proxy server you can use the following server section to route requests to the InteractiveTool proxy:
.. code-block:: nginx
server {
# Listen on port 443
listen *:443 ssl;
# Match all requests for the interactive tools subdomain
server_name *.interactivetool.localhost;
# Proxy all requests to the GIE Proxy application
location / {
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://localhost:4002;
}
}
Note that this nginx example uses https, so you need to have a wildcard certificate for your domain,
and you need to adjust ``galaxy_infrastructure_url`` as appropriate. You will most likely also want
to replace localhost with your server domain.
You will also need to enable a docker destination in the job_conf.xml file.
An example ``job_conf.xml`` file as seen in ``config/job_conf.xml.interactivetools``:
.. code-block:: xml
true
$galaxy_root:ro,$tool_directory:ro,$job_directory:rw,$working_directory:rw,$default_file_path:ro
false
bridge
true
true
true
--add-host localhost:host-gateway
docker_dispatch
docker_local
local
InteractiveTools have been enabled for the Condor, Slurm, Pulsar and Kuberneters job runner.
A destination configuration for Condor may look like this:
.. code-block:: xml
true
false
**Note on resource consumption:** Keep in mind that Distributed Resource
Management (DRM) / cluster systems may have a maximum runtime configured for
jobs. From the Galaxy point of view, such a container could run as long as the
user desires, this may not be advisable and an admin may want to restrict the
runtime of InteractiveTools *(and jobs in general)*. However, if the job is
killed by the DRM, the user is not informed beforehand and data in the container
could be discarded.
Some **example test InteractiveTools** have been defined, and can be added to
the ``config/tool_conf.xml``:
.. code-block:: xml