Chapter 5. Advanced configuration options

The following section describes advanced deployment and configuration methods for Red Hat CodeReady Workspaces.

5.1. CodeReady Workspaces configMaps and their behavior

The following section describes CodeReady Workspaces configMaps and how they behave.

A configMap is provided as an editable file that lists options to customize the CodeReady Workspaces environment. Based on the CodeReady Workspaces installation method, configMaps can be used to customize the working environment. The type of configMaps available in your CodeReady Workspaces environment varies based on the method used for installing CodeReady Workspaces.

5.1.1. CodeReady Workspaces installed using an Operator

Operators are software extensions to OpenShift that use custom resources to manage applications and their components.

CodeReady Workspaces installed using the Operator provides the user with an automatically generated configMap called workspaces.

The workspaces configMap contains the main properties for the CodeReady Workspaces server, and is in sync with the information stored in the CheCluster Custom Resource file. User modifications of the workspaces configMap after installing CodeReady Workspaces using the Operator are automatically overwritten by values that the Operator obtains from the CheCluster Custom Resource.

To edit the workspaces configMap, edit the Custom Resource manually. The configMap derives values from the CheCluster field. User modifications of the CheCluster Custom Resource field cause the Operator to change the attributes of the workspaces configMap accordingly. The configMap changes automatically trigger a restart of the CodeReady Workspaces Pod.

To add custom properties to the CodeReady Workspaces server, such as environment variables that are not automatically generated in the workspaces configMap by the Operator, or to override automatically generated properties, the CheCluster Custom Resource has a customCheProperties field, which expects a map.

For example, to overrride the default memory limit for workspaces, add the CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB property to customCheProperties: 

apiVersion: org.eclipse.che/v1
kind: CheCluster
metadata:
  name: eclipse-che
  namespace: che
spec:
  server:
    cheImageTag: ''
    devfileRegistryImage: ''
    pluginRegistryImage: ''
    tlsSupport: false
    selfSignedCert: false
    customCheProperties:
      CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB: "2048"
  auth:
...

Previous versions of the CodeReady Workspaces Operator had a configMap named custom to fulfill this role. If the CodeReady Workspaces Operator finds a configMap with the name custom, it adds the data it contains into the customCheProperties field, redeploys CodeReady Workspaces, and deletes the custom configMap.

5.2. Configuring namespace strategies

Note

The term namespace (Kubernetes) is used interchangeably with project (OpenShift).

The namespace strategies are configured using the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT environment variable.

Warning

There are legacy variables CHE_INFRA_KUBERNETES_NAMESPACE and CHE_INFRA_OPENSHIFT_PROJECT. These should be left unset for new instalations. Changing these variables during update can lead to data loss.

5.2.1. One namespace per workspace strategy

The strategy creates a new namespace for each new workspace.

To use the strategy, the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT variable value must contain the <workspaceid> identifier. It can be used alone or combined with other identifiers or any string.

Example 5.1. One namespace per workspace

To assign namespace names composed of a che-ws prefix and workspace id, set: 

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=che-ws-<workspaceid>

5.2.2. One namespace for all workspaces strategy

The strategy uses one predefined namespace for all workspaces.

To use the strategy, the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT variable value must be the name of the desired namespace to use.

Example 5.2. One namespace for all workspaces

To have all workspaces created in che-workspaces namespace, set: 

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=che-workspaces
Important

To run more than one workspace at a time when using this strategy together with the common PVC strategy, configure persistent volumes to use ReadWriteMany access mode.

5.2.3. One namespace per user strategy

The strategy isolates each user in their own namespace.

To use the strategy, the CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT variable value must contain one or more user identifiers. Currently supported identifiers are <username> and <userid>.

Example 5.3. One namespace per user

To assign namespace names composed of a che-ws prefix and individual usernames (che-ws-user1, che-ws-user2), set: 

CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT=che-ws-<username>
Important

To run more than one workspace at a time when using this strategy together with the common PVC strategy, configure persistent volumes to use ReadWriteMany access mode.

To limit the number of concurrently running workspaces per user to one, set the CHE_LIMITS_USER_WORKSPACES_RUN_COUNT environment variable to 1.

To limit the number of concurrently running workspaces per user to one (1):

  • For Helm Chart deployments: set the .global.workspace.number parameter to 1.
  • For Operator deployments: set the spec.server.cheCustomProperties.CHE_LIMITS_USER_WORKSPACE_RUN_COUNT variable of the CheCluster Custom Resource (CR) to 1.

5.2.4. Allowing user-defined workspace namespaces

Che server can be configured to honor the user selection of a namespace when a workspace is created. This feature is disabled by default. To allow user-defined workspace namespaces, set: 

CHE_INFRA_KUBERNETES_NAMESPACE_ALLOWUSERDEFINED=true

5.3. Deploying CodeReady Workspaces with support for Git repositories with self-signed certificates

This procedure describes how to configure CodeReady Workspaces for deployment with support for Git operations on repositories that use self-signed certificates.

Prerequisites

  • Git version 2 or later.

Configuring support for self-signed Git repositories on OpenShift

Deploying CodeReady Workspaces using a Helm Chart

  1. Configure the workspace exposure strategy using the global.useGitSelfSignedCerts property. To do that, add the following option to the helm upgrade command: 

    $ helm upgrade che --set global.useGitSelfSignedCerts=true

  2. Create a new configMap with details about the Git server: 

    $ oc create configmap che-git-self-signed-cert --from-file=<ca.crt> \
  --from-literal=githost=<host:port> -n=che

    In the command, substitute <ca.crt> for the self-signed certificate and `<host:port>` for the host and port of the HTTPS connection on the Git server (optional).

    Note

    When githost is not specified, the given certificate is used for all HTTPS repositories.

Create and start new workspace. Every container used by the workspace mounts a special volume that contains a file with the self-signed certificate. The repository’s .git/config file contains information about the Git server host (its URL) and the path to the certificate in the http section (see Git documentation about git-config). For example: 

[http "https://10.33.177.118:3000"]
        sslCAInfo = /etc/che/git/cert/ca.crt

5.4. CodeReady Workspaces configMaps fields reference

5.4.5. k8s configuration settings specific to CodeReady Workspaces installations on OpenShift

PropertyDefault valueDescription

ingressClass

nginx

Ingress class that defines which controller manages ingresses.

ingressDomain

omit

Global ingress domain for a K8S cluster. This field must be explicitly specified. This drives the is kubernetes.io/ingress.class annotation on CodeReady Workspaces-related ingresses.

ingressStrategy

multi-host

Strategy for ingress creation. This can be multi-host (host is explicitly provided in ingress), single-host (host is provided, path-based rules) and default-host.*(no host is provided, path-based rules).

securityContextFsGroup,omitempty

1724

FSGroup the CodeReady Workspaces Pod and Workspace Pods containers should run in.

securityContextRunAsUser

1724

ID of the user the CodeReady Workspaces Pod and Workspace Pods containers should run as.

tlsSecretName

omit

Name of a secret that is used to set ingress TLS termination if TLS is enabled. See also the tlsSupport field.

5.4.6. installation defines the observed state of CodeReady Workspaces installation

PropertyDescription

cheClusterRunning

Status of a CodeReady Workspaces installation. Can be Available, Unavailable, or Available, Rolling Update in Progress.

cheURL

Public URL to the CodeReady Workspaces server.

cheVersion

Currently installed CodeReady Workspaces version.

dbProvisioned

Indicates whether a Postgres instance has been correctly provisioned.

devfileRegistryURL

Public URL to the Devfile registry.

helpLink

A URL to where to find help related to the current Operator status.

keycloakProvisioned

Indicates whether an Identity Provider instance (Keycloak / RH SSO) has been provisioned with realm, client and user.

keycloakURL

Public URL to the Identity Provider server (Keycloak / RH SSO).

message

A human-readable message with details about why the Pod is in this state.

openShiftoAuthProvisioned

Indicates whether an Identity Provider instance (Keycloak / RH SSO) has been configured to integrate with the OpenShift OAuth.

pluginRegistryURL

Public URL to the Plugin registry.

reason

A brief CamelCase message with details about why the Pod is in this state.

5.4.7. Limits for workspaces

PropertyDefault valueDescription

che.limits.workspace.env.ram

16gb

The maximum amount of RAM that a user can allocate to a workspace when they create a new workspace. The RAM slider is adjusted to this maximum value.

che.limits.workspace.idle.timeout

1800000

The length of time that a user is idle with their workspace when the system will suspend the workspace and then stopping it. Idleness is the length of time that the user has not interacted with the workspace, meaning that one of our agents has not received interaction. Leaving a browser window open counts toward idleness.

5.4.8. Limits for the workspaces of an user

PropertyDefault valueDescription

che.limits.user.workspaces.ram

16gb

he total amount of RAM that a single user is allowed to allocate to running workspaces. A user can allocate this RAM to a single workspace or spread it across multiple workspaces.

che.limits.user.workspaces.count

1800000

The maximum number of workspaces that a user is allowed to create. The user will be presented with an error message if they try to create additional workspaces. This applies to the total number of both running and stopped workspaces.

che.limits.user.workspaces.run.count

1

The maximum number of running workspaces that a single user is allowed to have. If the user has reached this threshold and they try to start an additional workspace, they will be prompted with an error message. The user will need to stop a running workspace to activate another.

5.4.9. Limits for for the workspaces of an organization

PropertyDefault valueDescription

che.limits.organization.workspaces.ram

-1

The total amount of RAM that a single organization (team) is allowed to allocate to running workspaces. An organization owner can allocate this RAM however they see fit across the team’s workspaces.

che.limits.organization.workspaces.count

-1

The maximum number of workspaces that a organization is allowed to own. The organization will be presented an error message if they try to create additional workspaces. This applies to the total number of both running and stopped workspaces.

che.limits.organization.workspaces.run.count

-1

The maximum number of running workspaces that a single organization is allowed. If the organization has reached this threshold and they try to start an additional workspace, they will be prompted with an error message. The organization will need to stop a running workspace to activate another.