The Che workspace is a web application. It is composed of microservices running in containers that provide all the services of a modern IDE (an editor, language auto-completion, debugging tooling). The IDE services are deployed with the development tooling, 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 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.
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 plug-ins
Che plug-ins are special services that extend Che workspace capabilities. Che 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, thus 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 plug-in can run in its dedicated container (for better isolation).
Che editor plug-in
A Che editor 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 called Eclipse Che-Theia.
The Eclipse Che-Theia source-code repository is at Che Theia Github. It is based on the Eclipse Theia open-source project.
Che-Theia is written in TypeScript and is built on the Microsoft Monaco editor. 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 |
|
Container image |
|
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 |
|
Container image |
|
Che plug-in broker
Plug-in brokers are special services that, given a plug-in meta.yaml file:
-
Gather all the information to provide a Che 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-in definition 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 as the workspace. It has access to the plug-ins and project persistent volumes.
A plug-in 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 plug-in and Che editor.
Source code |
|
Container image |
|
Che workspace configuration
This section describes the properties of the Che server that affect the provisioning of a Che workspace.
Persistent volume configuration
A Kubernetes persistent volume is attached to the Che workspace to persist its data: source code, application logs, and tools configuration. A Che server can be configured to use different strategies:
-
common: A Che workspace that is provisioned in the same Kubernetes namespace and shares the same
PersistentVolume. The data of different workspaces are separated using subpaths. The default strategy is common. -
unique: Every Che workspace is attached to a distinct persistent volume. This strategy provides better data isolation but requires more resources.
Workspace namespaces configuration
The Kubernetes namespace where a new workspace pod is deployed depends on the Che server configuration. By default, every workspace is deployed in a distinct namespace, but the user can configure the Che server to deploy all workspaces in one specific namespace. The name of a namespace must be provided as a Che server configuration property and cannot be changed at runtime.
Che workspace creation flow
The following is a Che workspace creation flow:
-
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 tooling)
-
A list of runtime applications
-
-
wsmaster retrieves the editor and plug-in metadata from the plug-in registry.
-
For every plug-in type, wsmaster starts a specific plug-in broker.
-
The Che plug-in broker transforms the plug-in metadata into a Che plug-in definition. It executes the following steps:
-
Downloads a plug-in and extracts its content.
-
Processes the plug-in
meta.yamlfile and sends it back to wsmaster in the format of a Che plug-in.
-
-
wsmaster starts the editor and the plug-in sidecars.
-
The editor loads the plug-ins from the plug-in persistent volume.