Eclipse Che Gets a New Dev Environments Engine
After more than a year of work, and a preview release in Eclipse Che v7.28, the new workspace engine, the DevWorkspace Operator, became generally available in Eclipse Che v7.42.
Here’s a brief summary of the motivations behind the change and what it means for current and new Eclipse Che users.
Improved Provisioning of Kubernetes Resources
At the very core of Eclipse Che, a RESTful Java web service named che-server was used to provision development workspaces on Kubernetes: Pods, Services, and other Kubernetes resources that included a web-based IDE. Starting with Eclipse Che v7.42, the che-server no longer provisions those Kubernetes resources. It has been replaced by the DevWorkspace Operator (Figure 1).
Figure 1: Previous and New Eclipse Che Workspace Architectures
This represents a major architectural update with several benefits. Here are just a few of them:
A High Availability Key-Value Store
Because it was not previously possible to have more than one instance of the che-server running at the same time, a rolling update strategy was not an option. Every update caused a few seconds of non-availability.
The DevWorkspace Operator is a Kubernetes controller. As such, it runs behind the kube-apiserver that is designed to scale horizontally. And the data is persisted in a key-value store (etcd) that is designed to be highly available.
A Universal API
Eclipse Che workspaces are now Kubernetes objects. This means:
- Kubernetes clients such as kubectl, or the Kubernetes Dashboard, can manage Eclipse Che workspaces.
- Workspaces are secured using role-based access control (RBAC).
- Workspaces can be validated and protected by admission webhooks.
- The devfile specification is automatically generated from the API.
A Simpler Design
The new workspace engine has a single responsibility: to manage workspace resources. It's decoupled from developers’ IDEs and from Eclipse Che server-side components. Communications between components happen asynchronously using Kubernetes ConfigMaps and Secrets objects, rather than a REST API.
Fixes for Reported Issues
The new workspace engine was written from scratch, which gave us the opportunity to address some of the main issues previously reported by our users. The DevWorkspace Operator features:
- Simpler configuration for the administrator
- No hard dependency on Keycloak
- A simpler network model and Transport Layer Security (TLS) certificates management with one unique gateway
Changes for Administrators and Users
The switch to the DevWorkspace Operator introduces changes for existing Eclipse Che users and administrators.
If you’re an Eclipse Che administrator:
- Users’ workspaces can now be managed using kubectl or through the Kubernetes Dashboard.
- Eclipse Che no longer installs or requires Keycloak, but it does require an OpenID Connect (OIDC) provider that’s configured to authenticate Kubernetes users.
- Deploying Eclipse Che is simpler because there are fewer configuration options. For example, the namespace strategy and exposure strategy are set to "per-user" and "single-host" respectively as we’ve noticed that’s what users want anyways.
- There’s a new server-side component: a Traefik-based gateway that handles users' connections to IDEs.
- The operator installation mode is “all namespaces.”
If you’re an Eclipse Che user:
- The Devfile v2 specification is now supported, including new sections for parents and events. Version 1 Devfiles continue to be supported.
- Devfiles don’t include references to the editor and its plug-in. These components are now specified in separate files: .che/che-editor.yaml, .che/che-theia-extensions.yaml, and .vscode/extensions.json.
- Visual Studio Code is now supported as a workspace IDE, in addition to Eclipse Theia and JetBrains IDEs.
- Workspace startup is faster with fewer containers per workspace.
Get Eclipse Che With the DevWorkspace Operator
Eclipse Che v7.42 and higher include the DevWorkspace Operator and require Kubernetes v1.19 or higher. You can install the software from the OperatorHub or by using the chectl tool from the command line interface.
Note that if you’re using an Eclipse Che version prior to 7.42, you won’t be automatically upgraded, so you’ll need to do that yourself. See the links below for instructions.
For more insight into Eclipse Che and the DevWorkspace Operator, check out the following resources:
- Eclipse Che website
- Administrator guide to upgrade Eclipse Che 7.41 to 7.42
- Users guide to migrate a v1 Devfiles to v2
About the Author
Mario Loriedo is a software engineer and architect at Red Hat. He works on container-based developer tools to accelerate software development. He is the technical lead of the open source project Eclipse Che and has been a speaker at conferences such as KubeCon, LinuxCon, JavaOne, and FOSDEM.
More from this Edition
Langium is a new toolkit for textual languages that are built on the TypeScript programming language.
Eclipse JKube is the successor to the deprecated Fabric8 Maven plug-in, and the latest version, 1.8.0, is now available. Marc Nuri explains why now is the time to upgrade.