GitLab Next

Description

Having terminal access to running containers is essential for debugging, and eventually for active development. Openshift has an online terminal capability, but Kubernetes doesn't (yet), so for GCE/CoreOS/etc., we need to build something ourselves. Let's offer online terminal access for environments, and especially review apps.

Proposal

Like https://github.com/openshift/origin-web-console we use the API call GET /api/v1/namespaces/{namespace}/pods/{name}/exec which is listed under 'connect GET requests to exec of Pod' on http://kubernetes.io/docs/api-reference/v1/operations/.

Not sure if we should use https://github.com/openshift/origin-web-console, xterm.js, or make our own thing in vue. Keybindings might be hard to get right. @jschatz1 will inspect the Angular app from openshift.

Because of cross-site scripting protections the terminal will have to talk to the container via GitLab. We'll use Workhorse to forward those requests.

This is for accessing (review) apps only, CI/Runner access should be discussed in a new issue. The editor is in https://gitlab.com/gitlab-org/gitlab-ce/issues/22863.

1. Support OpenShift and Kubernetes.
2. Connect to Kubernetes using direct API
3. Create project-level Service for Kubernetes to store the credentials to Kubernetes (and OpenShift).
4. Only support Bearer authentication. User/Password and Mutual authentication are left for later.
5. Use the same credentials for deployment and for terminal access.
6. [Stretch] Prefill the project service if you run GitLab on Kubernetes.
7. Enabling the Kubernetes Service for a project will turn all deployments (jobs with an environment specified) into Kubernetes deployments.
8. No changes are needed to .gitlab-ci.yml to support this.
9. Getting terminal access will require developers to adhere to specific labels. This will be documented as well as updated in the Openshift .gitlab-ci.yml template. Overriding the label will be left until later.
10. Use intelligent defaults for namespace and labels based on the project name. i.e. namespace=$CI_PROJECT_NAME, app=environment.name.
11. Extend builds with deployment information (namespace and labels).
12. Add a column to deployment and attach deployment information when creating deployment on GitLab.
13. Show Terminal button only if we have deployment properties and we have kubernetes credentials in Kubernetes Service.
14. Use https://github.com/abonas/kubeclient to find Pods filtered by namespace and app label.
15. Connect to the first pod in the list.
16. Connect to first container in Pod.
17. [Stretch] Extend the terminal view with ability to choose the Pod and service to connect to, to support cases with multiple pods and services.
18. Terminal library will open Websocket connection to GitLab.
19. Authorize the connection GitLab and return to workhorse the credentials stored in Service and a URL to connect to.
20. Terminal will be only accessible for master users of the project. (Debatable?)

Service Credentials

We would require user to add these values to the Kubernetes Service:

• api_url (KUBE_URL)
• or token (KUBE_TOKEN)
• ca_pem - if HTTPS is using self-signed certificates (KUBE_CA_PEM)

Additionally:

• These variables may be passed to the GitLab runner as environment variables.

Note: It was deemed easier to create a new Service rather than special case Secret Variables. It's also a better experience, so win-win!

Mockups

Terminal icon can be found: https://gitlab.com/gitlab-org/gitlab-design/blob/master/production/_assets/svg/icon-terminal.svg

Links

• Early MVP, only works in openshift: #22843 (closed)
• Smart Kubernetes Deployments which would automatically create a deployment with all informations: #24197 (moved)
• Easy to use credentials interface: #22958 (moved)