Chapter 6. Advanced configuration options

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

6.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.

6.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 codeready.

The codeready 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 codeready 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 codeready 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 codeready 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 codeready 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: true
    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.

6.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

CHE_INFRA_KUBERNETES_NAMESPACE and CHE_INFRA_OPENSHIFT_PROJECT are legacy variables. Keep these variables unset for a new installations. Changing these variables during an update can lead to data loss.

6.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 6.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>

6.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 6.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.

6.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 6.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 Operator deployments: set the spec.server.cheCustomProperties.CHE_LIMITS_USER_WORKSPACE_RUN_COUNT variable of the CheCluster Custom Resource (CR) to 1.

6.2.4. Allowing user-defined workspace namespaces

CodeReady Workspaces 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:

  • For Operator deployments, set the following field in the CheCluster Custom Resource: 

    allowUserDefinedWorkspaceNamespaces

6.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

Procedure

Configuring support for self-signed Git repositories.

  1. 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 {prod-namespace}

    In the command, substitute <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.
    • The certificate file must be named ca.crt.

  2. Configure the workspace exposure strategy:

    Update the gitSelfSignedCert property. To do that, execute: 

    $ oc patch checluster codeready-workspaces -n workspaces --type=json \
  -p '[{"op": "replace", "path": "/spec/server/gitSelfSignedCert", "value": true}]'

  3. Create and start a 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

6.4. Adding self-signed SSL certificates to CodeReady Workspaces

When a CodeReady Workspaces user attempts to authenticate with RH-SSO that is using OpenShift OAuth, the authentication fails if the RH-SSO does not know the certificates needed for authorization.

To fix this problem, configure CodeReady Workspaces to authorize HTTPS communication with various components, such as identity and Git servers, by adding information about the self-signed SSL certificates to the CodeReady Workspaces configuration.

Prerequisites

  • The OpenShift command-line tool, oc is installed.

Procedure

  1. Save the desired self-signed certificates to a local file system.

  2. Create a new configMap with the required self-signed SSL certificates: 

    $ oc create configmap <configMap-name> --from-file=<certificate-file-path> -n=<che-namespace-name>

    To apply more than one certificate, add another --from-file=<certificate-file-path> option to the above command.

  3. Define a name for the newly created configMap.

    Note

    Use these steps with existing instances of CodeReady Workspaces. To install a new instance of CodeReady Workspaces with self-signed SSL certificates, create a new Che Custom Resource or Helm Chart property, based on the installation method selected, instead of updating the existing configuration.

    • For a CodeReady Workspaces Operators deployment:

      • Define a name for the newly created configMap by editing the spec.server.ServerTrustStoreConfigMapName Che Custom Resource property to match the previously created configMap: 

        $ oc patch checluster codeready-workspaces -n che --type=json -p '[{"op": "replace", "path": "/spec/server/serverTrustStoreConfigMapName", "value": "<config-map-name>"}]'

    Verification

    If the certificates have been added correctly, the CodeReady Workspaces server starts and obtains RH-SSO configuration over HTTPS with a self-signed SSL certificate, allowing user to:

    • Access the CodeReady Workspaces server.
    • Log in using OpenShift OAuth.
    • Clone from a Git repository that has a custom self-signed SSL certificate over HTTPS.

6.5. CodeReady Workspaces configMaps fields reference

6.5.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) and default-host(no host is provided, path-based rules).

securityContextFsGroup,omitempty

1724

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

securityContextRunAsUser

1724

ID of the user the CodeReady Workspaces Pod and Workspace Pods containers will 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.

6.5.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 PostgreSQL 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.

6.5.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.

6.5.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.

6.5.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.