 Hello, my name is Alexandre Mahmoud from the Galaxy team at Johns Hopkins University, and today I will be talking about the new way of deploying Galaxy interactive tools with the Kubernetes runner. For those who might be unfamiliar, Galaxy interactive tools, or ITs for short, are tools wrapped for Galaxy like any other but meant to have a UI exposed during runtime with which the user is meant to interact for their analysis. ITs have been around for many months. They are the modern evolution of interactive environments. However, their current best practice deployment method requires a reverse proxy. The Galaxy HelmChart is a package for deploying a scalable, production-grade Galaxy on Kubernetes. A major focus of this effort has been to enable interactive tools by default for the HelmChart and subsequently all the stacks using it. In order to achieve that, the implementation was done in Galaxy's backend, specifically in the Kubernetes runner, which is the current default runner for Galaxy on Kubernetes. By deploying an ingress and service resource alongside each job, ITs can be exposed without the need for a reverse proxy, a feature that is now available as of Galaxy 2105. Finally, Cloudman Boot is an Ansible Playbook that bootstaps the Genomics Virtual Lab or GVL stack on virtual machines. In this context, the Playbook can be particularly useful for going from a set of IPs representing nodes to a Kubernetes cluster with all the prerequisites that are on Galaxy alongside interactive tools. In particular, for the Kubernetes runner to deploy ITs in a cluster, the minimal requirement is an ingress controller. Managed clusters generally come with a built-in ingress controller, and any cluster running a web app needs one to consume the Kubernetes ingress resource. In our case, we use the Nginx controller, but the IT's implementation is controller agnostic in principle. Additionally, in order to get valid certificates for HTTPS connections, we use CertManager, the recommended operator for managing certificates in Kubernetes. In line with the previously recommended method using the reverse proxy, a single certificate can be issued for a wildcard subdomain with certain credentials. But the new implementation also supports shortened subdomains allowing CertManager to issue individual Let's Encrypt certificates per IT without any setup from the administrator. Now for a quick demo, I'm going to deploy a Jupyter Notebook interactive tool on a Kubernetes development Galaxy server. The interactive tools section can be found in the tool panel, and ITs have the classic Galaxy form just like any other tool. When run, this tool will however have a link for its exposed UI. One thing to note is that the implementation is not yet smart enough to wait for the certificates to be properly issued and validated before exposing the ingress. Therefore, if you haven't waited enough time, you might still be hit with the insecure connection warning. In this case, you should just wait a bit longer for the certificate handshake to happen after which you will be able to access and use your interactive tools UI with a secure connection. This should only take a minute or two. As you just saw in the demonstration, the user experience and user interface surrounding ITs has not changed, even when using the Kubernetes implementation. This was purposeful to keep this method as a new deployment mechanism on the back end but stay in sync with future IT work in Galaxy. So while the user still sees the same interface, things are quite different in the back. When an IT is launched, the Kubernetes runner deploys a corresponding Kubernetes job resource just like is the case for any job. Additionally, however, a Kubernetes service resource is also created to expose this job when it's an IT. This resource selects the job pod based on the unique job ID annotation rather than specific pod name, making the connection less error prone, for example in the case of a transient error where the job pod might need to be redeployed. Moreover, this method opens the potential door for high availability ITs where multiple pods could be launched for a single tool run and given proper readiness checks, the selector would be able to route requests to the better replica at that time. Finally, an ingress resource is also created. The ingress exposes the service's selected pods at the desired path and defines certificate requests in the manifest's annotations, subsequently consumed by a cert manager. With these three resources, the interactive tool is running in the pod and that pod is now exposed to the user with a secure connection. Now to delve into the how do I set this up for myself question, the configuration is rather simple and only requires changes in two files. Notably, in galaxy.yml, a few interactive tool configurations are present. These are documented in the galaxy configuration docs and will have sensible defaults inheriting from other values in the galaxy home chart. Moreover, in the jobconf.yml file under the Kubernetes runner section, one can specify whether or not to use a secure connection and what annotations to add to the ingress for that connection. Similarly to the other configurations, sensible default values have been added to the galaxy home chart, inheriting from the annotations specified for galaxy's main ingress. And that should be all. In short, with the galaxy home chart, no changes should be needed to run galaxy ITs on Kubernetes and in general, with the reverse proxy eliminated, the configuration is minimal as existing Kubernetes features can be used to expose interactive tools when running galaxy on Kubernetes. However, this implementation is not without its limitations. Unaudible limitation, on which we are currently focusing, relates to file permissions when interactive tool containers expect arbitrary users or expect to run as root. As such, while this feature is already available on 2105, it is likely not ready for wide production use quite yet without vetting individual interactive tools first. Thank you for listening and feel free to find me on Remo, Gitter or email me for any questions or for help setting this up for yourself.