Chapter 1. Preparing the installation

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

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:

• Section 1.2.1.4, “User dashboard”
• Section 1.2.1.5, “Devfile registries”
• Section 1.2.1.6, “OpenShift Dev Spaces server”
• Section 1.2.1.8, “Plug-in registry”
• Section 1.2.2, “User workspaces”

Figure 1.3. OpenShift Dev Spaces gateway interactions with other components

Additional resources

• Section 3.10, “Managing identities and authorizations”

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:

• Section 1.2.1.5, “Devfile registries”
• Section 1.2.1.6, “OpenShift Dev Spaces server”
• Section 1.2.1.8, “Plug-in registry”
• OpenShift API

Figure 1.4. 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 Dashboard Create 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

Additional resources

• Devfile v2 documentation
• devfile registry latest community version online instance
• OpenShift Dev Spaces devfile registry repository

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:

• Section 1.2.1.7, “PostgreSQL”
• Git service providers
• OpenShift API

Figure 1.6. OpenShift Dev Spaces server interactions with other components

Additional resources

• Section 3.3.2, “Advanced configuration options for the OpenShift Dev Spaces server component”

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

Additional resources

• quay.io/eclipse/che—​centos—​postgresql-96-centos7 container image
• quay.io/eclipse/che—​centos—​postgresql-13-centos7 container image

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

Additional resources

• Editors definitions in the OpenShift Dev Spaces plug-in registry repository
• Plug-ins definitions in the OpenShift Dev Spaces plug-in registry repository
• Plug-in registry latest community version online instance

Figure 1.9. 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:

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

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

In the diagram, there is one running workspaces.

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.

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.

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

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.

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.

This section describes a OpenShift Dev Spaces workspace example.

The following devfile defines the OpenShift Dev Spaces workspace:

schemaVersion: 2.1.0
metadata:
  name: bash
components:
  - name: tools
    container:
      image: quay.io/devfile/universal-developer-image:ubi8-0e189d9
      memoryLimit: 4Gi

commands:
  - id: run-main-script
    exec:
      label: "Run main.sh script"
      component: tools
      workingDir: '${PROJECT_SOURCE}'
      commandLine: |
        ./main.sh
      group:
        kind: run
        isDefault: true

This table provides the memory requirements for each workspace component: