Menu Close

Chapter 1. Preparing the installation

To prepare a OpenShift Dev Spaces installation, learn about OpenShift Dev Spaces ecosystem and deployment constraints:

1.1. Supported platforms

OpenShift Dev Spaces 3.0 is available on listed platforms with the listed supported installation methods:

Table 1.1. Supported deployment environments for OpenShift Dev Spaces 3.0

PlatformArchitecturesDeployment method

OpenShift Container Platform 4.10

  • AMD64 and Intel 64 (x86_64)
  • IBM Power (ppc64le)
  • IBM Z (s390x)

OpenShift Dedicated 4.10

  • AMD64 and Intel 64 (x86_64)

Red Hat OpenShift Service on AWS (ROSA) 4.10

  • AMD64 and Intel 64 (x86_64)

1.2. OpenShift Dev Spaces architecture

Figure 1.1. High-level OpenShift Dev Spaces architecture with the DevWorkspace operator

che interacting with devworkspace

OpenShift Dev Spaces runs on three groups of components:

OpenShift Dev Spaces server components
Manage User project and workspaces. The main component is the User dashboard, from which users control their workspaces.
DevWorkspace operator
Creates and controls the necessary OpenShift objects to run User workspaces. Including Pods, Services, and PeristentVolumes.
User workspaces
Container-based development environments, the IDE included.

The role of these OpenShift features is central:

DevWorkspace Custom Resources
Valid OpenShift objects representing the User workspaces and manipulated by OpenShift Dev Spaces. It is the communication channel for the three groups of components.
OpenShift role-based access control (RBAC)
Controls access to all resources.

1.2.1. OpenShift Dev Spaces server components

The OpenShift Dev Spaces server components ensure multi-tenancy and workspaces management.

Figure 1.2. OpenShift Dev Spaces server components interacting with the DevWorkspace operator

devspaces deployments interacting with devworkspace

1.2.1.1. OpenShift Dev Spaces operator

The OpenShift Dev Spaces operator ensure full lifecycle management of the OpenShift Dev Spaces server components. It introduces:

CheCluster custom resource definition (CRD)
Defines the CheCluster OpenShift object.
OpenShift Dev Spaces controller
Creates and controls the necessary OpenShift objects to run a OpenShift Dev Spaces instance, such as pods, services, and persistent volumes.
CheCluster custom resource (CR)

On a cluster with the OpenShift Dev Spaces operator, it is possible to create a CheCluster custom resource (CR). The OpenShift Dev Spaces operator ensures the full lifecycle management of the OpenShift Dev Spaces server components on this OpenShift Dev Spaces instance:

1.2.1.2. DevWorkspace operator

The DevWorkspace operator extends OpenShift to provide DevWorkspace support. It introduces:

DevWorkspace custom resource definition
Defines the DevWorkspace OpenShift object from the Devfile v2 specification.
DevWorkspace controller
Creates and controls the necessary OpenShift objects to run a DevWorkspace, such as pods, services, and persistent volumes.
DevWorkspace custom resource
On a cluster with the DevWorkspace operator, it is possible to create DevWorkspace custom resources (CR). A DevWorkspace CR is a OpenShift representation of a Devfile. It defines a User workspaces in a OpenShift cluster.

Additional resources

1.2.1.3. Gateway

The OpenShift Dev Spaces gateway has following roles:

  • Routing requests. It uses Traefik.
  • Authenticating users with OpenID Connect (OIDC). It uses OpenShift OAuth2 proxy.
  • Applying OpenShift Role based access control (RBAC) policies to control access to any OpenShift Dev Spaces resource. It uses `kube-rbac-proxy`.

The OpenShift Dev Spaces operator manages it as the che-gateway Deployment.

It controls access to:

Figure 1.3. OpenShift Dev Spaces gateway interactions with other components

OpenShift Dev Spaces gateway interactions with other components

1.2.1.4. User dashboard

The user dashboard is the landing page of Red Hat OpenShift Dev Spaces. OpenShift Dev Spaces users browse the user dashboard to access and manage their workspaces. It is a React application. The OpenShift Dev Spaces deployment starts it in the devspaces-dashboard Deployment.

It need access to:

Figure 1.4. User dashboard interactions with other components

User dashboard interactions with other components

When the user requests the user dashboard to start a workspace, the user dashboard executes this sequence of actions:

  1. Collects the devfile from the Section 1.2.1.5, “Devfile registries”, when the user is creating a workspace from a code sample.
  2. Sends the repository URL to Section 1.2.1.6, “OpenShift Dev Spaces server” and expects a devfile in return, when the user is creating a workspace from a remote devfile.
  3. Reads the devfile describing the workspace.
  4. Collects the additional metadata from the Section 1.2.1.8, “Plug-in registry”.
  5. Converts the information into a DevWorkspace Custom Resource.
  6. Creates the DevWorkspace Custom Resource in the user project using the OpenShift API.
  7. Watches the DevWorkspace Custom Resource status.
  8. Redirects the user to the running workspace IDE.

1.2.1.5. Devfile registries

Additional resources

The OpenShift Dev Spaces devfile registries are services providing a list of sample devfiles to create ready-to-use workspaces. The Section 1.2.1.4, “User dashboard” displays the samples list on the DashboardCreate Workspace page. Each sample includes a Devfile v2. The OpenShift Dev Spaces deployment starts one devfile registry instance in the devfile-registry deployment.

Figure 1.5. Devfile registries interactions with other components

devspaces devfile registry interactions

1.2.1.6. OpenShift Dev Spaces server

The OpenShift Dev Spaces server main functions are:

  • Creating user namespaces.
  • Provisioning user namespaces with required secrets and config maps.
  • Integrating with Git services providers, to fetch and validate devfiles and authentication.

The OpenShift Dev Spaces server is a Java web service exposing an HTTP REST API and needs access to:

Figure 1.6. OpenShift Dev Spaces server interactions with other components

OpenShift Dev Spaces server interactions with other components

1.2.1.7. PostgreSQL

OpenShift Dev Spaces server uses the PostgreSQL database to persist user configurations such as workspaces metadata.

The OpenShift Dev Spaces deployment starts a dedicated PostgreSQL instance in the postgres Deployment. You can use an external database instead.

Figure 1.7. PostgreSQL interactions with other components

PostgreSQL interactions with other components

1.2.1.8. Plug-in registry

Each OpenShift Dev Spaces workspace starts with a specific editor and set of associated extensions. The OpenShift Dev Spaces plug-in registry provides the list of available editors and editor extensions. A Devfile v2 describes each editor or extension.

The Section 1.2.1.4, “User dashboard” is reading the content of the registry.

Figure 1.8. Plug-in registries interactions with other components

Plug-in registries interactions with other components

1.2.2. User workspaces

Figure 1.9. User workspaces interactions with other components

User workspaces interactions with other components

User workspaces are web IDEs running in containers.

A User workspace is a web application. It consists of microservices running in containers providing all the services of a modern IDE running in your browser:

  • Editor
  • Language auto-completion
  • Language server
  • Debugging tools
  • Plug-ins
  • Application runtimes

A workspace is one OpenShift Deployment containing the workspace containers and enabled plug-ins, plus related OpenShift components:

  • Containers
  • ConfigMaps
  • Services
  • Endpoints
  • Ingresses or Routes
  • Secrets
  • Persistent Volumes (PVs)

A OpenShift Dev Spaces workspace contains the source code of the projects, persisted in a OpenShift Persistent Volume (PV). Microservices have read-write access to this shared directory.

Use the devfile v2 format to specify the tools and runtime applications of a OpenShift Dev Spaces workspace.

The following diagram shows one running OpenShift Dev Spaces workspace and its components.

Figure 1.10. OpenShift Dev Spaces workspace components

workspace components with dw

In the diagram, there is one running workspaces.

1.3. Calculating OpenShift Dev Spaces resource requirements

The OpenShift Dev Spaces Operator, DevWorkspace Controller, and user workspaces consist of a set of pods. The pods contribute to the resource consumption in terms of CPU and RAM limits and requests. Learn how to calculate resources, such as memory and CPU, required to run Red Hat OpenShift Dev Spaces.

1.3.1. OpenShift Dev Spaces Operator requirements

The OpenShift Dev Spaces Operator manages six operands running in six distinct pods. The following table presents the default resource requirements of each of these operands.

Table 1.2. OpenShift Dev Spaces operator operands

PodContainer namesDefault memory limitDefault memory request

OpenShift Dev Spaces Server

OpenShift Dev Spaces

1 Gi

512 MiB

OpenShift Dev Spaces Gateway

gateway, configbump, oauth-proxy, kube-rbac-proxy

4 Gi, 256Mi, 512Mi, 512Mi

128 Mi, 64Mi, 64Mi, 64Mi

OpenShift Dev Spaces Dashboard

OpenShift Dev Spaces-dashboard

256 Mi

32 Mi

PostgreSQL

postgres

1 Gi

512 Mi

Devfile registry

che-devfile-registry

256 Mi

32 Mi

Plug-in registry

che-plugin-registry

256 Mi

32 Mi

The OpenShift Dev Spaces Operator, which powers all the operands, consists of a single container with the 64Mi memory request and 256Mi limit. These default values are sufficient when the OpenShift Dev Spaces Operator manages a relatively big amount of OpenShift Dev Spaces workspaces. For even larger deployments, consider increasing the defaults.

1.3.2. DevWorkspace Operator requirements

The DevWorkspace Operator consists of 3 pods. The following table presents the default resource requirements of each of these pods.

Table 1.3. DevWorkspace Operator Pods

PodContainer nameDefault memory limitDefault memory request

DevWorkspace Controller Manager

DevWorkspace-controller, kube-rbac-proxy

1 Gi

100 Mi

DevWorkspace Operator Catalog

registry-server

N/A

50 Mi

DevWorkspace Webhook Server

webhook-server}, kube-rbac-proxy

300 Mi

20 Mi

These default values are sufficient when the DevWorkspace Controller manages a relatively big amount of OpenShift Dev Spaces workspaces. For larger deployments, consider increasing the defaults.

1.3.3. Workspaces requirements

This section describes how to calculate the resources required for a workspace. That is the sum of the resources required for each container of the workspace.

Procedure

  1. Identify the workspace components explicitly specified in the components section of the devfile.
  2. Identify the implicit workspace components.
Note

OpenShift Dev Spaces implicitly loads the default theia-ide, che-machine-exec, che-gateway containers.

  1. Calculate the requirements for each component.

1.3.4. A workspace example

This section describes a OpenShift Dev Spaces workspace example.

The following devfile defines the OpenShift Dev Spaces workspace:

apiVersion: 1.0.0
metadata:
  generateName: nodejs-configmap-
projects:
  - name: nodejs-configmap
    source:
      location: "https://github.com/crw-samples/nodejs-configmap.git"
      branch: 12.x
      type: git
components:
  - id: vscode/typescript-language-features/latest
    type: chePlugin
  - mountSources: true
    type: kubernetes
    entrypoints:
      - command:
          - sleep
        args:
          - infinity
    reference: 'https://raw.githubusercontent.com/crw-samples/nodejs-mongodb-sample/master/kubernetes-manifests/guestbook-app.deployment.yaml'
    alias: guestbook-frontend

This table provides the memory requirements for each workspace component:

Table 1.4. Total workspace memory requirement and limit

PodContainer nameDefault memory limitDefault memory request

Workspace

theia-ide

512 Mi

64 Mi

Workspace

machine-exec

128 Mi

32 Mi

Workspace

tools

4 Gi

64 Mi

Workspace

che-gateway

256 Mi

64 Mi

Total

4.9 Gi

224 Mi