## Release notes You can now enable an interactive web terminal via the GitLab Runner Helm chart to debug pipeline jobs on a Kubernetes cluster. ## Overview The officially supported GitLab Helm chart does not support setting up interactive web terminals. It's [possible](https://gitlab.com/gitlab-org/gitlab-runner/issues/3713#note_125855357) to get it working, but requires the user to modify the helm chart which then prevents automatic updates to the newest version as they are released. ## Proposal Add support to the GitLab Runer Helm chart for supporting interactive web terminals by default. Likely this will require updates to the [helm charts](https://gitlab.com/charts/gitlab-runner) in order to make it work since services and container ports need to be created. We will allow for the feature to be turned off in the [values.yml](https://gitlab.com/charts/gitlab-runner/blob/master/values.yaml), but it will be on by default. ### First Iteration Objective On release of this first iteration, a user will be able to enable the web interactive terminal through gitlab-runner helm chart. The implementation will focus on supporting only `LoadBalancer Service` for a deployment with `only one replica`. The support for the other service types (such as `ClusterIP`, `NodePort`, `ExternalName`) and for more than one replica will be added in future iterations. This means when the web interactive terminal feature is enabled: * Permissions to `create and get` services will be added to the service account * A `LoadBalancer Service` will be created * The use of an `init-container` is made to retrieve the `ExternalIP` of the service created ### Implementation #### Updates to GitLab Runner Helm chart There are few updated that needs to be made for the helm chart to support web terminals which are explained below and are taken from https://gitlab.com/gitlab-org/gitlab-runner/issues/3713#note_125855357 1. The [default configuration](https://gitlab.com/charts/gitlab-runner/blob/master/templates/configmap.yaml#L49) to set up the [session server](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-session_server-section), the port for the `session_server.listen_address` will need to be taken note of since it will need to be exposed later in step 2 1. The runner container needs to expose a new port for the session server. The session server is what serves the information for the web terminal so the gitlab instance needs to communicate to the gitlab runner. The port that it needs to expose is the one defined in `session_server.listen_address` from the `config.toml` file from step 1 1. Register a new service a `LoadBalancer` type might be the best option that exposes that port from step 2 to the external service. A good example of that service can be found in step 2 of https://gitlab.com/gitlab-org/gitlab-runner/issues/3713#note_125855357 1. Update the runner `config.toml` specifically the `session_server` table with `advertise_address` with the value of the ip:port of the service created in step 3. This is needed because `gitlab-runner` will tell GitLab.com or the self-hosted gitlab instance that to start the terminal it needs to through the following service. As pointed out by @WarheadsSE in https://gitlab.com/gitlab-org/gitlab-runner/issues/3713#note_125908832 this might be a bit tricky since we would need to first wait for the service to be created and then get the information and then update the `config.toml` #### Proxy API Option Technically, for `Helm Chart` we don't have to expose the `listen_addr` with load balancer, but rather use internal Kubernetes Proxy API for proxying if needed. This could be an alternative way, and much simpler to install and configure. We do that in Rails already for accessing Prometheus Metrics running on given Pod, so we could effectively do the same here. It will simplify at least installation on Rails side when we would like to use it. Maybe we could generate `listen_addr` automatically when starting gitlab runner to make it a fully valid address that would allow proxying. Kubernetes does inject ENV variables that should allow runner to properly configure `listen_addr` automatically. ## Links to related issues and merge requests/references - Originally mentioned in https://gitlab.com/gitlab-org/gitlab-runner/issues/3713 <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->