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
----------------------------------------------------
The ``galaxy.yml`` file will need to be populated as seen in
``config/galaxy.yml.interactivetools``.
Galaxy InteractiveTool routing relies on wildcard subdomain routes. For users
who manage their own DNS, you can set the appropriate A records to redirect
``*.interactivetool.yourdomain``, following format seen below.
It's not recommended for production, but for a quick local deployment
``localhost.blankenberglab.org`` is a domain record provided by Dan Blankenberg
(a Galaxy contributor and the architect of ITs) configured with the appropriate
wildcard redirect to 127.0.0.1, which you can use that in place of
```` to resolve to your local machine.
In the ``uwsgi:`` section:
.. code-block:: yaml
http-raw-body: true
# master: true
interactivetools_map: database/interactivetools_map.sqlite
python-raw: scripts/interactivetools/key_type_token_mapping.py
route-host: ^([A-Za-z0-9]+(?:-[A-Za-z0-9]+)*)-([A-Za-z0-9]+(?:-[A-Za-z0-9]+)*)\.([A-Za-z0-9]+(?:-[A-Za-z0-9]+)*)\.(interactivetool\.:8080)$ goto:interactivetool
route-run: goto:endendend
route-label: interactivetool
route-host: ^([A-Za-z0-9]+(?:-[A-Za-z0-9]+)*)-([A-Za-z0-9]+(?:-[A-Za-z0-9]+)*)\.([A-Za-z0-9]+(?:-[A-Za-z0-9]+)*)\.(interactivetool\.:8080)$ rpcvar:TARGET_HOST rtt_key_type_token_mapper_cached $1 $3 $2 $4 $0 5
route-if-not: empty:${TARGET_HOST} httpdumb:${TARGET_HOST}
route: .* break:404 Not Found
route-label: endendend
In the ``galaxy:`` section:
.. code-block:: yaml
interactivetools_enable: true
interactivetools_map: database/interactivetools_map.sqlite
galaxy_infrastructure_url: http://.org:8080
The admin should modify the ``route-host`` and ``interactivetools_prefix`` to match their preferred configuration.
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
docker_dispatch
docker_local
local
Alternatively to the local job runner, InteractiveTools have been enabled for the condor job runner, e.g.:
.. 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