High Level Architecture
Workspaces are defined with Devfiles, YAML files versioned in the git repository close to the application source code.
Eclipse Che Dashboard is a web application that transforms a Devfile provided by an authenticated user into a Kubernetes Custom Resource (the DevWorkspace).
The DevWorkspace Operator extends the Kubernetes API to support DevWorkspaces objects, a Custom Resource specialized for development environment provisioning.
A Workspace is composed of Pods, Services, Ingresses, Volumes and other Kubernetes objects. All together those objects empower developers to code, build and deploy using a web based IDE.
A Closer Look: Che Dashboard
The Dashboard is Che frontend application to manage DevWorkspaces. It lets authenticated users create, list, stop or delete DevWorkspaces. The input parameter for a DevWorkspace creation is an URL to a git repo or to a `Devfile.yaml`.
The Che dashboard uses other server-side components: the Che server, that is both a gateway to external git services and a Kubernetes namespaces provisioner and the Devfile Registry that returns a list of sample DevWorkspaces.
A Closer Look: DevWorkspace Operator
Universal API
- Che Workspaces are Kubernetes object:
- Managed with any Kubernetes client such as kubectl
- Secured by Role-Based Access Control (RBAC)
- Can be validated and protected by Admission Webhooks
- The Devfile specification is automatically generated from the API
Highly Available
The new engine is a Kubernetes controller. As such it runs behind the kube-apiserver that is designed to scale horizontally. The data is persisted in a key value store designed to be highly available (etcd).
Simple Design
The new workspace engine has a single responsibility that is to manage workspace resources. It's decoupled from the developers IDEs and from the server side components of Che. Communications between components happens asynchronously using ConfigMaps and Secrets rather than a REST API.
Workspace components
The Kubernetes objects that power a development environment, IDE included
Init Containers
Init containers are used to perform pre-start actions such as cloning a git repository, downloading the IDE or pre-downloading IDE extensions.
Developer defined containers
These are the containers that are specified in the Devfile. The entrypoint of these containers must be non-terminating. The IDE and its extensions are usually run as standalone binaries in one of these containers although they can run in its own container too.
Persistent Volumes
Containers are ephemeral: when a workspace is stopped changes to its files are wiped out unless they belonged to a PV. By default code is cloned in a PV. Persistent Volumes can be specified in Devfiles or can be labeled and annotated to be automatically mounted.
Secrets and ConfigMaps
Kubernetes Secrets and ConfigMap can be automatically mounted in containers with user credentials and configurations. The DevWorkspace operator selects which ones based on their labels.