Interactive web terminal support in helm chart
Description
The officially supported GitLab Helm chart does not support setting up interactive web terminals. It's possible 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
We will add support to the Helm chart for getting this working out of the box. Likely this will require updates to the helm charts 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, but it will be on by default.
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 #3713 (comment 125855357)
- The default configuration to set up the session server, 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 - 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 theconfig.toml
file from step 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 #3713 (comment 125855357) - Update the runner
config.toml
specifically thesession_server
table withadvertise_address
with the value of the ip:port of the service created in step 3. This is needed becausegitlab-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 #3713 (comment 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 theconfig.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 #3713