Understanding Che workspaces architecture

Che workspaces architecture

A Che deployment on the cluster consists of the Che server component, a database for storing user profile and preferences, and a number of additional deployments hosting workspaces. The Che server orchestrates the creation of workspaces, which consist of a deployment containing the workspace containers and enabled plug-ins, plus related components, such as:

  • ConfigMaps

  • services

  • endpoints

  • ingresses/routes

  • secrets

  • PVs

The Che workspace is a web application. It is composed of microservices running in containers that provide all the services of a modern IDE such as an editor, language auto-completion, and debugging tools. The IDE services are deployed with the development tools, packaged in containers and user runtime applications, which are defined as Kubernetes resources.

The source code of the projects of a Che workspace is persisted in a Kubernetes or OpenShift PersistentVolume. Microservices run in containers that have read-write access to the source code (IDE services, development tools), and runtime applications have read-write access to this shared directory.

The following diagram shows the detailed components of a Che workspace.

che workspaces
Figure 1. Che workspace components

In the diagram, there are three running workspaces: two belonging to User A and one to User C. A fourth workspace is getting provisioned where the plug-in broker is verifying and completing the workspace configuration.

Use the devfile format to specify the tools and runtime applications of a Che workspace.

Che workspace components

This section describes the components of a Che workspace.

Che Plugin plug-ins

Che Plugin plug-ins are special services that extend Che workspace capabilities. Che Plugin plug-ins are packaged as containers. Packaging plug-ins into a container has the following benefits:

  • It isolates the plug-ins from the main IDE, therefore limiting the resources that a plug-in has access to.

  • It uses the consolidated standard of container registries to publish and distribute plug-ins (as with any container image).

The containers that plug-ins are packaged into run as sidecars of the Che workspace editor and augment its capabilities.

Visual Studio Code extensions packaged in containers are Che plug-ins for the Che-Theia editor.

Multiple Che plug-ins can run in the same container (for better resource use), or a Che Plugin can run in its dedicated container (for better isolation).

Che Editor plug-in

A Che Editor plug-in is a Che workspace plug-in. It defines the web application that is used as an editor in a workspace. The default Che workspace editor is Che-Theia. It is a web-based source-code editor similar to Visual Studio Code (VS Code). It has a plug-in system that supports VS Code extensions.

Source code

Che-Theia

Container image

eclipse/che-theia

Endpoints

theia, webviews, theia-dev, theia-redirect-1, theia-redirect-2, theia-redirect-3
Additional resources

Che user runtimes

Use any non-terminating user container as a user runtime. An application that can be defined as a container image or as a set of Kubernetes or OpenShift resources can be included in a Che workspace. This makes it easy to test applications in the Che workspace.

To test an application in the Che workspace, include the application YAML definition used in stage or production in the workspace specification. It is a 12-factor app dev/prod parity.

Examples of user runtimes are Node.js, SpringBoot or MongoDB, and MySQL.

Che workspace JWT proxy

The JWT proxy is responsible for securing the communication of the Che workspace services. The Che workspace JWT proxy is included in a Che workspace only if the Che server is configured in multi-user mode.

An HTTP proxy is used to sign outgoing requests from a workspace service to the Che server and to authenticate incoming requests from the IDE client running on a browser.

Source code

JWT proxy

Container image

eclipse/che-jwtproxy

Che plug-ins broker

Plug-in brokers are special services that, given a plug-in meta.yaml file:

  • Gather all the information to provide a plug-in definition that the Che server knows.

  • Perform preparation actions in the workspace namespace (download, unpack files, process configuration).

The main goal of the plug-in broker is to decouple the Che plug-ins definitions from the actual plug-ins that Che can support. With brokers, Che can support different plug-ins without updating the Che server.

The Che server starts the plug-in broker. The plug-in broker runs in the same Kubernetes namespace or OpenShift project as the workspace. It has access to the plug-ins and project persistent volumes.

A plug-ins broker is defined as a container image (for example, eclipse/che-plugin-broker). The plug-in type determines the type of the broker that is started. Two types of plug-ins are supported: Che Plugin and Che Editor.

Source code

Che Plug-in broker

Container image

quay.io/eclipse/che-plugin-artifacts-broker
eclipse/che-plugin-metadata-broker

Che workspace creation flow

che workspace creation flow

The following is a Che workspace creation flow:

  1. A user starts a Che workspace defined by:

    • An editor (the default is Che-Theia)

    • A list of plug-ins (for example, Java and Kubernetes or OpenShift tools)

    • A list of runtime applications

  2. Che server retrieves the editor and plug-in metadata from the plug-in registry.

  3. For every plug-in type, Che server starts a specific plug-in broker.

  4. The Che plug-ins broker transforms the plug-in metadata into a Che Plugin definition. It executes the following steps:

    1. Downloads a plug-in and extracts its content.

    2. Processes the plug-in meta.yaml file and sends it back to Che server in the format of a Che Plugin.

  5. Che server starts the editor and the plug-in sidecars.

  6. The editor loads the plug-ins from the plug-in persistent volume.