This page provides a comprehensive overview of Server Runtime and catalogs relevant links and pages. It is created and maintained by @shekharpatnaik. The Server Runtime SEG Single-Engineer Group is a part of Incubation Engineering Department.
Server Runtime is aimed at engineering a performant, scalable remote development experience & productizing it as a customer offering. When this comes to fruition, we envision being able to bring to bear a remote development experience that is browser and platform agnostic and lets GitLab users build, run and test their code right within the GitLab platform. We see this as a viable product idea to generate revenue for the company & to transform the IDE experience for engineers. Competitors in this space, currently, are GitPod and Codespaces.
Generally, cloud based development environments have the following traits:
This SEG aims at engineering the server runtime in a manner that addresses each of the enlisted traits to build a performant, scalable, configurable experience for users. This SEG was established in response to the following issue.
The Server Runtime architecture has evolved iteratively. The initial approach at inception made use of a custom server runtime (control plane); the control plane handled server runtime environment deployments and lifecycle events in a variety of target platforms, including Kubernetes and cloud virtual machines (VMs)
The functionality offered by the initial version of the control plane is summarized for reference & posterity here:
You can review the architecture that enabled this functionality here
The Server Runtime architecture has gone through several iterations since, and as it stands currently, the notable change in approach is to develop the Server Runtime based on the GitLab Agent for Kubernetes.
GitLab Agent for Kubernetes (GA4K) provides an extensible module based architecture for building services that can communicate with both GitLab (rails) as well as a k8s cluster. The agent can be installed on any k8s cluster; and it communicates with rails over a bi-directional gRPC tunnel. Using the GitLab agent enables the deployment of developer workspaces to all customers clusters that have the GitLab agent installed.
The architecture makes extensive use of Devfiles which is an open source standard to express the definition of developer environments.
The most recent weekly update for the Server Runtime SEG can be found at:
| Date | Tl;DR; | Video |
|---|---|---|
| 2022-12-23 | GitLab Agent - Making changes to workspace state from the UI and k8s | https://youtu.be/nCIusZfxufo |
| 2022-12-16 | GitLab Agent - A demo of using Python and Jupyter with SR4GA4K | https://youtu.be/lQK_3xTb55U |
| 2022-12-12 | GitLab Agent - Rails UI, Authentication, Repository cloning | https://youtu.be/jxHFOeg9gAw |
| 2022-11-29 | GitLab Agent - Started porting server runtime. Support for HTTPS | https://youtu.be/-E8wJZsYnbM |
| 2022-11-16 | Custom Control Plane - Adding Rails UI and connecting to the GDK | https://youtu.be/wyZbbrCBk6A |
| 2022-11-02 | Custom Control Plane - Adding Devfile support, support for SSH authn and authz | https://youtu.be/f_jfwh4v_q0 |
| 2022-10-26 | Custom Control Plane - Documentation updates, support for GCP DNS, IDE selection | https://youtu.be/JIGNEqpdI7k |
| 2022-10-19 | Custom Control Plane - Adding Authentication, opening ports, attaching volumes | https://youtu.be/GFM0xK7Hz_I |
| 2022-10-12 | What is server runtime. Starting work on the custom control plane. | https://youtu.be/yrhJo_wUuIM |
Server runtime comprises of GitLab and customer managed components. GitLab manages the server side component called KAS and an agent, called Agentk runs on the customers' cluster/s. The Server Runtime is deployed as a module, on both, the server and the client side. AgentK makes outbound connections to KAS from the customer's k8s cluster to fetch updates. It actuates k8s resources pertinent to the runtime, such as deployment, services et cetera based on these updates. Customer hosting GitLab instances will be responsible for managing KAS while for managed GitLab.com accounts this will be managed by GitLab. GitLab can talk to KAS using a gRPC API which is accessed using the kas-gem.
A core part of the server runtime is provisioning a new workspace and managing workspace lifecycle events. The flow can be summarized as follows:
This flow describes the process user authentication & authorization process. A sidecar proxy (oauth2-proxy) is injected into every workspace. A forked version of OAuth2-proxy performs the following tasks
Coming soon!
Server runtime is a GitLab agent module. You can clone the following branch
git clone [email protected]:gitlab-org/cluster-integration/gitlab-agent.git
git checkout spatnaik-remote_dev_server_runtime origin/spatnaik-remote_dev_server_runtime
You can then run KAS using the following command. You need GDK installed in order for this to work.
export OWN_PRIVATE_API_URL=grpc://127.0.0.1:8155
bazel run //cmd/kas -- --configuration-file="$HOME/projects/gitlab-development-kit/gitlab-k8s-agent-config.yml"
agentk can be run using the following. The token file can be obtained by registering the agent.
export POD_NAME=test
export POD_NAMESPACE=default
bazel run //cmd/agentk -- --kas-address=grpc://127.0.0.1:8150 --token-file="$(pwd)/token.txt"