Administration Guide
Administering Red Hat CodeReady Workspaces 2.15
Abstract
Making open source more inclusive Copy linkLink copied to clipboard!
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Chapter 1. Architecture overview Copy linkLink copied to clipboard!
CodeReady Workspaces needs a workspace engine to manage the lifecycle of the workspaces. Two workspace engines are available. The choice of a workspace engine defines the architecture.
- Section 1.1, “CodeReady Workspaces architecture with CodeReady Workspaces server”
CodeReady Workspaces server is the default workspace engine.
Figure 1.1. High-level CodeReady Workspaces architecture with the CodeReady Workspaces server engine
- Section 1.4, “CodeReady Workspaces architecture with Dev Workspace”
The Dev Workspace Operator is a new workspace engine.
Technology preview featureManaging workspaces with the Dev Workspace engine is an experimental feature. Don’t use this workspace engine in production.
Known limitations
Workspaces are not secured. Whoever knows the URL of a workspace can have access to it and leak the user credentials.
Figure 1.2. High-level CodeReady Workspaces architecture with the Dev Workspace operator
Additional resources
- Section 1.1, “CodeReady Workspaces architecture with CodeReady Workspaces server”
- Section 1.4, “CodeReady Workspaces architecture with Dev Workspace”
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#enabling-dev-workspace-operator.adoc
- Dev Workspace Operator GitHub repository
1.1. CodeReady Workspaces architecture with CodeReady Workspaces server Copy linkLink copied to clipboard!
CodeReady Workspaces server is the default workspace engine.
Figure 1.3. High-level CodeReady Workspaces architecture with the CodeReady Workspaces server engine
Red Hat CodeReady Workspaces components are:
- CodeReady Workspaces server
- An always-running service that manages user workspaces with the OpenShift API.
- User workspaces
- Container-based IDEs running on user requests.
1.2. Understanding CodeReady Workspaces server Copy linkLink copied to clipboard!
This chapter describes the CodeReady Workspaces controller and the services that are a part of the controller.
1.2.1. CodeReady Workspaces server Copy linkLink copied to clipboard!
The workspaces controller manages the container-based development environments: CodeReady Workspaces workspaces. To secure the development environments with authentication, the deployment is always multiuser and multitenant.
The following diagram shows the different services that are a part of the CodeReady Workspaces workspaces controller.
Figure 1.4. CodeReady Workspaces workspaces controller
Additional resources
1.2.2. CodeReady Workspaces server Copy linkLink copied to clipboard!
The CodeReady Workspaces server is the central service of CodeReady Workspaces server-side components. It is a Java web service exposing an HTTP REST API to manage CodeReady Workspaces workspaces and users. It is the default workspace engine.
1.2.3. CodeReady Workspaces user dashboard Copy linkLink copied to clipboard!
The user dashboard is the landing page of Red Hat CodeReady Workspaces. It is a React application. CodeReady Workspaces users navigate the user dashboard from their browsers to create, start, and manage CodeReady Workspaces workspaces.
1.2.4. CodeReady Workspaces devfile registry Copy linkLink copied to clipboard!
The CodeReady Workspaces devfile registry is a service that provides a list of CodeReady Workspaces samples to create ready-to-use workspaces. This list of samples is used in the Dashboard → Create Workspace window. The devfile registry runs in a container and can be deployed wherever the user dashboard can connect.
1.2.5. CodeReady Workspaces plug-in registry Copy linkLink copied to clipboard!
The CodeReady Workspaces plug-in registry is a service that provides the list of plug-ins and editors for CodeReady Workspaces workspaces. A devfile only references a plug-in that is published in a CodeReady Workspaces plug-in registry. It runs in a container and can be deployed wherever CodeReady Workspaces server connects.
1.2.6. CodeReady Workspaces and PostgreSQL Copy linkLink copied to clipboard!
The PostgreSQL database is a prerequisite for CodeReady Workspaces server and RH-SSO.
The CodeReady Workspaces administrator can choose to:
- Connect CodeReady Workspaces to an existing PostgreSQL instance.
- Let the CodeReady Workspaces deployment start a new dedicated PostgreSQL instance.
Services use the database for the following purposes:
- CodeReady Workspaces server
- Persist user configurations such as workspaces metadata and Git credentials.
- RH-SSO
- Persist user information.
1.2.7. CodeReady Workspaces and RH-SSO Copy linkLink copied to clipboard!
RH-SSO is a prerequisite to configure CodeReady Workspaces. The CodeReady Workspaces administrator can choose to connect CodeReady Workspaces to an existing RH-SSO instance or let the CodeReady Workspaces deployment start a new dedicated RH-SSO instance.
The CodeReady Workspaces server uses RH-SSO as an OpenID Connect (OIDC) provider to authenticate CodeReady Workspaces users and secure access to CodeReady Workspaces resources.
Additional resources
1.3. Understanding CodeReady Workspaces workspaces architecture Copy linkLink copied to clipboard!
This chapter describes the architecture and components of CodeReady Workspaces.
1.3.1. CodeReady Workspaces workspaces architecture Copy linkLink copied to clipboard!
A CodeReady Workspaces deployment on the cluster consists of the CodeReady Workspaces server component, a database for storing user profile and preferences, and several additional deployments hosting workspaces. The CodeReady Workspaces server orchestrates the creation of workspaces, which consist of a deployment containing the workspace containers and enabled plug-ins, plus the related components, such as:
- ConfigMaps
- services
- endpoints
- ingresses or routes
- secrets
- persistent volumes (PVs)
The CodeReady Workspaces workspace is a web application. It is composed of microservices running in containers that provide all the services of a modern IDE such as an editor, language auto-completion, and debugging tools. The IDE services are deployed with the development tools, packaged in containers and user runtime applications, which are defined as OpenShift resources.
The source code of the projects of a CodeReady Workspaces workspace is persisted in a OpenShift PersistentVolume. Microservices run in containers that have read-write access to the source code (IDE services, development tools), and runtime applications have read-write access to this shared directory.
The following diagram shows the detailed components of a CodeReady Workspaces workspace.
Figure 1.5. CodeReady Workspaces workspace components
In the diagram, there are four running workspaces: two belonging to User A, one to User B and one to User C.
Use the devfile format to specify the tools and runtime applications of a CodeReady Workspaces workspace.
1.3.2. CodeReady Workspaces workspace components Copy linkLink copied to clipboard!
This section describes the components of a CodeReady Workspaces workspace.
1.3.2.1. Che Editor plug-in Copy linkLink copied to clipboard!
A Che Editor plug-in is a CodeReady Workspaces workspace plug-in. It defines the web application that is used as an editor in a workspace. The default CodeReady Workspaces workspace editor is Che-Theia. It is a web-based source-code editor similar to Visual Studio Code (Visual Studio Code). It has a plug-in system that supports Visual Studio Code extensions.
| Source code | |
| Container image |
|
| Endpoints |
|
Additional resources
1.3.2.2. CodeReady Workspaces user runtimes Copy linkLink copied to clipboard!
Use any non-terminating user container as a user runtime. An application that can be defined as a container image or as a set of OpenShift resources can be included in a CodeReady Workspaces workspace. This makes it easy to test applications in the CodeReady Workspaces workspace.
To test an application in the CodeReady Workspaces workspace, include the application YAML definition used in stage or production in the workspace specification. It is a 12-factor application development / production parity.
Examples of user runtimes are Node.js, SpringBoot or MongoDB, and MySQL.
1.3.2.3. CodeReady Workspaces workspace JWT proxy Copy linkLink copied to clipboard!
The JWT proxy is responsible for securing the communication of the CodeReady Workspaces workspace services.
An HTTP proxy is used to sign outgoing requests from a workspace service to the CodeReady Workspaces server and to authenticate incoming requests from the IDE client running on a browser.
| Source code | |
| Container image |
|
1.3.2.4. CodeReady Workspaces plug-ins broker Copy linkLink copied to clipboard!
Plug-in brokers are special services that, given a plug-in meta.yaml file:
- Gather all the information to provide a plug-in definition that the CodeReady Workspaces server knows.
- Perform preparation actions in the workspace project (download, unpack files, process configuration).
The main goal of the plug-in broker is to decouple the CodeReady Workspaces plug-ins definitions from the actual plug-ins that CodeReady Workspaces can support. With brokers, CodeReady Workspaces can support different plug-ins without updating the CodeReady Workspaces server.
The CodeReady Workspaces server starts the plug-in broker. The plug-in broker runs in the same OpenShift project as the workspace. It has access to the plug-ins and project persistent volumes.
A plug-ins broker is defined as a container image (for example, eclipse/che-plugin-broker). The plug-in type determines the type of the broker that is started. Two types of plug-ins are supported: Che Plugin and Che Editor.
| Source code | |
| Container image |
|
1.3.3. CodeReady Workspaces workspace creation flow Copy linkLink copied to clipboard!
The following is a CodeReady Workspaces workspace creation flow:
A user starts a CodeReady Workspaces workspace defined by:
- An editor (the default is Che-Theia)
- A list of plug-ins (for example, Java and OpenShift tools)
- A list of runtime applications
- CodeReady Workspaces server retrieves the editor and plug-in metadata from the plug-in registry.
- For every plug-in type, CodeReady Workspaces server starts a specific plug-in broker.
The CodeReady Workspaces plug-ins broker transforms the plug-in metadata into a
Che Plugindefinition. It executes the following steps:- Downloads a plug-in and extracts its content.
-
Processes the plug-in
meta.yamlfile and sends it back to CodeReady Workspaces server in the format of aChe Plugin.
- CodeReady Workspaces server starts the editor and the plug-in sidecars.
- The editor loads the plug-ins from the plug-in persistent volume.
1.4. CodeReady Workspaces architecture with Dev Workspace Copy linkLink copied to clipboard!
Managing workspaces with the Dev Workspace engine is an experimental feature. Don’t use this workspace engine in production.
Known limitations
Workspaces are not secured. Whoever knows the URL of a workspace can have access to it and leak the user credentials.
Figure 1.6. High-level CodeReady Workspaces architecture with the Dev Workspace operator
When CodeReady Workspaces is running with the Dev Workspace operator, it runs on three groups of components:
- CodeReady Workspaces server components
- Manage User project and workspaces. The main component is the User dashboard, from which users control their workspaces.
- Dev Workspace operator
-
Creates and controls the necessary OpenShift objects to run User workspaces. Including
Pods,Services, andPeristentVolumes. - User workspaces
- Container-based development environments, the IDE included.
The role of these OpenShift features is central:
- Dev Workspace Custom Resources
- Valid OpenShift objects representing the User workspaces and manipulated by CodeReady Workspaces. It is the communication channel for the three groups of components.
- OpenShift role-based access control (RBAC)
- Controls access to all resources.
Additional resources
- Section 1.5, “CodeReady Workspaces server components”
- Section 1.5.2, “Dev Workspace operator”
- Section 1.6, “User workspaces”
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#enabling-dev-workspace-operator.adoc
- Dev Workspace Operator repository
- Kubernetes documentation - Custom Resources
1.5. CodeReady Workspaces server components Copy linkLink copied to clipboard!
Managing workspaces with the Dev Workspace engine is an experimental feature. Don’t use this workspace engine in production.
Known limitations
Workspaces are not secured. Whoever knows the URL of a workspace can have access to it and leak the user credentials.
The CodeReady Workspaces server components ensure multi-tenancy and workspaces management.
Figure 1.7. CodeReady Workspaces server components interacting with the Dev Workspace operator
Additional resources
1.5.1. CodeReady Workspaces operator Copy linkLink copied to clipboard!
The CodeReady Workspaces operator ensure full lifecycle management of the CodeReady Workspaces server components. It introduces:
CheClustercustom resource definition (CRD)-
Defines the
CheClusterOpenShift object. - CodeReady Workspaces controller
- Creates and controls the necessary OpenShift objects to run a CodeReady Workspaces instance, such as pods, services, and persistent volumes.
CheClustercustom resource (CR)On a cluster with the CodeReady Workspaces operator, it is possible to create a
CheClustercustom resource (CR). The CodeReady Workspaces operator ensures the full lifecycle management of the CodeReady Workspaces server components on this CodeReady Workspaces instance:
Additional resources
1.5.2. Dev Workspace operator Copy linkLink copied to clipboard!
Managing workspaces with the Dev Workspace engine is an experimental feature. Don’t use this workspace engine in production.
Known limitations
Workspaces are not secured. Whoever knows the URL of a workspace can have access to it and leak the user credentials.
The Dev Workspace operator extends OpenShift to provide Dev Workspace support. It introduces:
- Dev Workspace custom resource definition
- Defines the Dev Workspace OpenShift object from the Devfile v2 specification.
- Dev Workspace controller
- Creates and controls the necessary OpenShift objects to run a Dev Workspace, such as pods, services, and persistent volumes.
- Dev Workspace custom resource
- On a cluster with the Dev Workspace operator, it is possible to create Dev Workspace custom resources (CR). A Dev Workspace CR is a OpenShift representation of a Devfile. It defines a User workspaces in a OpenShift cluster.
1.5.3. Gateway Copy linkLink copied to clipboard!
The CodeReady Workspaces 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 CodeReady Workspaces resource. It uses `kube-rbac-proxy`.
The CodeReady Workspaces operator manages it as the che-gateway Deployment.
It controls access to:
Figure 1.8. CodeReady Workspaces gateway interactions with other components
Additional resources
1.5.4. User dashboard Copy linkLink copied to clipboard!
The user dashboard is the landing page of Red Hat CodeReady Workspaces. CodeReady Workspaces end-users browse the user dashboard to access and manage their workspaces. It is a React application. The CodeReady Workspaces deployment starts it in the codeready-dashboard Deployment.
It need access to:
Figure 1.9. 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:
- Collects the devfile from the Section 1.5.5, “Devfile registries”, when the user is Creating a workspace from a code sample.
- Sends the repository URL to Section 1.5.6, “CodeReady Workspaces server” and expects a devfile in return, when the user is Creating a workspace from remote devfile.
- Reads the devfile describing the workspace.
- Collects the additional metadata from the Section 1.5.8, “Plug-in registry”.
- Converts the information into a Dev Workspace Custom Resource.
- Creates the Dev Workspace Custom Resource in the user project using the OpenShift API.
- Watches the Dev Workspace Custom Resource status.
- Redirects the user to the running workspace IDE.
1.5.5. Devfile registries Copy linkLink copied to clipboard!
The CodeReady Workspaces devfile registries are services providing a list of sample devfiles to create ready-to-use workspaces. The Section 1.5.4, “User dashboard” displays the samples list on the Dashboard → Create Workspace page. Each sample includes a Devfile v2. The CodeReady Workspaces deployment starts one devfile registry instance in the devfile-registry deployment.
Figure 1.10. Devfile registries interactions with other components
Additional resources
1.5.6. CodeReady Workspaces server Copy linkLink copied to clipboard!
The CodeReady Workspaces 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 CodeReady Workspaces server is a Java web service exposing an HTTP REST API and needs access to:
- Section 1.5.7, “PostgreSQL”
- Git service providers
- OpenShift API
Figure 1.11. CodeReady Workspaces server interactions with other components
1.5.7. PostgreSQL Copy linkLink copied to clipboard!
CodeReady Workspaces server uses the PostgreSQL database to persist user configurations such as workspaces metadata.
The CodeReady Workspaces deployment starts a dedicated PostgreSQL instance in the postgres Deployment. You can use an external database instead.
Figure 1.12. PostgreSQL interactions with other components
1.5.8. Plug-in registry Copy linkLink copied to clipboard!
Each CodeReady Workspaces workspace starts with a specific editor and set of associated extensions. The CodeReady Workspaces plug-in registry provides the list of available editors and editor extensions. A Devfile v2 describes each editor or extension.
The Section 1.5.4, “User dashboard” is reading the content of the registry.
Figure 1.13. Plug-in registries interactions with other components
1.6. User workspaces Copy linkLink copied to clipboard!
Figure 1.14. 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 CodeReady Workspaces 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 CodeReady Workspaces workspace.
The following diagram shows one running CodeReady Workspaces workspace and its components.
Figure 1.15. CodeReady Workspaces workspace components
In the diagram, there is one running workspaces.
Chapter 2. Calculating CodeReady Workspaces resource requirements Copy linkLink copied to clipboard!
Additional resources
This section describes how to calculate resources, such as memory and CPU, required to run Red Hat CodeReady Workspaces.
Both the CodeReady Workspaces central controller and user workspaces consist of a set of containers. Those containers contribute to the resources consumption in terms of CPU and RAM limits and requests.
2.1. Controller requirements Copy linkLink copied to clipboard!
The Workspace Controller consists of a set of five services running in five distinct containers. The following table presents the default resource requirements of each of these services.
| Pod | Container name | Default memory limit | Default memory request |
|---|---|---|---|
| CodeReady Workspaces Server and Dashboard | che | 1 GiB | 512 MiB |
| PostgreSQL |
| 1 GiB | 512 MiB |
| RH-SSO |
| 2 GiB | 512 MiB |
| Devfile registry |
| 256 MiB | 16 MiB |
| Plug-in registry |
| 256 MiB | 16 MiB |
These default values are sufficient when the CodeReady Workspaces Workspace Controller manages a small amount of CodeReady Workspaces workspaces. For larger deployments, increase the memory limit. See the https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#advanced-configuration-options-for-the-che-server-component.adoc article for instructions on how to override the default requests and limits. For example, the Eclipse Che hosted by Red Hat that runs on https://workspaces.openshift.com uses 1 GB of memory.
Additional resources
2.2. Workspaces requirements Copy linkLink copied to clipboard!
This section describes how to calculate the resources required for a workspace. It is the sum of the resources required for each component of this workspace.
These examples demonstrate the necessity of a proper calculation:
- A workspace with ten active plug-ins requires more resources than the same workspace with fewer plug-ins.
- A standard Java workspace requires more resources than a standard Node.js workspace because running builds, tests, and application debugging requires more resources.
Procedure
-
Identify the workspace components explicitly specified in the
componentssection of the https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/end-user_guide/index#authoring-devfiles-version-2.adoc. Identify the implicit workspace components:
-
CodeReady Workspaces implicitly loads the default
cheEditor:che-theia, and thechePluginthat allows commands execution:che-machine-exec-plugin. To change the default editor, add acheEditorcomponent section in the devfile. - The JWT Proxy component is responsible for the authentication and authorization of the external communications of the workspace components.
-
CodeReady Workspaces implicitly loads the default
Calculate the requirements for each component:
Default values:
The following table displays the default requirements for all workspace components, and the corresponding CodeReady Workspaces server properties. Use the CodeReady Workspaces server properties to modify the defaults cluster-wide.
Expand Table 2.2. Default requirements of workspace components by type Component types CodeReady Workspaces server property Default memory limit Default memory request chePluginche.workspace.sidecar.default_memory_limit_mb128 MiB
64 MiB
cheEditorche.workspace.sidecar.default_memory_limit_mb128 MiB
64 MiB
kubernetes,openshift,dockerimageche.workspace.default_memory_limit_mb,che.workspace.default_memory_request_mb1 Gi
200 MiB
JWT Proxyche.server.secure_exposer.jwtproxy.memory_limit,che.server.secure_exposer.jwtproxy.memory_request128 MiB
15 MiB
Custom requirements for
chePluginsandcheEditorscomponents:Custom memory limit and request:
Define the
memoryLimitandmemoryRequestattributes of thecontainerssection of themeta.yamlfile to configure the memory limit of thechePluginsorcheEditorscomponents. CodeReady Workspaces automatically sets the memory request to match the memory limit if it is not specified explicitly.Example 2.1. The
chePluginche-incubator/typescript/latestmeta.yamlspec section:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This results in a container with the following memory limit and request:
Expand Memory limit
512 MiB
Memory request
256 MiB
NoteFor IBM Power (ppc64le), the memory limit for some plugins has been increased by up to 1.5G to allow pods sufficient RAM to run. For example, on IBM Power (ppc64le), the Theia editor pod requires 2G; the OpenShift connector pod requires 2.5G. For AMD64 and Intel 64 (x86_64) and IBM Z (s390x), memory requirements remain lower at 512M and 1500M respectively. However, some devfiles may still be configured to set the lower limit valid for AMD64 and Intel 64 (x86_64) and IBM Z (s390x), so to work around this, edit devfiles for workspaces that are crashing to increase the default memoryLimit by at least 1 - 1.5 GB.
NoteHow to find the
meta.yamlfile ofchePluginCommunity plug-ins are available in the CodeReady Workspaces plug-ins registry repository in folder
v3/plugins/${organization}/${name}/${version}/.For non-community or customized plug-ins, the
meta.yamlfiles are available on the local OpenShift cluster at${pluginRegistryEndpoint}/v3/plugins/${organization}/${name}/${version}/meta.yaml.Custom CPU limit and request:
CodeReady Workspaces does not set CPU limits and requests by default. However, it is possible to configure CPU limits for the
chePluginandcheEditortypes in themeta.yamlfile or in the devfile in the same way as it done for memory limits.Example 2.2. The
chePluginche-incubator/typescript/latestmeta.yamlspec section:Copy to Clipboard Copied! Toggle word wrap Toggle overflow It results in a container with the following CPU limit and request:
Expand CPU limit
2 cores
CPU request
0.5 cores
To set CPU limits and requests globally, use the following dedicated environment variables:
|
|
|
|
|
|
Note that the LimitRange object of the OpenShift project may specify defaults for CPU limits and requests set by cluster administrators. To prevent start errors due to resources overrun, limits on application or workspace levels must comply with those settings.
Custom requirements for
dockerimagecomponentsDefine the
memoryLimitandmemoryRequestattributes of the devfile to configure the memory limit of adockerimagecontainer. CodeReady Workspaces automatically sets the memory request to match the memory limit if it is not specified explicitly.- alias: maven type: dockerimage image: eclipse/maven-jdk8:latest memoryLimit: 1536M- alias: maven type: dockerimage image: eclipse/maven-jdk8:latest memoryLimit: 1536MCopy to Clipboard Copied! Toggle word wrap Toggle overflow Custom requirements for
kubernetesoropenshiftcomponents:The referenced manifest may define the memory requirements and limits.
- Add all previously calculated requirements.
Additional resources
2.3. A workspace example Copy linkLink copied to clipboard!
This section describes a CodeReady Workspaces workspace example.
The following devfile defines the CodeReady Workspaces workspace:
This table provides the memory requirements for each workspace component:
| Pod | Container name | Default memory limit | Default memory request |
|---|---|---|---|
| Workspace |
| 512 MiB | 512 MiB |
| Workspace |
| 128 MiB | 32 MiB |
| Workspace |
| 512 MiB | 512 MiB |
| Workspace |
| 1 GiB | 512 MiB |
| JWT Proxy | verifier | 128 MiB | 128 MiB |
| Total | 2.25 GiB | 1.38 GiB | |
-
The
theia-ideandmachine-execcomponents are implicitly added to the workspace, even when not included in the devfile. -
The resources required by
machine-execare the default forchePlugin. -
The resources for
theia-ideare specifically set in thecheEditormeta.yamlto 512 MiB asmemoryLimit. -
The Typescript Visual Studio Code extension has also overridden the default memory limits. In its
meta.yamlfile, the limits are explicitly specified to 512 MiB. -
CodeReady Workspaces is applying the defaults for the
dockerimagecomponent type: a memory limit of 1 GiB and a memory request of 512 MiB. - The JWT container requires 128 MiB of memory.
Adding all together results in 1.38 GiB of memory requests with a 2.25 GiB limit.
Additional resources
- Chapter 1, Architecture overview
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#configuring-the-che-installation.adoc
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#advanced-configuration-options-for-the-che-server-component.adoc
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/end-user_guide/index#authoring-devfiles-version-2.adoc
- Section 12.1, “Authenticating users”
- CodeReady Workspaces plug-ins registry repository
Chapter 3. Customizing the registries Copy linkLink copied to clipboard!
This chapter describes how to build and run custom registries for CodeReady Workspaces.
3.1. Understanding the CodeReady Workspaces registries Copy linkLink copied to clipboard!
CodeReady Workspaces uses two registries: the plug-ins registry and the devfile registry. They are static websites publishing the metadata of CodeReady Workspaces plug-ins and devfiles. When built-in offline mode they also include artifacts.
The devfile and plug-in registries run in two separate Pods. Their deployment is part of the CodeReady Workspaces installation.
The devfile and plug-in registries
- The devfile registry
-
The devfile registry holds the definitions of the CodeReady Workspaces stacks. Stacks are available on the CodeReady Workspaces user dashboard when selecting Create Workspace. It contains the list of CodeReady Workspaces technological stack samples with example projects. When built-in offline mode it also contains all sample projects referenced in devfiles as
zipfiles. - The plug-in registry
- The plug-in registry makes it possible to share a plug-in definition across all the users of the same instance of CodeReady Workspaces. When built-in offline mode it also contains all plug-in or extension artifacts.
Additional resources
3.2. Building custom registry images Copy linkLink copied to clipboard!
3.2.1. Building a custom devfile registry image Copy linkLink copied to clipboard!
This section describes how to build a custom devfile registry image. The procedure explains how to add a devfile. The image contains all sample projects referenced in devfiles.
Prerequisites
- A running installation of podman or docker.
- Valid content for the devfile to add. See: https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/end-user_guide/index#authoring-devfiles-version-2.adoc.
Procedure
Clone the devfile registry repository and check out the version to deploy:
git clone git@github.com:redhat-developer/codeready-workspaces.git cd codeready-workspaces git checkout crw-2.15-rhel-8
$ git clone git@github.com:redhat-developer/codeready-workspaces.git $ cd codeready-workspaces $ git checkout crw-2.15-rhel-8Copy to Clipboard Copied! Toggle word wrap Toggle overflow In the
./dependencies/che-devfile-registry/devfiles/directory, create a subdirectory<devfile-name>/and add thedevfile.yamlandmeta.yamlfiles.Example 3.1. File organization for a devfile
./dependencies/che-devfile-registry/devfiles/ └── <devfile-name> ├── devfile.yaml └── meta.yaml./dependencies/che-devfile-registry/devfiles/ └── <devfile-name> ├── devfile.yaml └── meta.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Add valid content in the
devfile.yamlfile. For a detailed description of the devfile format, see https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/end-user_guide/index#authoring-devfiles-version-2.adoc. Ensure that the
meta.yamlfile conforms to the following structure:Expand Table 3.1. Parameters for a devfile meta.yaml Attribute Description descriptionDescription as it appears on the user dashboard.
displayNameName as it appears on the user dashboard.
iconLink to an
.svgfile that is displayed on the user dashboard.tagsList of tags. Tags typically include the tools included in the stack.
globalMemoryLimitOptional parameter: the sum of the expected memory consumed by all the components launched by the devfile. This number will be visible on the user dashboard. It is informative and is not taken into account by the CodeReady Workspaces server.
Example 3.2. Example devfile
meta.yamldisplayName: Rust description: Rust Stack with Rust 1.39 tags: ["Rust"] icon: https://www.eclipse.org/che/images/logo-eclipseche.svg globalMemoryLimit: 1686Mi
displayName: Rust description: Rust Stack with Rust 1.39 tags: ["Rust"] icon: https://www.eclipse.org/che/images/logo-eclipseche.svg globalMemoryLimit: 1686MiCopy to Clipboard Copied! Toggle word wrap Toggle overflow Build a custom devfile registry image:
cd dependencies/che-devfile-registry ./build.sh --organization <my-org> \ --registry <my-registry> \ --tag <my-tag>$ cd dependencies/che-devfile-registry $ ./build.sh --organization <my-org> \ --registry <my-registry> \ --tag <my-tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteTo display full options for the
build.shscript, use the--helpparameter.
3.2.2. Building a custom plug-ins registry image Copy linkLink copied to clipboard!
This section describes how to build a custom plug-ins registry image. The procedure explains how to add a plug-in. The image contains plug-ins or extensions metadata.
Prerequisites
- Node.js 12.x
- A running version of yarn. See: Installing Yarn.
-
./node_modules/.binis in thePATHenvironment variable. - A running installation of podman or docker.
Procedure
Clone the plug-ins registry repository and check out the version to deploy:
git clone git@github.com:redhat-developer/codeready-workspaces.git cd codeready-workspaces git checkout crw-2.15-rhel-8
$ git clone git@github.com:redhat-developer/codeready-workspaces.git $ cd codeready-workspaces $ git checkout crw-2.15-rhel-8Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
In the
./dependencies/che-plugin-registry/directory, edit theche-theia-plugins.yamlfile. -
Add valid content to the
che-theia-plugins.yamlfile, for detailed information see: https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/end-user_guide/index#adding-a-vs-code-extension-to-the-che-plugin-registry.adoc. Build a custom plug-ins registry image:
cd dependencies/che-plugin-registry ./build.sh --organization <my-org> \ --registry <my-registry> \ --tag <my-tag>$ cd dependencies/che-plugin-registry $ ./build.sh --organization <my-org> \ --registry <my-registry> \ --tag <my-tag>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteTo display full options for the
build.shscript, use the--helpparameter. To include the plug-in binaries in the registry image, add the--offlineparameter.Observe the contents of
./dependencies/che-plugin-registry/v3/plugins/present in the container after building the registry. Allmeta.yamlfiles resulting from a successful plug-ins registry build will be located here.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Additional resources
3.3. Running custom registries Copy linkLink copied to clipboard!
Prerequisites
The my-plug-in-registry and my-devfile-registry images used in this section are built using the docker command. This section assumes that these images are available on the OpenShift cluster where CodeReady Workspaces is deployed.
These images can be then pushed to:
-
A public container registry such as
quay.io, or the DockerHub. - A private registry.
3.3.1. Deploying registries in OpenShift Copy linkLink copied to clipboard!
Procedure
An OpenShift template to deploy the plug-in registry is available in the deploy/openshift/ directory of the GitHub repository.
To deploy the plug-in registry using the OpenShift template, run the following command:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- If installed using crwctl, the default CodeReady Workspaces project is
openshift-workspaces. The OperatorHub installation method deploys CodeReady Workspaces to the users current project.
The devfile registry has an OpenShift template in the
deploy/openshift/directory of the GitHub repository. To deploy it, run the command:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- If installed using crwctl, the default CodeReady Workspaces project is
openshift-workspaces. The OperatorHub installation method deploys CodeReady Workspaces to the users current project.
Verification steps
The <plug-in> plug-in is available in the plug-in registry.
Example 3.3. Find <plug-in> requesting the plug-in registry API.
URL=$(oc get route -l app=che,component=plugin-registry \ -o 'custom-columns=URL:.spec.host' --no-headers) INDEX_JSON=$(curl -sSL http://${URL}/v3/plugins/index.json) echo ${INDEX_JSON} | jq '.[] | select(.name == "<plug-in>")'$ URL=$(oc get route -l app=che,component=plugin-registry \ -o 'custom-columns=URL:.spec.host' --no-headers) $ INDEX_JSON=$(curl -sSL http://${URL}/v3/plugins/index.json) $ echo ${INDEX_JSON} | jq '.[] | select(.name == "<plug-in>")'Copy to Clipboard Copied! Toggle word wrap Toggle overflow The <devfile> devfile is available in the devfile registry.
Example 3.4. Find <devfile> requesting the devfile registry API.
URL=$(oc get route -l app=che,component=devfile-registry \ -o 'custom-columns=URL:.spec.host' --no-headers) INDEX_JSON=$(curl -sSL http://${URL}/v3/plugins/index.json) echo ${INDEX_JSON} | jq '.[] | select(.name == "<devfile>")'$ URL=$(oc get route -l app=che,component=devfile-registry \ -o 'custom-columns=URL:.spec.host' --no-headers) $ INDEX_JSON=$(curl -sSL http://${URL}/v3/plugins/index.json) $ echo ${INDEX_JSON} | jq '.[] | select(.name == "<devfile>")'Copy to Clipboard Copied! Toggle word wrap Toggle overflow CodeReady Workspaces server points to the URL of the plug-in registry.
Example 3.5. Compare the value of the
CHE_WORKSPACE_PLUGIN__REGISTRY__URLparameter in thecheConfigMap with the URL of the plug-in registry route.Get the value of the
CHE_WORKSPACE_PLUGIN__REGISTRY__URLparameter in thecheConfigMap.oc get cm/che \ -o "custom-columns=URL:.data['CHE_WORKSPACE_PLUGIN__REGISTRY__URL']" \ --no-headers
$ oc get cm/che \ -o "custom-columns=URL:.data['CHE_WORKSPACE_PLUGIN__REGISTRY__URL']" \ --no-headersCopy to Clipboard Copied! Toggle word wrap Toggle overflow Get the URL of the plug-in registry route.
oc get route -l app=che,component=plugin-registry \ -o 'custom-columns=URL: .spec.host' --no-headers
$ oc get route -l app=che,component=plugin-registry \ -o 'custom-columns=URL: .spec.host' --no-headersCopy to Clipboard Copied! Toggle word wrap Toggle overflow CodeReady Workspaces server points to the URL of the devfile registry.
Example 3.6. Compare the value of the
CHE_WORKSPACE_DEVFILE__REGISTRY__URLparameter in thecheConfigMap with the URL of the devfile registry route.Get the value of the
CHE_WORKSPACE_DEVFILE__REGISTRY__URLparameter in thecheConfigMap.oc get cm/che \ -o "custom-columns=URL:.data['CHE_WORKSPACE_DEVFILE__REGISTRY__URL']" \ --no-headers
$ oc get cm/che \ -o "custom-columns=URL:.data['CHE_WORKSPACE_DEVFILE__REGISTRY__URL']" \ --no-headersCopy to Clipboard Copied! Toggle word wrap Toggle overflow Get the URL of the devfile registry route.
oc get route -l app=che,component=devfile-registry \ -o 'custom-columns=URL: .spec.host' --no-headers
$ oc get route -l app=che,component=devfile-registry \ -o 'custom-columns=URL: .spec.host' --no-headersCopy to Clipboard Copied! Toggle word wrap Toggle overflow If the values do not match, update the ConfigMap and restart the CodeReady Workspaces server.
oc edit cm/codeready (...) oc scale --replicas=0 deployment/codeready oc scale --replicas=1 deployment/codeready
$ oc edit cm/codeready (...) $ oc scale --replicas=0 deployment/codeready $ oc scale --replicas=1 deployment/codereadyCopy to Clipboard Copied! Toggle word wrap Toggle overflow The plug-ins are available in the:
- Completion to chePlugin components in the Devfile tab of a workspace details
- Plugin Che-Theia view of a workspace
- The devfiles are available in the Quick Add and Custom Workspace tab of the Create Workspace page on the user dashboard.
3.3.2. Adding a custom plug-in registry in an existing CodeReady Workspaces workspace Copy linkLink copied to clipboard!
The following section describes two methods of adding a custom plug-in registry in an existing CodeReady Workspaces workspace:
- Adding a custom plug-in registry using Command palette - For adding a new custom plug-in registry quickly, with a use of text inputs from Command palette command. This method does not allow a user to edit already existing information, such as plug-in registry URL or name.
-
Adding a custom plug-in registry using the
settings.jsonfile - For adding a new custom plug-in registry and editing of the already existing entries.
3.3.2.1. Adding a custom plug-in registry using Command Palette Copy linkLink copied to clipboard!
Prerequisites
- An instance of CodeReady Workspaces
Procedure
In the CodeReady Workspaces IDE, press F1 to open the Command Palette, or navigate to View → Find Command in the top menu.
The command palette can be also activated by pressing Ctrl+Shift+p (or Cmd+Shift+p on macOS).
-
Enter the
Add Registrycommand into the search box and pres Enter once filled. Enter the registry name and registry URL in next two command prompts.
- After adding a new plug-in registry, the list of plug-ins in the Plug-ins view is refreshed, and if the new plug-in registry is not valid, a user is notified by a warning message.
3.3.2.2. Adding a custom plug-in registry using the settings.json file Copy linkLink copied to clipboard!
The following section describes the use of the main CodeReady Workspaces Settings menu to edit and add a new plug-in registry using the settings.json file.
Prerequisites
- An instance of CodeReady Workspaces
Procedure
- From the main CodeReady Workspaces screen, select Open Preferences by pressing Ctrl+, or using the gear wheel icon on the left bar.
Select Che Plug-ins and continue by Edit in
setting.jsonlink.The
setting.jsonfile is displayed.Add a new plug-in registry using the
chePlugins.repositoriesattribute as shown below:{ “application.confirmExit”: “never”, “chePlugins.repositories”: {“test”: “https://test.com”} }{ “application.confirmExit”: “never”, “chePlugins.repositories”: {“test”: “https://test.com”} }Copy to Clipboard Copied! Toggle word wrap Toggle overflow Save the changes to add a custom plug-in registry in an existing CodeReady Workspaces workspace.
-
A newly added plug-in validation tool checks the correctness of URL values set in the
chePlugins.repositoriesfield of thesettings.jsonfile. -
After adding a new plug-in registry, the list of plug-ins in the Plug-ins view is refreshed, and if the new plug-in registry is not valid, a user is notified by a warning message. This check is also functional for plug-ins added using the Command palette command
Add plugin registry.
-
A newly added plug-in validation tool checks the correctness of URL values set in the
Chapter 4. Retrieving CodeReady Workspaces logs Copy linkLink copied to clipboard!
For information about obtaining various types of logs in CodeReady Workspaces, see the following sections:
4.1. Configuring server logging Copy linkLink copied to clipboard!
It is possible to fine-tune the log levels of individual loggers available in the CodeReady Workspaces server.
The log level of the whole CodeReady Workspaces server is configured globally using the cheLogLevel configuration property of the Operator. See https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#checluster-custom-resource-fields-reference.adoc. To set the global log level in installations not managed by the Operator, specify the CHE_LOG_LEVEL environment variable in the che ConfigMap.
It is possible to configure the log levels of the individual loggers in the CodeReady Workspaces server using the CHE_LOGGER_CONFIG environment variable.
4.1.1. Configuring log levels Copy linkLink copied to clipboard!
The format of the value of the CHE_LOGGER_CONFIG property is a list of comma-separated key-value pairs, where keys are the names of the loggers as seen in the CodeReady Workspaces server log output and values are the required log levels.
In Operator-based deployments, the CHE_LOGGER_CONFIG variable is specified under the customCheProperties of the custom resource.
For example, the following snippet would make the WorkspaceManager produce the DEBUG log messages.
...
server:
customCheProperties:
CHE_LOGGER_CONFIG: "org.eclipse.che.api.workspace.server.WorkspaceManager=DEBUG"
...
server:
customCheProperties:
CHE_LOGGER_CONFIG: "org.eclipse.che.api.workspace.server.WorkspaceManager=DEBUG"
4.1.2. Logger naming Copy linkLink copied to clipboard!
The names of the loggers follow the class names of the internal server classes that use those loggers.
4.1.3. Logging HTTP traffic Copy linkLink copied to clipboard!
It is possible to log the HTTP traffic between the CodeReady Workspaces server and the API server of the Kubernetes or OpenShift cluster. To do that, one has to set the che.infra.request-logging logger to the TRACE level.
...
server:
customCheProperties:
CHE_LOGGER_CONFIG: "che.infra.request-logging=TRACE"
...
server:
customCheProperties:
CHE_LOGGER_CONFIG: "che.infra.request-logging=TRACE"
4.2. Accessing OpenShift events on OpenShift Copy linkLink copied to clipboard!
For high-level monitoring of OpenShift projects, view the OpenShift events that the project performs.
This section describes how to access these events in the OpenShift web console.
Prerequisites
- A running OpenShift web console.
Procedure
- In the left panel of the OpenShift web console, click the Home → Events.
- To view the list of all events for a particular project, select the project from the list.
- The details of the events for the current project are displayed.
Additional resources
- For a list of OpenShift events, see Comprehensive List of Events in OpenShift documentation.
4.3. Viewing the state of the CodeReady Workspaces cluster deployment using OpenShift 4 CLI tools Copy linkLink copied to clipboard!
This section describes how to view the state of the CodeReady Workspaces cluster deployment using OpenShift 4 CLI tools.
Prerequisites
- An instance of Red Hat CodeReady Workspaces running on OpenShift.
-
An installation of the OpenShift command-line tool,
oc.
Procedure
Run the following commands to select the
crwproject:oc project <project_name>
$ oc project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Run the following commands to get the name and status of the Pods running in the selected project:
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Check that the status of all the Pods is
Running.Example 4.1. Pods with status
RunningNAME READY STATUS RESTARTS AGE codeready-8495f4946b-jrzdc 0/1 Running 0 86s codeready-operator-578765d954-99szc 1/1 Running 0 42m keycloak-74fbfb9654-g9vp5 1/1 Running 0 4m32s postgres-5d579c6847-w6wx5 1/1 Running 0 5m14s
NAME READY STATUS RESTARTS AGE codeready-8495f4946b-jrzdc 0/1 Running 0 86s codeready-operator-578765d954-99szc 1/1 Running 0 42m keycloak-74fbfb9654-g9vp5 1/1 Running 0 4m32s postgres-5d579c6847-w6wx5 1/1 Running 0 5m14sCopy to Clipboard Copied! Toggle word wrap Toggle overflow To see the state of the CodeReady Workspaces cluster deployment, run:
oc logs --tail=10 -f `(oc get pods -o name | grep operator)`
$ oc logs --tail=10 -f `(oc get pods -o name | grep operator)`Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example 4.2. Logs of the Operator:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4. Viewing CodeReady Workspaces server logs Copy linkLink copied to clipboard!
This section describes how to view the CodeReady Workspaces server logs using the command line.
4.4.1. Viewing the CodeReady Workspaces server logs using the OpenShift CLI Copy linkLink copied to clipboard!
This section describes how to view the CodeReady Workspaces server logs using the OpenShift CLI (command line interface).
Procedure
In the terminal, run the following command to get the Pods:
oc get pods
$ oc get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Example
oc get pods NAME READY STATUS RESTARTS AGE codeready-11-j4w2b 1/1 Running 0 3m
$ oc get pods NAME READY STATUS RESTARTS AGE codeready-11-j4w2b 1/1 Running 0 3mCopy to Clipboard Copied! Toggle word wrap Toggle overflow To get the logs for a deployment, run the following command:
oc logs <name-of-pod>
$ oc logs <name-of-pod>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example
oc logs codeready-11-j4w2b
$ oc logs codeready-11-j4w2bCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5. Viewing external service logs Copy linkLink copied to clipboard!
This section describes how the view the logs from external services related to CodeReady Workspaces server.
4.5.1. Viewing RH-SSO logs Copy linkLink copied to clipboard!
The RH-SSO OpenID provider consists of two parts: Server and IDE. It writes its diagnostics or error information to several logs.
4.5.1.1. Viewing the RH-SSO server logs Copy linkLink copied to clipboard!
This section describes how to view the RH-SSO OpenID provider server logs.
Procedure
- In the OpenShift Web Console, click Deployments.
-
In the Filter by label search field, type
keycloakto see the RH-SSO logs.
. In the Deployment Configs section, click the keycloak link to open it.
- In the History tab, click the View log link for the active RH-SSO deployment.
- The RH-SSO logs are displayed.
Additional resources
- See the Section 4.4, “Viewing CodeReady Workspaces server logs” for diagnostics and error messages related to the RH-SSO IDE Server.
4.5.1.2. Viewing the RH-SSO client logs on Mozilla Firefox Copy linkLink copied to clipboard!
This section describes how to view the RH-SSO IDE client diagnostics or error information in the Mozilla Firefox WebConsole.
Procedure
- Click Menu > WebDeveloper > WebConsole.
4.5.1.3. Viewing the RH-SSO client logs on Google Chrome Copy linkLink copied to clipboard!
This section describes how to view the RH-SSO IDE client diagnostics or error information in the Google Chrome Console tab.
Procedure
- Click Menu > More Tools > Developer Tools.
- Click the Console tab.
4.5.2. Viewing the CodeReady Workspaces database logs Copy linkLink copied to clipboard!
This section describes how to view the database logs in CodeReady Workspaces, such as PostgreSQL server logs.
Procedure
- In the OpenShift Web Console, click Deployments.
In the Find by label search field, type:
-
app=cheand press Enter component=postgresand press EnterThe OpenShift Web Console is searching base on those two keys and displays PostgreSQL logs.
-
-
Click
postgresdeployment to open it. Click the View log link for the active PostgreSQL deployment.
The OpenShift Web Console displays the database logs.
Additional resources
- Some diagnostics or error messages related to the PostgreSQL server can be found in the active CodeReady Workspaces deployment log. For details to access the active CodeReady Workspaces deployments logs, see the Section 4.4, “Viewing CodeReady Workspaces server logs” section.
4.6. Viewing the plug-in broker logs Copy linkLink copied to clipboard!
This section describes how to view the plug-in broker logs.
The che-plugin-broker Pod itself is deleted when its work is complete. Therefore, its event logs are only available while the workspace is starting.
Procedure
To see logged events from temporary Pods:
- Start a CodeReady Workspaces workspace.
- From the main OpenShift Container Platform screen, go to Workload → Pods.
- Use the OpenShift terminal console located in the Pod’s Terminal tab
Verification step
- OpenShift terminal console displays the plug-in broker logs while the workspace is starting
4.7. Collecting logs using crwctl Copy linkLink copied to clipboard!
It is possible to get all Red Hat CodeReady Workspaces logs from a OpenShift cluster using the crwctl tool.
-
crwctl server:deployautomatically starts collecting Red Hat CodeReady Workspaces servers logs during installation of Red Hat CodeReady Workspaces -
crwctl server:logscollects existing Red Hat CodeReady Workspaces server logs -
crwctl workspace:logscollects workspace logs
Chapter 5. Monitoring CodeReady Workspaces Copy linkLink copied to clipboard!
This chapter describes how to configure CodeReady Workspaces to expose metrics and how to build an example monitoring stack with external tools to process data exposed as metrics by CodeReady Workspaces.
5.1. Enabling and exposing CodeReady Workspaces metrics Copy linkLink copied to clipboard!
This section describes how to enable and expose CodeReady Workspaces metrics.
Procedure
-
Set the
CHE_METRICS_ENABLED=trueenvironment variable, which will expose the8087port as a service on theche-masterhost.
When Red Hat CodeReady Workspaces is installed from the OperatorHub, the environment variable is set automatically if the default CheCluster CR is used:
spec:
metrics:
enable: true
spec:
metrics:
enable: true
5.2. Collecting CodeReady Workspaces metrics with Prometheus Copy linkLink copied to clipboard!
This section describes how to use the Prometheus monitoring system to collect, store, and query metrics about CodeReady Workspaces.
Prerequisites
-
CodeReady Workspaces is exposing metrics on port
8087. See Enabling and exposing CodeReady Workspaces metrics. -
Prometheus 2.9.1 or later is running. The Prometheus console is running on port
9090with a corresponding service and route. See First steps with Prometheus.
Procedure
Configure Prometheus to scrape metrics from the
8087port:Example 5.1. Prometheus configuration example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Rate, at which a target is scraped.
- 2
- Rate, at which recording and alerting rules are re-checked (not used in the system at the moment).
- 3
- Resources Prometheus monitors. In the default configuration, a single job called
che, scrapes the time series data exposed by the CodeReady Workspaces server. - 4
- Scrape metrics from the
8087port.
Verification steps
Use the Prometheus console to query and view metrics.
Metrics are available at:
http://<che-server-url>:9090/metrics.For more information, see Using the expression browser.
Additional resources
Chapter 6. Monitoring the Dev Workspace operator Copy linkLink copied to clipboard!
This chapter describes how to configure an example monitoring stack to process metrics exposed by the Dev Workspace operator. You must enable the Dev Workspace operator to follow the instructions in this chapter. See https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#enabling-dev-workspace-operator.adoc.
6.1. Collecting Dev Workspace operator metrics with Prometheus Copy linkLink copied to clipboard!
This section describes how to use the Prometheus to collect, store, and query metrics about the Dev Workspace operator.
Prerequisites
-
The
devworkspace-controller-metricsservice is exposing metrics on port8443. -
The
devworkspace-webhookserverservice is exposing metrics on port9443. By default, the service exposes metrics on port9443. -
Prometheus 2.26.0 or later is running. The Prometheus console is running on port
9090with a corresponding service and route. See First steps with Prometheus.
Procedure
Create a
ClusterRoleBindingto bind theServiceAccountassociated with Prometheus to the devworkspace-controller-metrics-readerClusterRole. Without theClusterRoleBinding, you cannot access Dev Workspace metrics because they are protected with role-based access control (RBAC).Example 6.1. ClusterRole example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example 6.2. ClusterRoleBinding example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Configure Prometheus to scrape metrics from the
8443port exposed by thedevworkspace-controller-metricsservice, and9443port exposed by thedevworkspace-webhookserverservice.Example 6.3. Prometheus configuration example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1
- Rate at which a target is scraped.
- 2
- Rate at which recording and alerting rules are re-checked.
- 3
- Resources that Prometheus monitors. In the default configuration, two jobs (
DevWorkspaceandDevWorkspace webhooks), scrape the time series data exposed by thedevworkspace-controller-metricsanddevworkspace-webhookserverservices. - 4
- Scrape metrics from the
8443port. - 5
- Scrape metrics from the
9443port.
Verification steps
Use the Prometheus console to view targets and metrics.
For more information, see Using the expression browser.
6.2. Dev Workspace-specific metrics Copy linkLink copied to clipboard!
This section describes the Dev Workspace-specific metrics exposed by the devworkspace-controller-metrics service.
| Name | Type | Description | Labels |
|---|---|---|---|
|
| Counter | Number of Dev Workspace starting events. |
|
|
| Counter |
Number of Dev Workspaces successfully entering the |
|
|
| Counter | Number of failed Dev Workspaces. |
|
|
| Histogram | Total time taken to start a Dev Workspace, in seconds. |
|
| Name | Description | Values |
|---|---|---|
|
|
The |
|
|
|
The |
|
|
| The workspace startup failure reason. |
|
| Name | Description |
|---|---|
|
| Startup failure due to an invalid devfile used to create a Dev Workspace. |
|
|
Startup failure due to the following errors: |
|
| Unknown failure reason. |
Chapter 7. Tracing CodeReady Workspaces Copy linkLink copied to clipboard!
Tracing helps gather timing data to troubleshoot latency problems in microservice architectures and helps to understand a complete transaction or workflow as it propagates through a distributed system. Every transaction may reflect performance anomalies in an early phase when new services are being introduced by independent teams.
Tracing the CodeReady Workspaces application may help analyze the execution of various operations, such as workspace creations, workspace startup, breaking down the duration of sub-operations executions, helping finding bottlenecks and improve the overall state of the platform.
Tracers live in applications. They record timing and metadata about operations that take place. They often instrument libraries, so that their use is indiscernible to users. For example, an instrumented web server records when it received a request and when it sent a response. The trace data collected is called a span. A span has a context that contains information such as trace and span identifiers and other kinds of data that can be propagated down the line.
7.1. Tracing API Copy linkLink copied to clipboard!
CodeReady Workspaces utilizes OpenTracing API - a vendor-neutral framework for instrumentation. This means that if a developer wants to try a different tracing back end, then rather than repeating the whole instrumentation process for the new distributed tracing system, the developer can simply change the configuration of the tracer back end.
7.2. Tracing back end Copy linkLink copied to clipboard!
By default, CodeReady Workspaces uses Jaeger as the tracing back end. Jaeger was inspired by Dapper and OpenZipkin, and it is a distributed tracing system released as open source by Uber Technologies. Jaeger extends a more complex architecture for a larger scale of requests and performance.
7.3. Installing the Jaeger tracing tool Copy linkLink copied to clipboard!
The following sections describe the installation methods for the Jaeger tracing tool. Jaeger can then be used for gathering metrics in CodeReady Workspaces.
Installation methods available:
For tracing a CodeReady Workspaces instance using Jaeger, version 1.12.0 or above is required. For additional information about Jaeger, see the Jaeger website.
7.3.1. Installing Jaeger using OperatorHub on OpenShift 4 Copy linkLink copied to clipboard!
This section provide information about using Jaeger tracing tool for testing an evaluation purposes in production.
To install the Jaeger tracing tool from the OperatorHub interface in OpenShift Container Platform, follow the instructions below.
Prerequisites
- The user is logged in to the OpenShift Container Platform Web Console.
- A CodeReady Workspaces instance is available in a project.
Procedure
- Open the OpenShift Container Platform console.
- From the left menu of the main OpenShift Container Platform screen, navigate to Operators → OperatorHub.
-
In the Search by keyword search bar, type
Jaeger Operator. -
Click the
Jaeger Operatortile. -
Click the button in the
Jaeger Operatorpop-up window. -
Select the installation method:
A specific project on the clusterwhere the CodeReady Workspaces is deployed and leave the rest in its default values. - Click the Subscribe button.
- From the left menu of the main OpenShift Container Platform screen, navigate to the Operators → Installed Operators section.
- Red Hat CodeReady Workspaces is displayed as an Installed Operator, as indicated by the InstallSucceeded status.
- Click the Jaeger Operator name in the list of installed Operators.
- Navigate to the Overview tab.
-
In the Conditions sections at the bottom of the page, wait for this message:
install strategy completed with no errors. -
Jaeger Operatorand additionalElasticsearch Operatoris installed. - Navigate to the Operators → Installed Operators section.
- Click Jaeger Operator in the list of installed Operators.
- The Jaeger Cluster page is displayed.
- In the lower left corner of the window, click Create Instance
- Click Save.
-
OpenShift creates the Jaeger cluster
jaeger-all-in-one-inmemory. - Follow the steps in Enabling metrics collection to finish the procedure.
7.3.2. Installing Jaeger using CLI on OpenShift 4 Copy linkLink copied to clipboard!
This section provide information about using Jaeger tracing tool for testing an evaluation purposes.
To install the Jaeger tracing tool from a CodeReady Workspaces project in OpenShift Container Platform, follow the instructions in this section.
Prerequisites
- The user is logged in to the OpenShift Container Platform web console.
- A instance of CodeReady Workspaces in an OpenShift Container Platform cluster.
Procedure
In the CodeReady Workspaces installation project of the OpenShift Container Platform cluster, use the
occlient to create a new application for the Jaeger deployment.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Using the Workloads → Deployments from the left menu of main OpenShift Container Platform screen, monitor the Jaeger deployment until it finishes successfully.
- Select Networking → Routes from the left menu of the main OpenShift Container Platform screen, and click the URL link to access the Jaeger dashboard.
- Follow the steps in Enabling metrics collection to finish the procedure.
7.4. Enabling metrics collection Copy linkLink copied to clipboard!
Prerequisites
- Installed Jaeger v1.12.0 or above. See instructions at Section 7.3, “Installing the Jaeger tracing tool”
Procedure
For Jaeger tracing to work, enable the following environment variables in your CodeReady Workspaces deployment:
To enable the following environment variables:
In the
yamlsource code of the CodeReady Workspaces deployment, add the following configuration variables underspec.server.customCheProperties.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
JAEGER_ENDPOINTvalue to match the name of the Jaeger collector service in your deployment.From the left menu of the main OpenShift Container Platform screen, obtain the value of JAEGER_ENDPOINT by navigation to Networking → Services. Alternatively, execute the following
occommand:oc get services
$ oc get servicesCopy to Clipboard Copied! Toggle word wrap Toggle overflow The requested value is included in the service name that contains the
collectorstring.
Additional resources
- For additional information about custom environment properties and how to define them in CheCluster Custom Resource, see https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#advanced-configuration-options-for-the-che-server-component.adoc.
- For custom configuration of Jaeger, see the list of Jaeger client environment variables.
7.5. Viewing CodeReady Workspaces traces in Jaeger UI Copy linkLink copied to clipboard!
This section demonstrates how to use the Jaeger UI to overview traces of CodeReady Workspaces operations.
Procedure
In this example, the CodeReady Workspaces instance has been running for some time and one workspace start has occurred.
To inspect the trace of the workspace start:
In the Search panel on the left, filter spans by the operation name (span name), tags, or time and duration.
Figure 7.1. Using Jaeger UI to trace CodeReady Workspaces
Select the trace to expand it and show the tree of nested spans and additional information about the highlighted span, such as tags or durations.
Figure 7.2. Expanded tracing tree
7.6. CodeReady Workspaces tracing codebase overview and extension guide Copy linkLink copied to clipboard!
The core of the tracing implementation for CodeReady Workspaces is in the che-core-tracing-core and che-core-tracing-web modules.
All HTTP requests to the tracing API have their own trace. This is done by TracingFilter from the OpenTracing library, which is bound for the whole server application. Adding a @Traced annotation to methods causes the TracingInterceptor to add tracing spans for them.
7.6.1. Tagging Copy linkLink copied to clipboard!
Spans may contain standard tags, such as operation name, span origin, error, and other tags that may help users with querying and filtering spans. Workspace-related operations (such as starting or stopping workspaces) have additional tags, including userId, workspaceID, and stackId. Spans created by TracingFilter also have an HTTP status code tag.
Declaring tags in a traced method is done statically by setting fields from the TracingTags class:
TracingTags.WORKSPACE_ID.set(workspace.getId());
TracingTags.WORKSPACE_ID.set(workspace.getId());
TracingTags is a class where all commonly used tags are declared, as respective AnnotationAware tag implementations.
Additional resources
For more information about how to use Jaeger UI, visit Jaeger documentation: Jaeger Getting Started Guide.
Chapter 8. Backup and recovery Copy linkLink copied to clipboard!
Backing up CodeReady Workspaces involves a combination of the following processes that back up different data:
Use the CodeReady Workspaces Operator and a crwctl.
NoteUse the internal backup server to test this process.
Use backups of persistent volumes to back up and restore the source code stored in users' workspaces.
TipWhether or not you implement backups of persistent volumes, advise users to commit and push their changes to avoid losing their work.
- Use backups of the external PostgreSQL database to back up and restore persisting data about the state of CodeReady Workspaces.
8.1. Supported Restic-compatible backup servers Copy linkLink copied to clipboard!
CodeReady Workspaces uses the CodeReady Workspaces Operator and integrated Restic to back up and restore CodeReady Workspaces instances from backup snapshots on a configured backup server. The CodeReady Workspaces Operator automates the creation of a Restic backup repository on the backup server. To back up data, the CodeReady Workspaces Operator gathers the data required for a backup snapshot and uses Restic to create and manage the snapshot. To restore data, the CodeReady Workspaces Operator uses Restic to retrieve and decrypt the snapshot, and then the CodeReady Workspaces Operator applies the retrieved data to perform the recovery.
CodeReady Workspaces can use the following backup servers that are compatible with the integrated Restic:
- SFTP
- See the documentation for the SFTP server solution you plan to use (OpenSSH or a derived commercial product) and the Restic Docs on SFTP.
- Amazon S3
- See the documentation for Amazon S3 (or the chosen S3 API compatible storage) and the Restic Docs on Amazon S3.
- REST
- See the README for Rest Server and the Restic Docs on Rest Server.
For testing the backing up and restoring of CodeReady Workspaces instances, CodeReady Workspaces offers the internal backup server.
8.2. Backing up of CodeReady Workspaces instances to an SFTP backup server Copy linkLink copied to clipboard!
You can send backups of CodeReady Workspaces instances to an SFTP backup server with custom resources or crwctl:
8.2.1. Backing up a CodeReady Workspaces instance to an SFTP backup server by using custom resources Copy linkLink copied to clipboard!
Backing up a CodeReady Workspaces instance to an SFTP backup server by using custom resources requires two custom objects:
- First you create a custom object to configure CodeReady Workspaces to use an SFTP backup server.
- Then you create a custom object to make and send a backup snapshot of a CodeReady Workspaces instance to the configured SFTP backup server.
8.2.1.1. Configuring CodeReady Workspaces with custom resources to use an SFTP backup server Copy linkLink copied to clipboard!
To configure CodeReady Workspaces to use an SFTP backup server:
Prerequisites
- Configured SFTP backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
Procedure
Create a Secret containing the
repo-passwordkey with a password:Copy to Clipboard Copied! Toggle word wrap Toggle overflow (The CodeReady Workspaces Operator will set up this password for the backup repository that the CodeReady Workspaces Operator will create from this custom object on the backup server.)
WarningThe backup repository password is used to encrypt the backup data. If you lose this password, you will lose the backup data.
-
Create a Secret (for example,
name: ssh-key-secret) containing thessh-privatekeykey with a private SSH key for logging in to the SFTP server without a password. Create the
CheBackupServerConfigurationcustom object:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Must only contain one section (such as
sftp). - 2
- User name on the remote server to log in using the SSH protocol.
- 3
- Remote server hostname.
- 4
- Optional property that specifies the port on which an SFTP server is running. The default value is
22. - 5
- Absolute or relative path on the server where backup snapshots are stored.
- 6
- Secret created in step 1.
- 7
- Secret created in step 2.
-
Optional: To configure multiple backup servers, create a separate
CheBackupServerConfigurationcustom object for each backup server.
The CodeReady Workspaces Operator automatically backs up the CodeReady Workspaces instance before every CodeReady Workspaces update, permitting rollback to previous CodeReady Workspaces version if needed. If you configure only one backup server, that backup server is automatically used for pre-update backups by default. If you configure multiple backup servers, you must add the che.eclipse.org/backup-before-update: true annotation to the custom object of only one of them to specify it as the default backup server for pre-update backups. (If you don’t add this annotation for one of multiple backup servers, or if you add this annotation for multiple backup servers, then the CodeReady Workspaces Operator defaults to using the internal backup server for pre-update backups.)
8.2.1.2. Backing up a CodeReady Workspaces instance to an SFTP backup server by using the CheClusterBackup custom object Copy linkLink copied to clipboard!
You can use a CheClusterBackup custom object to make a backup snapshot of a CodeReady Workspaces instance and to send the snapshot to the configured backup server. To create each and every backup snapshot requires a new CheClusterBackup custom object; that is, editing an already consumed CheClusterBackup custom object, during or after backing up, has no effect.
This procedure does not back up the source code stored in users' workspaces. To back up the source code stored in users' workspaces, see Backups of persistent volumes.
Prerequisites
- Configured backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
-
Created
CheBackupServerConfigurationcustom object. See the previous section of this guide.
Procedure
Create the
CheClusterBackupcustom object, which creates a backup snapshot:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Name of the
CheBackupServerConfigurationcustom object defining what backup server to use. - 2
- Configures the Operator through this custom resource to use the CodeReady Workspaces-managed internal backup server or an administrator-managed external backup server (SFTP, Amazon S3 or S3 API compatible storage, or REST).
TipIf you intend to reuse a
nameforCheClusterBackupcustom objects, first delete any existing custom object with the samename. To delete it on the command line, use oc:oc delete CheClusterBackup <name> -n openshift-workspaces
$ oc delete CheClusterBackup <name> -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Read the
statussection of theCheClusterBackupcustom object to verify the backup process, for example:status: message: 'Backup is in progress. Start time: <timestamp>' stage: Collecting CodeReady Workspaces installation data state: InProgress
status: message: 'Backup is in progress. Start time: <timestamp>'1 stage: Collecting CodeReady Workspaces installation data2 state: InProgress3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow The CodeReady Workspaces instance is backed up in a snapshot when
stateisSucceeded:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2.2. Backing up a CodeReady Workspaces instance to an SFTP backup server by using crwctl Copy linkLink copied to clipboard!
You can use crwctl to make a backup snapshot of a CodeReady Workspaces instance and send the snapshot to a configured SFTP backup server. To do so, enter crwctl with the command-line options or set the environment variables.
8.2.2.1. Backing up a CodeReady Workspaces instance to an SFTP backup server by using crwctl with command-line options Copy linkLink copied to clipboard!
To make a backup snapshot of a CodeReady Workspaces instance and send the snapshot to a configured SFTP backup server, run crwctl with the command-line options.
This procedure does not back up the source code stored in users' workspaces. To back up the source code stored in users' workspaces, see Backups of persistent volumes.
Prerequisites
-
Installed
crwctl. - Configured SFTP backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
Procedure
Enter the
crwctl server:backupcommand with the following arguments:crwctl server:backup \ --repository-url=<repository_url> \ --repository-password=<repository_password> \ --ssh-key-file=<ssh_key_file>
$ crwctl server:backup \ --repository-url=<repository_url> \1 --repository-password=<repository_password> \2 --ssh-key-file=<ssh_key_file>3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Backup repository URL as an argument using the
--repository-urlor-roption. Syntax for the backup repository URL:sftp:<user>@<host>:/<repository_path_on_sftp_server>. An example of a repository path on the SFTP server:/srv/restic-repo. For more details about repository URL syntax, see Restic Documentation. - 2
- Backup repository password as an argument using the
--repository-passwordor-poption. - 3
- Path to a private SSH key file for authenticating on the SFTP server.
TipLast used backup server information is stored in a Secret inside the CodeReady Workspaces cluster. When consistently using the same backup server, you can enter the
--repository-urland--repository-passwordoptions with thecrwctl server:backupcommand just once and omit them onward when enteringcrwctl server:backuporcrwctl server:restore.Verify the output of the entered command. For example:
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
You can back up a CodeReady Workspaces instance by entering the name of a CheBackupServerConfiguration custom object as an argument with the crwctl server:backup command.
Prerequisites
-
Installed
crwctl. - Configured backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
-
Created
CheBackupServerConfigurationcustom object.
Procedure
Run the following command on a command line:
crwctl server:backup \ --backup-server-config-name=<name_of_CheBackupServerConfiguration>
$ crwctl server:backup \ --backup-server-config-name=<name_of_CheBackupServerConfiguration>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- This option points crwctl to a
CheBackupServerConfigurationcustom object. You can find thenameof theCheBackupServerConfigurationcustom object undermetadatain the custom object.
TipLast used backup server information is stored in a Secret inside the CodeReady Workspaces cluster. When consistently using the same backup server, you can enter the
--backup-server-config-nameoption with thecrwctl server:backupcommand just once and omit this option onward when enteringcrwctl server:backup.Verify the output of the entered command. For example:
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2.2.3. Configuring crwctl for an SFTP backup server with environment variables Copy linkLink copied to clipboard!
As an alternative to using command-line options for crwctl server:backup, you can configure crwctl for an SFTP backup server with environment variables. This enables you to run crwctl server:backup without having to enter those options with it.
Prerequisites
-
Installed
crwctl. - Configured SFTP backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
Procedure
Which environment variables you need to set depends on your use case:
If you do not have a
CheBackupServerConfigurationcustom object yet, then you can set the following environment variables:-
BACKUP_REPOSITORY_URLfor the backup repository. -
BACKUP_REPOSITORY_PASSWORDfor the backup repository password. One of the two environment variables for the SSH key (for logging in without a password):
-
SSH_KEY_FILEfor the path to the SSH key file. -
SSH_KEYfor the SSH key.
-
-
If you already have a
CheBackupServerConfigurationcustom object, you can set the following environment variable that will point crwctl to thatCheBackupServerConfigurationcustom object:-
BACKUP_SERVER_CONFIG_NAMEfor thenameof aCheBackupServerConfigurationcustom object to point crwctl to. (You can findnameundermetadatain the custom object.)
-
8.3. Backing up of CodeReady Workspaces instances to Amazon S3 Copy linkLink copied to clipboard!
You can send backups of CodeReady Workspaces instances to Amazon S3 (or S3 API compatible storage) with custom resources or crwctl:
8.3.1. Backing up a CodeReady Workspaces instance to Amazon S3 by using custom resources Copy linkLink copied to clipboard!
Backing up a CodeReady Workspaces instance to Amazon S3 (or S3 API compatible storage) by using custom resources requires two custom objects:
- First you create a custom object to configure CodeReady Workspaces to use Amazon S3.
- Then you create a custom object to make and send a backup snapshot of a CodeReady Workspaces instance to the configured Amazon S3.
8.3.1.1. Configuring CodeReady Workspaces with custom resources to use Amazon S3 Copy linkLink copied to clipboard!
To configure CodeReady Workspaces to use Amazon S3:
Prerequisites
- Configured Amazon S3. See Section 8.1, “Supported Restic-compatible backup servers”.
Procedure
Create a Secret containing the
repo-passwordkey with a password:Copy to Clipboard Copied! Toggle word wrap Toggle overflow (The CodeReady Workspaces Operator will set up this password for the backup repository that the CodeReady Workspaces Operator will create from this custom object on the backup server.)
WarningThe backup repository password is used to encrypt the backup data. If you lose this password, you will lose the backup data.
Create a Secret (for example,
name: aws-user-credentials-secret) containing:-
awsAccessKeyIdkey with the AWS access key ID of the user -
awsSecretAccessKeykey with the AWS secret access key of the user
-
Create the
CheBackupServerConfigurationcustom object:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Must only contain one section (such as
awss3). - 2
- Optional property that specifies the protocol to be used.
httpsis the default value;httpis a permitted value. - 3
- Optional property that specifies the S3 hostname. The default value is
s3.amazonaws.com. - 4
- Optional property that specifies the port on which the backup server is running. The default value is
443. - 5
- Name of the bucket resource that stores the backup snapshots. You must manually create the bucket resource before configuring it here.
- 6
- Secret created in step 1.
- 7
- Secret created in step 2.
-
Optional: To configure multiple backup servers, create a separate
CheBackupServerConfigurationcustom object for each backup server.
The CodeReady Workspaces Operator automatically backs up the CodeReady Workspaces instance before every CodeReady Workspaces update, permitting rollback to previous CodeReady Workspaces version if needed. If you configure only one backup server, that backup server is automatically used for pre-update backups by default. If you configure multiple backup servers, you must add the che.eclipse.org/backup-before-update: true annotation to the custom object of only one of them to specify it as the default backup server for pre-update backups. (If you don’t add this annotation for one of multiple backup servers, or if you add this annotation for multiple backup servers, then the CodeReady Workspaces Operator defaults to using the internal backup server for pre-update backups.)
8.3.1.2. Backing up a CodeReady Workspaces instance to Amazon S3 by using the CheClusterBackup custom object Copy linkLink copied to clipboard!
You can use a CheClusterBackup custom object to make a backup snapshot of a CodeReady Workspaces instance and to send the snapshot to the configured backup server. To create each and every backup snapshot requires a new CheClusterBackup custom object; that is, editing an already consumed CheClusterBackup custom object, during or after backing up, has no effect.
This procedure does not back up the source code stored in users' workspaces. To back up the source code stored in users' workspaces, see Backups of persistent volumes.
Prerequisites
- Configured backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
-
Created
CheBackupServerConfigurationcustom object. See the previous section of this guide.
Procedure
Create the
CheClusterBackupcustom object, which creates a backup snapshot:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Name of the
CheBackupServerConfigurationcustom object defining what backup server to use. - 2
- Configures the Operator through this custom resource to use the CodeReady Workspaces-managed internal backup server or an administrator-managed external backup server (SFTP, Amazon S3 or S3 API compatible storage, or REST).
TipIf you intend to reuse a
nameforCheClusterBackupcustom objects, first delete any existing custom object with the samename. To delete it on the command line, use oc:oc delete CheClusterBackup <name> -n openshift-workspaces
$ oc delete CheClusterBackup <name> -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Read the
statussection of theCheClusterBackupcustom object to verify the backup process, for example:status: message: 'Backup is in progress. Start time: <timestamp>' stage: Collecting CodeReady Workspaces installation data state: InProgress
status: message: 'Backup is in progress. Start time: <timestamp>'1 stage: Collecting CodeReady Workspaces installation data2 state: InProgress3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow The CodeReady Workspaces instance is backed up in a snapshot when
stateisSucceeded:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3.2. Backing up a CodeReady Workspaces instance to Amazon S3 by using crwctl Copy linkLink copied to clipboard!
You can use crwctl to make a backup snapshot of a CodeReady Workspaces instance and send the snapshot to the configured Amazon S3 (or S3 API compatible storage). To do so, enter crwctl with the command-line options or set the environment variables.
8.3.2.1. Backing up a CodeReady Workspaces instance to Amazon S3 by using crwctl with command-line options Copy linkLink copied to clipboard!
To make a backup snapshot of a CodeReady Workspaces instance and send the snapshot to the configured Amazon S3, run crwctl with the command-line options.
This procedure does not back up the source code stored in users' workspaces. To back up the source code stored in users' workspaces, see Backups of persistent volumes.
Prerequisites
-
Installed
crwctl. - Configured Amazon S3. See Section 8.1, “Supported Restic-compatible backup servers”.
Procedure
Enter the
crwctl server:backupcommand with the following arguments:crwctl server:backup \ --repository-url=<repository_url> \ --repository-password=<repository_password> \ --aws-access-key-id=<aws-access-key-id> \ --aws-secret-access-key==<aws-secret-access-key>
$ crwctl server:backup \ --repository-url=<repository_url> \1 --repository-password=<repository_password> \2 --aws-access-key-id=<aws-access-key-id> \3 --aws-secret-access-key==<aws-secret-access-key>4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Backup repository URL as an argument using the
--repository-urlor-roption. Syntax for the backup repository URL:s3:s3.amazonaws.com/<bucket_name>. For more details about repository URL syntax, see Restic Documentation. - 2
- Backup repository password as an argument using the
--repository-passwordor-poption. - 3
- User’s AWS access key ID.
- 4
- User’s AWS secret access key.
TipLast used backup server information is stored in a Secret inside the CodeReady Workspaces cluster. When consistently using the same backup server, you can enter the
--repository-urland--repository-passwordoptions with thecrwctl server:backupcommand just once and omit them onward when enteringcrwctl server:backuporcrwctl server:restore.Verify the output of the entered command. For example:
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3.2.2. Backing up a CodeReady Workspaces instance to Amazon S3 by using crwctl and a CheBackupServerConfiguration custom object Copy linkLink copied to clipboard!
You can back up a CodeReady Workspaces instance by entering the name of a CheBackupServerConfiguration custom object as an argument with the crwctl server:backup command.
Prerequisites
-
Installed
crwctl. - Configured backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
-
Created
CheBackupServerConfigurationcustom object.
Procedure
Run the following command on a command line:
crwctl server:backup \ --backup-server-config-name=<name_of_CheBackupServerConfiguration>
$ crwctl server:backup \ --backup-server-config-name=<name_of_CheBackupServerConfiguration>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- This option points crwctl to a
CheBackupServerConfigurationcustom object. You can find thenameof theCheBackupServerConfigurationcustom object undermetadatain the custom object.
TipLast used backup server information is stored in a Secret inside the CodeReady Workspaces cluster. When consistently using the same backup server, you can enter the
--backup-server-config-nameoption with thecrwctl server:backupcommand just once and omit this option onward when enteringcrwctl server:backup.Verify the output of the entered command. For example:
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3.2.3. Configuring crwctl with environment variables to use Amazon S3 Copy linkLink copied to clipboard!
As an alternative to using command-line options for crwctl server:backup, you can configure crwctl for Amazon S3 with environment variables. This enables you to run crwctl server:backup without having to enter those options with it.
Prerequisites
-
Installed
crwctl. - Configured Amazon S3. See Section 8.1, “Supported Restic-compatible backup servers”.
Procedure
Which environment variables you need to set depends on your use case:
If you do not have a
CheBackupServerConfigurationcustom object yet, then you can set the following environment variables:-
BACKUP_REPOSITORY_URLfor the backup repository. -
BACKUP_REPOSITORY_PASSWORDfor the backup repository password. -
AWS_ACCESS_KEY_IDfor the user’s AWS access key ID. -
AWS_SECRET_ACCESS_KEYfor the user’s AWS secret access key.
-
If you already have a
CheBackupServerConfigurationcustom object, you can set the following environment variable that will point crwctl to thatCheBackupServerConfigurationcustom object:-
BACKUP_SERVER_CONFIG_NAMEfor thenameof aCheBackupServerConfigurationcustom object to point crwctl to. (You can findnameundermetadatain the custom object.)
-
8.4. Backing up of CodeReady Workspaces instances to a REST backup server Copy linkLink copied to clipboard!
You can send backups of CodeReady Workspaces instances to a REST backup server with custom resources or crwctl:
8.4.1. Backing up a CodeReady Workspaces instance to a REST backup server by using custom resources Copy linkLink copied to clipboard!
Backing up a CodeReady Workspaces instance to a REST backup server by using custom resources requires two custom objects:
- First you create a custom object to configure CodeReady Workspaces to use a REST backup server.
- Then you create a custom object to make and send a backup snapshot of a CodeReady Workspaces instance to the configured REST backup server.
8.4.1.1. Configuring CodeReady Workspaces with custom resources to use a REST backup server Copy linkLink copied to clipboard!
To configure CodeReady Workspaces to use a REST backup server:
Prerequisites
- Configured REST backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
Procedure
Create a Secret containing the
repo-passwordkey with a password:Copy to Clipboard Copied! Toggle word wrap Toggle overflow (The CodeReady Workspaces Operator will set up this password for the backup repository that the CodeReady Workspaces Operator will create from this custom object on the backup server.)
WarningThe backup repository password is used to encrypt the backup data. If you lose this password, you will lose the backup data.
Optional: Create a Secret (for example,
name: rest-server-auth-secret) containing theusernameandpasswordkeys for the REST server user credentials.NoteSkip this step if not using the REST server user credentials.
Create the
CheBackupServerConfigurationcustom object:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Must only contain one section (such as
rest). - 2
- Optional property that specifies the protocol to be used:
httpsis the default value;httpis a permitted value. - 3
- Backup server hostname.
- 4
- Optional property that specifies the port on which the backup server is running. The default value is
8000. - 5
- Path on the backup server where the backup snapshots are stored.
- 6
- Secret created in step 1.
- 7
- Optional property that specifies the Secret created in step 2.
-
Optional: To configure multiple backup servers, create a separate
CheBackupServerConfigurationcustom object for each backup server.
The CodeReady Workspaces Operator automatically backs up the CodeReady Workspaces instance before every CodeReady Workspaces update, permitting rollback to previous CodeReady Workspaces version if needed. If you configure only one backup server, that backup server is automatically used for pre-update backups by default. If you configure multiple backup servers, you must add the che.eclipse.org/backup-before-update: true annotation to the custom object of only one of them to specify it as the default backup server for pre-update backups. (If you don’t add this annotation for one of multiple backup servers, or if you add this annotation for multiple backup servers, then the CodeReady Workspaces Operator defaults to using the internal backup server for pre-update backups.)
8.4.1.2. Backing up a CodeReady Workspaces instance to a REST backup server by using the CheClusterBackup custom object Copy linkLink copied to clipboard!
You can use a CheClusterBackup custom object to make a backup snapshot of a CodeReady Workspaces instance and to send the snapshot to the configured backup server. To create each and every backup snapshot requires a new CheClusterBackup custom object; that is, editing an already consumed CheClusterBackup custom object, during or after backing up, has no effect.
This procedure does not back up the source code stored in users' workspaces. To back up the source code stored in users' workspaces, see Backups of persistent volumes.
Prerequisites
- Configured backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
-
Created
CheBackupServerConfigurationcustom object. See the previous section of this guide.
Procedure
Create the
CheClusterBackupcustom object, which creates a backup snapshot:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Name of the
CheBackupServerConfigurationcustom object defining what backup server to use. - 2
- Configures the Operator through this custom resource to use the CodeReady Workspaces-managed internal backup server or an administrator-managed external backup server (SFTP, Amazon S3 or S3 API compatible storage, or REST).
TipIf you intend to reuse a
nameforCheClusterBackupcustom objects, first delete any existing custom object with the samename. To delete it on the command line, use oc:oc delete CheClusterBackup <name> -n openshift-workspaces
$ oc delete CheClusterBackup <name> -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Read the
statussection of theCheClusterBackupcustom object to verify the backup process, for example:status: message: 'Backup is in progress. Start time: <timestamp>' stage: Collecting CodeReady Workspaces installation data state: InProgress
status: message: 'Backup is in progress. Start time: <timestamp>'1 stage: Collecting CodeReady Workspaces installation data2 state: InProgress3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow The CodeReady Workspaces instance is backed up in a snapshot when
stateisSucceeded:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4.2. Backing up a CodeReady Workspaces instance to a REST backup server by using crwctl Copy linkLink copied to clipboard!
You can use crwctl to make a backup snapshot of a CodeReady Workspaces instance and send the snapshot to a configured REST backup server. To do so, enter crwctl with the command-line options or set the environment variables.
8.4.2.1. Backing up a CodeReady Workspaces instance to a REST backup server by using crwctl with command-line options Copy linkLink copied to clipboard!
To make a backup snapshot of a CodeReady Workspaces instance and send the snapshot to a configured REST backup server, run crwctl with the command-line options.
This procedure does not back up the source code stored in users' workspaces. To back up the source code stored in users' workspaces, see Backups of persistent volumes.
Prerequisites
-
Installed
crwctl. - Configured REST backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
Procedure
Enter the
crwctl server:backupcommand with the following arguments:crwctl server:backup \ --repository-url=<repository_url> \ --repository-password=<repository_password> \ --username=<username> \ --password=<password>
$ crwctl server:backup \ --repository-url=<repository_url> \1 --repository-password=<repository_password> \2 --username=<username> \3 --password=<password>4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Backup repository URL as an argument using the
--repository-urlor-roption. Syntax for the backup repository URL:rest:http://<host>:8000/orrest:https://<user>:<password>@<host>:8000/orrest:https://<user>:<password>@<host>:8000/<repository_path_on_rest_server>/. For more details about repository URL syntax, see Restic Documentation. - 2
- Backup repository password as an argument using the
--repository-passwordor-poption. - 3
- When authentication is required, the username for authenticating to the backup REST server as the
--username=<username>argument. - 4
- When authentication is required, the password for authenticating to the backup REST server as the
--password=<password>argument.
TipLast used backup server information is stored in a Secret inside the CodeReady Workspaces cluster. When consistently using the same backup server, you can enter the
--repository-urland--repository-passwordoptions with thecrwctl server:backupcommand just once and omit them onward when enteringcrwctl server:backuporcrwctl server:restore.Verify the output of the entered command. For example:
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
You can back up a CodeReady Workspaces instance by entering the name of a CheBackupServerConfiguration custom object as an argument with the crwctl server:backup command.
Prerequisites
-
Installed
crwctl. - Configured backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
-
Created
CheBackupServerConfigurationcustom object.
Procedure
Run the following command on a command line:
crwctl server:backup \ --backup-server-config-name=<name_of_CheBackupServerConfiguration>
$ crwctl server:backup \ --backup-server-config-name=<name_of_CheBackupServerConfiguration>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- This option points crwctl to a
CheBackupServerConfigurationcustom object. You can find thenameof theCheBackupServerConfigurationcustom object undermetadatain the custom object.
TipLast used backup server information is stored in a Secret inside the CodeReady Workspaces cluster. When consistently using the same backup server, you can enter the
--backup-server-config-nameoption with thecrwctl server:backupcommand just once and omit this option onward when enteringcrwctl server:backup.Verify the output of the entered command. For example:
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4.2.3. Configuring crwctl with environment variables to use a REST backup server Copy linkLink copied to clipboard!
As an alternative to using command-line options for crwctl server:backup, you can configure crwctl for a REST backup server with environment variables. This enables you to run crwctl server:backup without having to enter those options with it.
Prerequisites
-
Installed
crwctl. - Configured REST backup server. See Section 8.1, “Supported Restic-compatible backup servers”.
Procedure
Which environment variables you need to set depends on your use case:
If you do not have a
CheBackupServerConfigurationcustom object yet, then you can set the following environment variables:-
BACKUP_REPOSITORY_URLfor the backup repository. -
BACKUP_REPOSITORY_PASSWORDfor the backup repository password. When authentication to the REST backup server is required:
-
REST_SERVER_USERNAMEfor the username. -
REST_SERVER_PASSWORDfor the password.
-
-
If you already have a
CheBackupServerConfigurationcustom object, you can set the following environment variable that will point crwctl to thatCheBackupServerConfigurationcustom object:-
BACKUP_SERVER_CONFIG_NAMEfor thenameof aCheBackupServerConfigurationcustom object to point crwctl to. (You can findnameundermetadatain the custom object.)
-
8.5. Backing up of CodeReady Workspaces instances to the internal backup server Copy linkLink copied to clipboard!
To create backups for testing purposes, you can use the internal backup server. The internal backup server is a REST backup server that is managed by the CodeReady Workspaces Operator.
The CodeReady Workspaces Operator defaults to using the internal backup server for pre-update backups (to allow the CodeReady Workspaces version rollback) if multiple backup servers are configured and if the che.eclipse.org/backup-before-update: true annotation is added to more than one of the multiple backup servers or is not added to the custom object of any one of the multiple backup servers.
8.5.1. Backing up a CodeReady Workspaces instance to the internal server by using the CheClusterBackup custom object Copy linkLink copied to clipboard!
You can create a custom object to back up a CodeReady Workspaces instance to the internal backup server.
In this case, the CodeReady Workspaces Operator automatically configures the internal backup server and creates a CheBackupServerConfiguration custom object with name: backup-rest-server-configuration.
Configuring a backup server inside the same cluster, for example the internal backup server, is not the best practice because a cluster failure can be one of the scenarios when a backed up CodeReady Workspaces instance needs to be restored.
Procedure
Create the
CheClusterBackupcustom object to send a backup snapshot to the internal backup server:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Configures the custom resource to back up to the internal backup server.
Read the
statussection of theCheClusterBackupobject to verify the backup process:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The version of CodeReady Workspaces from which the backup snapshot was created. This field appears only when
stateisSucceeded. - 2
- Displays the overall state or error message.
- 3
- The ID of the created backup snapshot. This field appears only when
stateisSucceeded. - 4
- Backup process state:
InProgressorSucceededorFailed.
8.5.2. Backing up a CodeReady Workspaces instance to the internal server by using crwctl Copy linkLink copied to clipboard!
You can use crwctl to take a backup snapshot of a CodeReady Workspaces instance and send it to the internal backup server.
In this case, the CodeReady Workspaces Operator automatically configures the internal backup server and creates a CheBackupServerConfiguration custom object with name: backup-rest-server-configuration.
This procedure does not back up the source code stored in users' workspaces. To back up the source code stored in users' workspaces, see Backups of persistent volumes.
Prerequisites
-
Installed
crwctl. - CodeReady Workspaces has not been configured to use a backup server.
Procedure
-
On a command line, enter the
crwctl server:backupcommand with no arguments. Verify the output of the entered command. For example:
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.
... ✔ Scheduling backup...OK ✔ Waiting until backup process finishes...OK Backup snapshot ID: 9f0adce2 Command server:backup has completed successfully in 00:10.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.6. Restoring a CodeReady Workspaces instance from a backup Copy linkLink copied to clipboard!
You can restore a CodeReady Workspaces instance from a backup snapshot by using the CheClusterRestore custom object or crwctl:
8.6.1. Restoring a CodeReady Workspaces instance from a backup by using the CheClusterRestore custom object Copy linkLink copied to clipboard!
You can restore a CodeReady Workspaces instance from a backup snapshot by using custom resources. A new CheClusterRestore custom object is required every time you restore a CodeReady Workspaces instance from a backup snapshot. (So editing an already consumed CheClusterRestore custom object, during or after backing up, has no effect.)
Backup snapshots are bound to a OpenShift cluster. To restore a CodeReady Workspaces instance, you must only use a backup snapshot that was created in the same OpenShift cluster.
Do not use the CheClusterRestore custom object to recover a CodeReady Workspaces instance of an earlier version of CodeReady Workspaces! Use only crwctl to recover a CodeReady Workspaces instance of an earlier version of CodeReady Workspaces; see Section 8.6.2, “Restoring a CodeReady Workspaces instance from a backup by using crwctl”!
Prerequisites
Backup snapshot of a CodeReady Workspaces instance on any of the following:
Procedure
Create the
CheClusterRestorecustom object, which restores a backup:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Name of the
CheBackupServerConfigurationobject that defines what backup server to use. You can find this name asbackupServerConfigRefinspecof theCheClusterBackupcustom object. (You can also find it asnameinmetadataof theCheBackupServerConfigurationcustom object used to take the backup snapshot you are restoring.) - 2
- Optional parameter defining the Snapshot ID to restore from. The default value is the last snapshot in the backup repository on the backup server.
TipTo reuse a
nameforCheClusterRestorecustom objects, first delete any existing custom object with the samename. To delete it on the command line, use oc:oc delete CheClusterRestore <name> -n openshift-workspaces
$ oc delete CheClusterRestore <name> -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Read the
statussection of theCheClusterRestoreobject to monitor the recovery process, for example:status: message: 'Restore is in progress. Start time: <timestamp>' stage: Restoring CodeReady Workspaces related cluster objects state: InProgress
status: message: 'Restore is in progress. Start time: <timestamp>'1 stage: Restoring CodeReady Workspaces related cluster objects2 state: InProgress3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow Check that the CodeReady Workspaces instance has been recovered.
TipIf errors occur in your browser after the recovery, clean up the browser data for the CodeReady Workspaces domain.
-
Delete the
CheClusterRestoreobject.
8.6.2. Restoring a CodeReady Workspaces instance from a backup by using crwctl Copy linkLink copied to clipboard!
Using crwctl, you can restore a CodeReady Workspaces instance from a backup snapshot by using any of the following options (as applicable):
- Section 8.6.2.1, “Restoring a CodeReady Workspaces instance from its latest backup by using crwctl”
- Section 8.6.2.2, “Restoring a CodeReady Workspaces instance from a backup by snapshot ID”
- Section 8.6.2.3, “Restoring a CodeReady Workspaces instance by using crwctl and a CheClusterBackup custom object”
8.6.2.1. Restoring a CodeReady Workspaces instance from its latest backup by using crwctl Copy linkLink copied to clipboard!
To restore the CodeReady Workspaces instance from its latest backup by using crwctl, you can enter latest as the snapshot ID.
Backup snapshots are bound to a OpenShift cluster. To restore a CodeReady Workspaces instance, you must only use a backup snapshot that was created in the same OpenShift cluster.
If the backup snapshot was taken in an earlier version of Che, add the --version=<earlier_version_number> option to the crwctl server:restore command to roll back Che to that earlier version.
Prerequisites
-
Installed
crwctl. Backup snapshot of a CodeReady Workspaces instance on any of the following:
Procedure
Run the
crwctl server:restorecommand with the following arguments:crwctl server:restore \ --snapshot-id=latest \ --repository-url=<repository-url> \ --repository-password=<repository-password>
$ crwctl server:restore \ --snapshot-id=latest \1 --repository-url=<repository-url> \2 --repository-password=<repository-password>3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow TipLast used backup server information is stored in a Secret inside the CodeReady Workspaces cluster. When consistently using the same backup server, you can enter the
--repository-urland--repository-passwordoptions with thecrwctl server:backupcommand just once and omit them onward when enteringcrwctl server:backuporcrwctl server:restore.When prompted in the output, enter
yto confirm:... ✔ Snapshot: ... Asking for restore confirmation: Do you want to proceed? [y/n] ...
... ✔ Snapshot: ... Asking for restore confirmation: Do you want to proceed? [y/n] ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow TipTo skip this question, add the
--batchoption to theserver:restorecommand.Verify the output of the entered command. For example:
... ✔ Scheduling restore...OK ✔ Waiting until restore process finishes...OK Command server:restore has completed successfully in 05:59.
... ✔ Scheduling restore...OK ✔ Waiting until restore process finishes...OK Command server:restore has completed successfully in 05:59.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.6.2.2. Restoring a CodeReady Workspaces instance from a backup by snapshot ID Copy linkLink copied to clipboard!
To restore a CodeReady Workspaces instance from a particular backup snapshot, you can enter the snapshot ID with crwctl.
Backup snapshots are bound to a OpenShift cluster. To restore a CodeReady Workspaces instance, you must only use a backup snapshot that was created in the same OpenShift cluster.
If the backup snapshot was taken in an earlier version of Che, add the --version=<earlier_version_number> option to the crwctl server:restore command to roll back Che to that earlier version.
Prerequisites
-
Installed
crwctl. Backup snapshot of a CodeReady Workspaces instance on any of the following:
Backup snapshot ID, which can be found in:
- Command-line output when creating a backup
-
statusof aCheClusterBackupcustom object - Command-line output of the Restic command that can list snapshots in the backup repository
Procedure
Run the
crwctl server:restorecommand with the backup snapshot ID specified using the--snapshot-id=option:crwctl server:restore \ --snapshot-id=<snapshot-id> \ --repository-url=<repository-url> \ --repository-password=<repository-password>
$ crwctl server:restore \ --snapshot-id=<snapshot-id> \1 --repository-url=<repository-url> \2 --repository-password=<repository-password>3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow TipLast used backup server information is stored in a Secret inside the CodeReady Workspaces cluster. When consistently using the same backup server, you can enter the
--repository-urland--repository-passwordoptions with thecrwctl server:backupcommand just once and omit them onward when enteringcrwctl server:backuporcrwctl server:restore.When prompted in the output, enter
yto confirm:... ✔ Snapshot: ... Asking for restore confirmation: Do you want to proceed? [y/n] ...
... ✔ Snapshot: ... Asking for restore confirmation: Do you want to proceed? [y/n] ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow TipTo skip this question, add the
--batchoption to theserver:restorecommand.Verify the output of the entered command. For example:
... ✔ Scheduling restore...OK ✔ Waiting until restore process finishes...OK Command server:restore has completed successfully in 05:59.
... ✔ Scheduling restore...OK ✔ Waiting until restore process finishes...OK Command server:restore has completed successfully in 05:59.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.6.2.3. Restoring a CodeReady Workspaces instance by using crwctl and a CheClusterBackup custom object Copy linkLink copied to clipboard!
You can restore a CodeReady Workspaces instance by entering the name of the CheClusterBackup custom object as an argument with the crwctl server:restore command.
If the backup snapshot was taken in an earlier version of Che, then crwctl server:restore --backup-cr-name=<name_of_custom_object> rolls back Che to that earlier version, which is specified in the CheClusterBackup custom object.
Prerequisites
-
Installed
crwctl. -
The
CheClusterBackupcustom object that was used to create the backup snapshot. The backup snapshot that was taken using the
CheClusterBackupcustom object and stored on any of the following:
Procedure
Run the following command on a command line:
crwctl server:restore \ --backup-cr-name=<name_of_custom_object>
$ crwctl server:restore \ --backup-cr-name=<name_of_custom_object>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The name of the
CheClusterBackupcustom object.
When prompted in the output, enter
yto confirm:... Asking for restore confirmation: Do you want to proceed? [y/n] ...
... Asking for restore confirmation: Do you want to proceed? [y/n] ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow TipTo skip this question, add the
--batchoption to theserver:restorecommand.Verify the output of the entered command. For example:
... ✔ Scheduling restore...OK ✔ Waiting until restore process finishes...OK Command server:restore has completed successfully in 05:59.
... ✔ Scheduling restore...OK ✔ Waiting until restore process finishes...OK Command server:restore has completed successfully in 05:59.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.7. Backups of persistent volumes Copy linkLink copied to clipboard!
Persistent Volumes (PVs) store workspace data for CodeReady Workspaces similarly to how workspace data are stored for desktop IDEs on a local hard disk drive. PVs must be backed up periodically to prevent data loss. Storage-agnostic tools are available for backing up and restoring OpenShift resources, including PVs.
8.7.1. Velero Copy linkLink copied to clipboard!
An open source tool for backing up OpenShift applications and their PVs is Velero. This tool can perform the following operations:
- Deploy in the cloud or on premises.
- Back up the cluster and restore the backed up data in case of data loss.
- Migrate cluster resources to other clusters.
- Replicate a production cluster to development and testing clusters.
Alternatively, you can use backup solutions that depend on the underlying storage system: for example, solutions specific to Gluster or Ceph.
8.8. Backups of PostgreSQL Copy linkLink copied to clipboard!
The CodeReady Workspaces server uses a PostgreSQL database for persisting data about the state of CodeReady Workspaces. The database contains information about user accounts, workspaces, preferences, and other details.
8.8.1. External PostgreSQL setup Copy linkLink copied to clipboard!
By default, the CodeReady Workspaces Operator creates and manages deployment of the internal PostgreSQL database. However, the CodeReady Workspaces Operator does not support full lifecycle capabilities such as backups and recovery.
A business-critical setup must use an external PostgreSQL database that is configured:
- for High Availability (HA) and Point In Time Recovery (PITR)
- on-premises or using a cloud service such as Amazon Relational Database Service (Amazon RDS)
For example, Amazon RDS enables deployment of production databases in a Multi-Availability Zone configuration for a resilient disaster recovery strategy with daily and on-demand snapshots.
An example configuration is as follows:
| Parameter | Value |
|---|---|
| Instance class | db.t2.small |
| vCPU | 1 |
| RAM | 2 GB |
| Multi-az | true, 2 replicas |
| Engine version | 9.6.11 |
| TLS | enabled |
| Automated backups | enabled (30 days) |
You can make workspace metadata and user information persistent by configuring the external PostgreSQL database and configuring CodeReady Workspaces to use the configured external PostgreSQL database:
Additional resources
8.8.2. Configuring the external PostgreSQL Copy linkLink copied to clipboard!
To make workspace metadata and user information persistent, configure an external PostgreSQL database as follows:
Procedure
Define the values of the following placeholders:
<database-user>- CodeReady Workspaces server database user name
<database-password>- CodeReady Workspaces server database password
<database>- CodeReady Workspaces server database name
Use the following SQL script to create a user and database for the CodeReady Workspaces server to make workspace metadata persistent:
CREATE USER <database-user> WITH PASSWORD '<database-password>' CREATE DATABASE <database> GRANT ALL PRIVILEGES ON DATABASE <database> TO <database-user> ALTER USER <database-user> WITH SUPERUSER
CREATE USER <database-user> WITH PASSWORD '<database-password>' CREATE DATABASE <database> GRANT ALL PRIVILEGES ON DATABASE <database> TO <database-user> ALTER USER <database-user> WITH SUPERUSERCopy to Clipboard Copied! Toggle word wrap Toggle overflow Define the value of the following placeholder:
<identity-database-password>- RH-SSO database password
Use the following SQL script to create a database for the RH-SSO back end to make user information persistent:
CREATE USER keycloak WITH PASSWORD '<identity-database-password>' CREATE DATABASE keycloak GRANT ALL PRIVILEGES ON DATABASE keycloak TO keycloak
CREATE USER keycloak WITH PASSWORD '<identity-database-password>' CREATE DATABASE keycloak GRANT ALL PRIVILEGES ON DATABASE keycloak TO keycloakCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.8.3. Configuring CodeReady Workspaces to work with the external PostgreSQL Copy linkLink copied to clipboard!
To make workspace metadata and user information persistent, you must configure CodeReady Workspaces to work with the configured external PostgreSQL database.
Prerequisites
- Section 8.8.2, “Configuring the external PostgreSQL”
-
Installed
oc
Procedure
Create a project for CodeReady Workspaces:
oc create namespace openshift-workspaces
$ oc create namespace openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a Secret to store CodeReady Workspaces server database credentials:
oc create secret generic <server-database-credentials> \ --from-literal=user=<database-user> \ --from-literal=password=<database-password> \ -n openshift-workspaces
$ oc create secret generic <server-database-credentials> \1 --from-literal=user=<database-user> \2 --from-literal=password=<database-password> \3 -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a Secret to store RH-SSO database credentials:
oc create secret generic <identity-database-credentials> \ --from-literal=password=<identity-database-password> \ -n openshift-workspaces
$ oc create secret generic <identity-database-credentials> \1 --from-literal=password=<identity-database-password> \2 -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deploy Red Hat CodeReady Workspaces by executing the
crwctlcommand and applying a patch. For example:crwctl server:deploy --che-operator-cr-patch-yaml=patch.yaml ...
$ crwctl server:deploy --che-operator-cr-patch-yaml=patch.yaml ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ensure that
patch.yamlcontains the following lines to make the Operator skip the deployment of a database and pass connection details of an existing database to a CodeReady Workspaces server:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 9. Migration from PostgreSQL 9 to PostgreSQL 13 Copy linkLink copied to clipboard!
By the 11th of November, 2021, the PostgreSQL version 9.6 came out of support, and CodeReady Workspaces team recommends that all users undergo migrating to version 13.
Follow the procedure below to migrate to a newer version of PostgreSQL successfully without any data loss.
Prerequisites
-
The
octool is available. - An instance of CodeReady Workspaces running in OpenShift.
Procedure
- Save and push changes back to the Git repositories for all running workspaces of the CodeReady Workspaces instance.
- Stop all workspaces in the CodeReady Workspaces instance.
Scale down the CodeReady Workspaces and RH-SSO deployments:
oc scale deployment codeready --replicas=0 -n openshift-workspaces oc scale deployment keycloak --replicas=0 -n openshift-workspaces
oc scale deployment codeready --replicas=0 -n openshift-workspaces oc scale deployment keycloak --replicas=0 -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Backup available databases:
POSTGRES_POD=$(oc get pods -n openshift-workspaces | grep postgres | awk '{print $1}') CHE_POSTGRES_DB=$(oc get checluster/codeready-workspaces -n openshift-workspaces -o json | jq '.spec.database.chePostgresDb') oc exec -it $POSTGRES_POD -n openshift-workspaces -- bash -c "pg_dump $CHE_POSTGRES_DB > /tmp/che.sql" oc exec -it $POSTGRES_POD -n openshift-workspaces -- bash -c "pg_dump keycloak > /tmp/keycloak.sql"POSTGRES_POD=$(oc get pods -n openshift-workspaces | grep postgres | awk '{print $1}') CHE_POSTGRES_DB=$(oc get checluster/codeready-workspaces -n openshift-workspaces -o json | jq '.spec.database.chePostgresDb') oc exec -it $POSTGRES_POD -n openshift-workspaces -- bash -c "pg_dump $CHE_POSTGRES_DB > /tmp/che.sql" oc exec -it $POSTGRES_POD -n openshift-workspaces -- bash -c "pg_dump keycloak > /tmp/keycloak.sql"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy the obtained backups to a local file system:
oc cp openshift-workspaces/$POSTGRES_POD:/tmp/che.sql che.sql oc cp openshift-workspaces/$POSTGRES_POD:/tmp/keycloak.sql keycloak.sql
oc cp openshift-workspaces/$POSTGRES_POD:/tmp/che.sql che.sql oc cp openshift-workspaces/$POSTGRES_POD:/tmp/keycloak.sql keycloak.sqlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Scale down the PostgreSQL deployment:
oc scale deployment postgres --replicas=0 -n openshift-workspaces
oc scale deployment postgres --replicas=0 -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Delete the corresponding PVC unit to clean up old data:
oc delete pvc postgres-data -n openshift-workspaces
oc delete pvc postgres-data -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow After deleting the PVC from the step above, a new PVC will automatically appear in a few seconds.
Set the version of the new PostgreSQL database to 13.3:
oc patch checluster codeready-workspaces -n openshift-workspaces --type=json -p '[{"op": "replace", "path": "/spec/database/postgresVersion", "value": "13.3"}]'oc patch checluster codeready-workspaces -n openshift-workspaces --type=json -p '[{"op": "replace", "path": "/spec/database/postgresVersion", "value": "13.3"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Scale up the PostgreSQL deployments:
oc scale deployment postgres --replicas=1 -n openshift-workspaces oc wait --for=condition=ready pod -l app.kubernetes.io/component=postgres -n openshift-workspaces --timeout=120s
oc scale deployment postgres --replicas=1 -n openshift-workspaces oc wait --for=condition=ready pod -l app.kubernetes.io/component=postgres -n openshift-workspaces --timeout=120sCopy to Clipboard Copied! Toggle word wrap Toggle overflow Provision a database:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy the backups to the PostgreSQL Pod:
oc cp che.sql openshift-workspaces/$POSTGRES_POD:/tmp/che.sql oc cp keycloak.sql openshift-workspaces/$POSTGRES_POD:/tmp/keycloak.sql
oc cp che.sql openshift-workspaces/$POSTGRES_POD:/tmp/che.sql oc cp keycloak.sql openshift-workspaces/$POSTGRES_POD:/tmp/keycloak.sqlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Restore the database:
oc exec -it $POSTGRES_POD -n openshift-workspaces -- bash -c "psql keycloak < /tmp/keycloak.sql" oc exec -it $POSTGRES_POD -n openshift-workspaces -- bash -c "psql $CHE_POSTGRES_DB < /tmp/che.sql"
oc exec -it $POSTGRES_POD -n openshift-workspaces -- bash -c "psql keycloak < /tmp/keycloak.sql" oc exec -it $POSTGRES_POD -n openshift-workspaces -- bash -c "psql $CHE_POSTGRES_DB < /tmp/che.sql"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Scale up the RH-SSO and CodeReady Workspaces deployments:
oc scale deployment keycloak --replicas=1 -n openshift-workspaces oc wait --for=condition=ready pod -l app.kubernetes.io/component=keycloak -n openshift-workspaces --timeout=120s oc scale deployment codeready --replicas=1 -n openshift-workspaces oc wait --for=condition=ready pod -l app.kubernetes.io/component=codeready -n openshift-workspaces --timeout=120s
oc scale deployment keycloak --replicas=1 -n openshift-workspaces oc wait --for=condition=ready pod -l app.kubernetes.io/component=keycloak -n openshift-workspaces --timeout=120s oc scale deployment codeready --replicas=1 -n openshift-workspaces oc wait --for=condition=ready pod -l app.kubernetes.io/component=codeready -n openshift-workspaces --timeout=120sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 10. Readiness init containers Copy linkLink copied to clipboard!
CodeReady Workspaces Operator installs CodeReady Workspaces and starts its containers in the correct order. If a node with CodeReady Workspaces is restarted and all CodeReady Workspaces containers start simultaneously, some containers may fail because some other component they depend on is not ready. To avoid such failures, the readiness init containers queue the containers for CodeReady Workspaces components to start in the correct order.
The readiness init containers are disabled by default. If you choose to enable them, proceed according to the installation method used to install CodeReady Workspaces:
10.1. Enabling and disabling the readiness init containers for the Operator installer Copy linkLink copied to clipboard!
You can enable and disable the readiness init containers for the CodeReady Workspaces installed by the Operator installer:
10.2. Enabling the readiness init containers for the Operator installer Copy linkLink copied to clipboard!
The readiness init containers are not enabled by default, so to use them you first have to enable them. To enable the readiness init containers for the CodeReady Workspaces installed by the Operator installer:
Prerequisites
- Red Hat CodeReady Workspaces installed by the Operator installer.
Procedure
Find the name of the CodeReady Workspaces Operator Deployment. Usually it is
codeready-workspaces-operator:$ oc get deployments -n openshift-workspaces
$ oc get deployments -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the Deployment as follows: Under
spec.template.spec.containers[0].envof the Operator Deployment, insert the following lines:- name: ADD_COMPONENT_READINESS_INIT_CONTAINERS value: "true"
- name: ADD_COMPONENT_READINESS_INIT_CONTAINERS1 value: "true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ADD_COMPONENT_READINESS_INIT_CONTAINERSis an environment variable.
- Wait while CodeReady Workspaces Operator restarts some components.
Repeat these steps after each CodeReady Workspaces upgrade when a new Operator Deployment is created.
10.3. Disabling the readiness init containers for the Operator installer Copy linkLink copied to clipboard!
To disable the previously enabled readiness init containers for the CodeReady Workspaces installed by the Operator installer:
Prerequisites
- Red Hat CodeReady Workspaces installed by the Operator installer.
Procedure
Find the name of the CodeReady Workspaces Operator Deployment. Usually it is
codeready-workspaces-operator:$ oc get deployments -n openshift-workspaces
$ oc get deployments -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the Deployment as follows: Under
spec.template.spec.containers[0].envof the Operator Deployment, remove the following lines:- name: ADD_COMPONENT_READINESS_INIT_CONTAINERS value: "true"
- name: ADD_COMPONENT_READINESS_INIT_CONTAINERS1 value: "true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ADD_COMPONENT_READINESS_INIT_CONTAINERSis an environment variable.
- Wait while CodeReady Workspaces Operator restarts some components.
10.4. Enabling and disabling the readiness init containers for the OLM installer Copy linkLink copied to clipboard!
You can enable and disable the readiness init containers for the CodeReady Workspaces installed by the OLM installer. (Available through crwctl, the OLM installer uses the Operator Lifecycle Manager to install CodeReady Workspaces.)
10.5. Enabling the readiness init containers for the OLM installer Copy linkLink copied to clipboard!
The readiness init containers are not enabled by default, so to use them you first have to enable them. To enable the readiness init containers for the CodeReady Workspaces installed by the OLM installer:
Prerequisites
- CodeReady Workspaces is installed by the OLM installer.
Procedure
Find the CodeReady Workspaces Operator subscription name:
oc get subscriptions -n openshift-workspaces
$ oc get subscriptions -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Get the CSV (Cluster Service Version) name from the CodeReady Workspaces Operator subscription:
oc get subscription <subscription-name> -n openshift-workspaces -o yaml | grep installedCSV
$ oc get subscription <subscription-name> -n openshift-workspaces -o yaml | grep installedCSVCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
ClusterServiceVersionYAML manifest:oc edit csv <csv-name> -n openshift-workspaces
$ oc edit csv <csv-name> -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Add the following environment variable to the Operator Deployment spec:
- name: ADD_COMPONENT_READINESS_INIT_CONTAINERS value: "true"
- name: ADD_COMPONENT_READINESS_INIT_CONTAINERS value: "true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Wait for the CodeReady Workspaces Operator restart to finish. The restarted Operator will then continue with restarting some of its components.
Repeat these steps after each CodeReady Workspaces upgrade when a new CSV is created by OLM.
10.6. Disabling the readiness init containers for the OLM installer Copy linkLink copied to clipboard!
To disable the previously enabled readiness init containers for the CodeReady Workspaces installed by the OLM installer:
Prerequisites
- CodeReady Workspaces is installed by the OLM installer.
Procedure
Find the CodeReady Workspaces Operator subscription name:
oc get subscriptions -n openshift-workspaces
$ oc get subscriptions -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Get the CSV (Cluster Service Version) name from the CodeReady Workspaces Operator subscription:
oc get subscription <subscription-name> -n openshift-workspaces -o yaml | grep installedCSV
$ oc get subscription <subscription-name> -n openshift-workspaces -o yaml | grep installedCSVCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
ClusterServiceVersionYAML manifest:oc edit csv <csv-name> -n openshift-workspaces
$ oc edit csv <csv-name> -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Remove the following environment variable from the Operator Deployment spec:
- name: ADD_COMPONENT_READINESS_INIT_CONTAINERS value: "true"
- name: ADD_COMPONENT_READINESS_INIT_CONTAINERS value: "true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Wait for the CodeReady Workspaces Operator restart to finish. The restarted Operator will then continue with restarting some of its components.
Chapter 11. Caching images for faster workspace start Copy linkLink copied to clipboard!
To improve the start time performance of CodeReady Workspaces workspaces, use the Image Puller, a CodeReady Workspaces-agnostic component that can be used to pre-pull images for OpenShift clusters. The Image Puller is an additional OpenShift deployment which creates a DaemonSet that can be configured to pre-pull relevant CodeReady Workspaces workspace images on each node. These images would already be available when a CodeReady Workspaces workspace starts, therefore improving the workspace start time.
The Image Puller provides the following parameters for configuration.
| Parameter | Usage | Default |
|---|---|---|
|
| DaemonSets health checks interval in hours |
|
|
| The memory request for each cached image when the puller is running. See Section 11.2, “Defining the memory parameters for the Image Puller”. |
|
|
| The memory limit for each cached image when the puller is running. See Section 11.2, “Defining the memory parameters for the Image Puller”. |
|
|
| The processor request for each cached image when the puller is running |
|
|
| The processor limit for each cached image when the puller is running |
|
|
| Name of DaemonSet to create |
|
|
| Name of the Deployment to create |
|
|
| OpenShift project containing DaemonSet to create |
|
|
|
Semicolon separated list of images to pull, in the format | |
|
| Node selector to apply to the Pods created by the DaemonSet |
|
|
| Affinity applied to pods created by the DaemonSet |
|
|
|
List of image pull secrets, in the format |
|
Additional resources
- Section 11.1, “Defining the list of images to pull”
- Section 11.2, “Defining the memory parameters for the Image Puller”.
- Section 11.3, “Installing Image Puller using the CodeReady Workspaces Operator”
- Section 11.4, “Installing Image Puller on OpenShift 4 using OperatorHub”
- Section 11.5, “Installing Image Puller on OpenShift using OpenShift templates”
- Kubernetes Image Puller source code repository
11.1. Defining the list of images to pull Copy linkLink copied to clipboard!
The Image Puller can pre-pull most images, including scratch images such as che-machine-exec. However, images that mount volumes in the Dockerfile, such as traefik, are not supported for pre-pulling on OpenShift 3.11.
Pre-pulling images involved in workspace startup will reduce workspace start times. For example:
- Che-Theia
- broker images
- plug-in sidecar images
Prerequisites
-
The
curltool is available. See curl homepage. -
The
jqtool is available. See jq homepage. -
The
yqtool is available. See yq homepage.
Procedure
Gather a list of relevant container images for the OpenShift platform:
Example 11.1. Getting the list of all images for CodeReady Workspaces 2.15
curl -sSLo- https://raw.githubusercontent.com/redhat-developer/codeready-workspaces-images/crw-2.15-rhel-8/codeready-workspaces-operator-metadata-generated/manifests/codeready-workspaces.csv.yaml \ | yq -r '.spec.relatedImages[]'
$ curl -sSLo- https://raw.githubusercontent.com/redhat-developer/codeready-workspaces-images/crw-2.15-rhel-8/codeready-workspaces-operator-metadata-generated/manifests/codeready-workspaces.csv.yaml \ | yq -r '.spec.relatedImages[]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Retain the images involved on the workspace startup phase:
-
eap -
machineexec -
mongodb -
pluginbroker -
plugin- -
stacks -
theia -
ubi-minimal
-
Exclude from the list the container images not supported by the target platform.
For AMD64 and Intel 64 (x86_64).
Example 11.2. Image list for AMD64 and Intel 64 (x86_64)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow For IBM Z and IBM Power, exclude
dotnet.Example 11.3. Image list for IBM Z and IBM Power: excluding
dotnetCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Determine images from the list for pre-pulling.
For faster workspace startup times, consider pre-pulling the workspace-related images:
-
theia-rhel8 -
theia-endpoint-rhel8 -
pluginbroker-artifacts-rhel8 -
pluginbroker-metadata-rhel8 -
stacks-*-rhel8 plugin-*-rhel8- The list of stacks images: Container images - Stacks
- The list of plug-in images: Container images - Plug-ins
-
Additional resources
11.2. Defining the memory parameters for the Image Puller Copy linkLink copied to clipboard!
Define the memory requests and limits parameters to ensure pulled containers and the platform have enough memory to run.
Prerequisites
Procedure
-
To define the minimal value for
CACHING_MEMORY_REQUESTorCACHING_MEMORY_LIMIT, consider the necessary amount of memory required to run each of the container images to pull. To define the maximal value for
CACHING_MEMORY_REQUESTorCACHING_MEMORY_LIMIT, consider the total memory allocated to the DaemonSet Pods in the cluster:(memory limit) * (number of images) * (number of nodes in the cluster)
(memory limit) * (number of images) * (number of nodes in the cluster)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pulling 5 images on 20 nodes, with a container memory limit of
20Mirequires2000Miof memory.
11.3. Installing Image Puller using the CodeReady Workspaces Operator Copy linkLink copied to clipboard!
This section describes how to use the CodeReady Workspaces Operator to install the Image Puller, which is a community-supported feature in the technology preview state.
Prerequisites
- Section 11.1, “Defining the list of images to pull”
- Section 11.2, “Defining the memory parameters for the Image Puller”
- Operator Lifecycle Manager and OperatorHub are available on the OpenShift instance. OpenShift provides them starting with version 4.2.
- The CodeReady Workspaces Operator is available. See https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#installing-che-on-openshift-4-using-operatorhub.adoc
Procedure
Enable Image Puller in the
CheClusterCustom Resource by setting.spec.imagePuller.enabletotrue:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Configure Image Puller in the
CheClusterCustom Resource:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
To use the supported Image Puller, install it separately from the KubernetesImagePuller Operator. Red Hat official build benefits from extra testing and validation provided by Red Hat.
Enabling the use of KubernetesImagePuller in Operator Hub during CodeReady Workspaces installation, sets the Community supported version for use.
Default images
-
The CodeReady Workspaces Operator populates the
.spec.imagePuller.spec.imagesfield with default images used for workspace startup (Theia images, plug-in broker images, sidecar plug-in images), provided that no images were added to this field before creating theCheClusterCustom Resource. The CodeReady Workspaces Operator updates the default images in the.spec.imagePuller.spec.imagesfield after every rollout update of CodeReady Workspaces. However, if images were added to the.spec.imagePuller.spec.imagesfield before creating theCheClusterCustom Resource, the CodeReady Workspaces Operator will not add default images. -
If user-provided images are added to the
.spec.imagePuller.spec.imagesfield after creating theCheClusterCustom Resource, the CodeReady Workspaces Operator will still update default images on subsequent CodeReady Workspaces rollout updates. Non-default images remain unchanged in the.spec.imagePuller.spec.imagesfield after rollout updates.
Verification
-
OpenShift creates a
kubernetes-image-puller-operatorSubscription. The
eclipse-che namespacecontains acommunity supported Kubernetes Image Puller OperatorClusterServiceVersion:oc get clusterserviceversions
$ oc get clusterserviceversionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow The
eclipse-che namespacecontains these deployments:kubernetes-image-pullerandkubernetes-image-puller-operator.oc get deployments
$ oc get deploymentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow The community supported Kubernetes Image Puller Operator creates a
KubernetesImagePullerCustom Resource:oc get kubernetesimagepullers
$ oc get kubernetesimagepullersCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Uninstalling Image Puller using CodeReady Workspaces Operator
-
Edit the
CheClusterCustom Resource and set.spec.imagePuller.enabletofalse. -
Edit the
CheClusterCustom Resource and set the.spec.imagePuller.specto configure the optional Image Puller parameters for the CodeReady Workspaces Operator.
11.4. Installing Image Puller on OpenShift 4 using OperatorHub Copy linkLink copied to clipboard!
This procedure describes how to install the community supported Kubernetes Image Puller Operator on OpenShift 4 using the Operator.
Prerequisites
- An administrator account on a running instance of OpenShift 4.
- Section 11.1, “Defining the list of images to pull”
- Section 11.2, “Defining the memory parameters for the Image Puller”.
Procedure
- To create an OpenShift project <kubernetes-image-puller> to host the Image Puller, open the OpenShift web console, navigate to the Home → Projects section and click .
Specify the project details:
- Name: <kubernetes-image-puller>
- Display Name: <Image Puller>
- Description: <Kubernetes Image Puller>
- Navigate to → .
-
Use the box to search for
community supported Kubernetes Image Puller Operator. Click the . - Read the description of the Operator. Click → .
- Select for the . In the drop-down find the OpenShift project <kubernetes-image-puller>. Click .
- Wait for the community supported Kubernetes Image Puller Operator to install. Click the → .
-
In a redirected window with a YAML editor, make modifications to the
KubernetesImagePullerCustom Resource and click . - Navigate to the and menu in the <kubernetes-image-puller> OpenShift project. Verify that the Image Puller is available.
11.5. Installing Image Puller on OpenShift using OpenShift templates Copy linkLink copied to clipboard!
This procedure describes how to install the Kubernetes Image Puller on OpenShift using OpenShift templates.
Prerequisites
- A running OpenShift cluster.
-
The
octool is available. - Section 11.1, “Defining the list of images to pull”.
- Section 11.2, “Defining the memory parameters for the Image Puller”.
Procedure
Clone the Image Puller repository and get in the directory containing the OpenShift templates:
git clone https://github.com/che-incubator/kubernetes-image-puller cd kubernetes-image-puller/deploy/openshift
$ git clone https://github.com/che-incubator/kubernetes-image-puller $ cd kubernetes-image-puller/deploy/openshiftCopy to Clipboard Copied! Toggle word wrap Toggle overflow Configure the
app.yaml,configmap.yamlandserviceaccount.yamlOpenShift templates using following parameters:Expand Table 11.2. Image Puller OpenShift templates parameters in app.yaml Value Usage Default DEPLOYMENT_NAMEThe value of
DEPLOYMENT_NAMEin the ConfigMapkubernetes-image-pullerIMAGEImage used for the
kubernetes-image-pullerdeploymentregistry.redhat.io/codeready-workspaces/imagepuller-rhel8:2.15IMAGE_TAGThe image tag to pull
latestSERVICEACCOUNT_NAMEThe name of the ServiceAccount created and used by the deployment
kubernetes-image-pullerExpand Table 11.3. Image Puller OpenShift templates parameters in configmap.yaml Value Usage Default CACHING_CPU_LIMITThe value of
CACHING_CPU_LIMITin the ConfigMap.2CACHING_CPU_REQUESTThe value of
CACHING_CPU_REQUESTin the ConfigMap.05CACHING_INTERVAL_HOURSThe value of
CACHING_INTERVAL_HOURSin the ConfigMap"1"CACHING_MEMORY_LIMITThe value of
CACHING_MEMORY_LIMITin the ConfigMap"20Mi"CACHING_MEMORY_REQUESTThe value of
CACHING_MEMORY_REQUESTin the ConfigMap"10Mi"DAEMONSET_NAMEThe value of
DAEMONSET_NAMEin the ConfigMapkubernetes-image-pullerDEPLOYMENT_NAMEThe value of
DEPLOYMENT_NAMEin the ConfigMapkubernetes-image-pullerIMAGESThe value of
IMAGESin the ConfigMap'che_workspace_plugin_broker_artifacts=registry.redhat.io/codeready-workspaces/pluginbroker-artifacts-rhel8@sha256:6d13003539fcbda201065eae2e66dc67fed007ba3ba41fb3b8ec841650c52bc2;che_workspace_plugin_broker_metadata=registry.redhat.io/codeready-workspaces/pluginbroker-metadata-rhel8@sha256:de8ede01ce5d3b06ae8b1866bb482bb937f020f7dee5dfb20b041f02c1e63f68;codeready_workspaces_machineexec_plugin_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/machineexec-rhel8@sha256:dc0e082c9522158cb12345b1d184c3803d8a4a63a7189940e853e51557e43acf;codeready_workspaces_plugin_java11_devfile_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/plugin-java11-rhel8@sha256:315273182e1f4dc884365fc3330ada3937b40369f3faf7762847ec433c3ac537;codeready_workspaces_plugin_java11_plugin_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/plugin-java11-rhel8@sha256:315273182e1f4dc884365fc3330ada3937b40369f3faf7762847ec433c3ac537;codeready_workspaces_plugin_java8_devfile_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/plugin-java8-rhel8@sha256:8cb1e495825051b83cf903bb317e55823a6f57b3bad92e9407dc8fa59c24c0cc;codeready_workspaces_plugin_java8_plugin_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/plugin-java8-rhel8@sha256:8cb1e495825051b83cf903bb317e55823a6f57b3bad92e9407dc8fa59c24c0cc;codeready_workspaces_plugin_kubernetes_plugin_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/plugin-kubernetes-rhel8@sha256:75fe8823dea867489b68169b764dc8b0b03290a456e9bfec5fe0cc413eec7355;codeready_workspaces_plugin_openshift_plugin_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/plugin-openshift-rhel8@sha256:d7603582f7ace76283641809b0c61dbcb78621735e536b789428e5a910d35af3;codeready_workspaces_stacks_cpp_devfile_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/stacks-cpp-rhel8@sha256:c2f38140f52112b2a7688c2a179afcaa930ad6216925eb322cfd9634a71cfc13;codeready_workspaces_stacks_cpp_plugin_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/stacks-cpp-rhel8@sha256:c2f38140f52112b2a7688c2a179afcaa930ad6216925eb322cfd9634a71cfc13;codeready_workspaces_stacks_dotnet_devfile_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/stacks-dotnet-rhel8@sha256:f48fe1caa5be1ae91140681bee159ca8b11dc687fa50fbf9dc5644f4852bf5c8;codeready_workspaces_stacks_dotnet_plugin_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/stacks-dotnet-rhel8@sha256:f48fe1caa5be1ae91140681bee159ca8b11dc687fa50fbf9dc5644f4852bf5c8;codeready_workspaces_stacks_golang_devfile_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/stacks-golang-rhel8@sha256:db76d04752973223e2c0de9401ebf06b84263e1bb6d29f1455daaff0cb39c1b3;codeready_workspaces_stacks_golang_plugin_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/stacks-golang-rhel8@sha256:db76d04752973223e2c0de9401ebf06b84263e1bb6d29f1455daaff0cb39c1b3;codeready_workspaces_stacks_php_devfile_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/stacks-php-rhel8@sha256:d120c41ee8dd80fb960dd4c1657bede536d32f13f3c3ca84e986a830ec2ead3b;codeready_workspaces_stacks_php_plugin_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/stacks-php-rhel8@sha256:d120c41ee8dd80fb960dd4c1657bede536d32f13f3c3ca84e986a830ec2ead3b;codeready_workspaces_theia_endpoint_plugin_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/theia-endpoint-rhel8@sha256:5d26cf000924716d8d03969121a4c636e7fc8ef08aa21148eafa28a2c4aeaff7;codeready_workspaces_theia_plugin_registry_image_gixdcnik=registry.redhat.io/codeready-workspaces/theia-rhel8@sha256:6000d00ef1029583642c01fec588f92addb95f16d56d0c23991a8f19314b0f06;jboss_eap_7_eap74_openjdk8_openshift_rhel7_devfile_registry_image_g4xdilrqbi______=registry.redhat.io/jboss-eap-7/eap74-openjdk8-openshift-rhel7@sha256:b4a113c4d4972d142a3c350e2006a2b297dc883f8ddb29a88db19c892358632d;jboss_eap_7_eap_xp3_openjdk11_openshift_devfile_registry_image_gmxdacq_=registry.redhat.io/jboss-eap-7/eap-xp3-openjdk11-openshift-rhel8@sha256:bb3072afdbf31ddd1071fea37ed5308db3bf8a2478b5aa5aff8373e8042d6aeb;pvc_jobs=registry.redhat.io/ubi8/ubi-minimal@sha256:2e4bbb2be6e7aff711ddc93f0b07e49c93d41e4c2ffc8ea75f804ad6fe25564e;rhscl_mongodb_36_rhel7_devfile_registry_image_gewtkmak=registry.redhat.io/rhscl/mongodb-36-rhel7@sha256:9f799d356d7d2e442bde9d401b720600fd9059a3d8eefea6f3b2ffa721c0dc73;'NAMESPACEThe value of
NAMESPACEin the ConfigMapk8s-image-pullerNODE_SELECTORThe value of
NODE_SELECTORin the ConfigMap"{}"Expand Table 11.4. Image Puller OpenShift templates parameters in serviceaccount.yaml Value Usage Default SERVICEACCOUNT_NAMEThe name of the ServiceAccount created and used by the deployment
kubernetes-image-pullerCreate an OpenShift project to host the Image Puller:
oc new-project <k8s-image-puller>
$ oc new-project <k8s-image-puller>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Process and apply the templates to install the puller:
oc process -f serviceaccount.yaml | oc apply -f - oc process -f configmap.yaml | oc apply -f - oc process -f app.yaml | oc apply -f -
$ oc process -f serviceaccount.yaml | oc apply -f - $ oc process -f configmap.yaml | oc apply -f - $ oc process -f app.yaml | oc apply -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification steps
Verify the existence of a <kubernetes-image-puller> deployment and a <kubernetes-image-puller> DaemonSet. The DaemonSet needs to have a Pod for each node in the cluster:
oc get deployment,daemonset,pod --namespace <k8s-image-puller>
$ oc get deployment,daemonset,pod --namespace <k8s-image-puller>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify the values of the <kubernetes-image-puller>
ConfigMap.oc get configmap <kubernetes-image-puller> --output yaml
$ oc get configmap <kubernetes-image-puller> --output yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 12. Managing identities and authorizations Copy linkLink copied to clipboard!
This section describes different aspects of managing identities and authorizations of Red Hat CodeReady Workspaces.
12.1. Authenticating users Copy linkLink copied to clipboard!
This document covers all aspects of user authentication in Red Hat CodeReady Workspaces, both on the CodeReady Workspaces server and in workspaces. This includes securing all REST API endpoints, WebSocket or JSON RPC connections, and some web resources.
All authentication types use the JWT open standard as a container for transferring user identity information. In addition, CodeReady Workspaces server authentication is based on the OpenID Connect protocol implementation, which is provided by default by RH-SSO.
Authentication in workspaces implies the issuance of self-signed per-workspace JWT tokens and their verification on a dedicated service based on JWTProxy.
12.1.1. Authenticating to the CodeReady Workspaces server Copy linkLink copied to clipboard!
12.1.1.1. Authenticating to the CodeReady Workspaces server using other authentication implementations Copy linkLink copied to clipboard!
This procedure describes how to use an OpenID Connect (OIDC) authentication implementation other than RH-SSO.
Procedure
-
Update the authentication configuration parameters that are stored in the
multiuser.propertiesfile (such as client ID, authentication URL, realm name). -
Write a single filter or a chain of filters to validate tokens, create the user in the CodeReady Workspaces dashboard, and compose the
subjectobject. - If the new authorization provider supports the OpenID protocol, use the OIDC JS client library available at the settings endpoint because it is decoupled from specific implementations.
- If the selected provider stores additional data about the user (first and last name, job title), it is recommended to write a provider-specific ProfileDao implementation that provides this information.
12.1.1.2. Authenticating to the CodeReady Workspaces server using OAuth Copy linkLink copied to clipboard!
For easy user interaction with third-party services, the CodeReady Workspaces server supports OAuth authentication. OAuth tokens are also used for GitHub-related plug-ins.
OAuth authentication has two main flows:
- delegated
- Default. Delegates OAuth authentication to RH-SSO server.
- embedded
- Uses built-in CodeReady Workspaces server mechanism to communicate with OAuth providers.
To switch between the two implementations, use the che.oauth.service_mode=<embedded|delegated> configuration property.
The main REST endpoint in the OAuth API is /api/oauth, which contains:
-
An authentication method,
/authenticate, that the OAuth authentication flow can start with. -
A callback method,
/callback, to process callbacks from the provider. -
A token GET method,
/token, to retrieve the current user’s OAuth token. -
A token DELETE method,
/token, to invalidated the current user’s OAuth token. -
A GET method,
/, to get the list of configured identity providers.
12.1.1.3. Using Swagger or REST clients to execute queries Copy linkLink copied to clipboard!
The user’s RH-SSO token is used to execute queries to the secured API on the user’s behalf through REST clients. A valid token must be attached as the Request header or the ?token=$token query parameter.
Access the CodeReady Workspaces Swagger interface at \https://codeready-<openshift_deployment_name>.<domain_name>/swagger. The user must be signed in through RH-SSO, so that the access token is included in the Request header.
12.1.2. Authenticating in a CodeReady Workspaces workspace Copy linkLink copied to clipboard!
Workspace containers may contain services that must be protected with authentication. Such protected services are called secure. To secure these services, use a machine authentication mechanism.
JWT tokens avoid the need to pass RH-SSO tokens to workspace containers (which can be insecure). Also, RH-SSO tokens may have a relatively shorter lifetime and require periodic renewals or refreshes, which is difficult to manage and keep in sync with the same user session tokens on clients.
Figure 12.1. Authentication inside a workspace
12.1.2.1. Creating secure servers Copy linkLink copied to clipboard!
To create secure servers in CodeReady Workspaces workspaces, set the secure attribute of the endpoint to true in the dockerimage type component in the devfile.
Devfile snippet for a secure server
components:
- type: dockerimage
endpoints:
- attributes:
secure: 'true'
components:
- type: dockerimage
endpoints:
- attributes:
secure: 'true'
12.1.2.2. Workspace JWT token Copy linkLink copied to clipboard!
Workspace tokens are JSON web tokens (JWT) that contain the following information in their claims:
-
uid: The ID of the user who owns this token -
uname: The name of the user who owns this token -
wsid: The ID of a workspace which can be queried with this token
Every user is provided with a unique personal token for each workspace. The structure of a token and the signature are different from what they are in RH-SSO. The following is an example token view:
The SHA-256 cipher with the RSA algorithm is used for signing JWT tokens. It is not configurable. Also, there is no public service that distributes the public part of the key pair with which the token is signed.
12.1.2.3. Machine token validation Copy linkLink copied to clipboard!
The validation of machine tokens (JWT tokens) is performed using a dedicated per-workspace service with JWTProxy running on it in a separate Pod. When the workspace starts, this service receives the public part of the SHA key from the CodeReady Workspaces server. A separate verification endpoint is created for each secure server. When traffic comes to that endpoint, JWTProxy tries to extract the token from the cookies or headers and validates it using the public-key part.
To query the CodeReady Workspaces server, a workspace server can use the machine token provided in the CHE_MACHINE_TOKEN environment variable. This token is the user’s who starts the workspace. The scope of such requests is restricted to the current workspace only. The list of allowed operations is also strictly limited.
12.2. Authorizing users Copy linkLink copied to clipboard!
User authorization in CodeReady Workspaces is based on the permissions model. Permissions are used to control the allowed actions of users and establish a security model. Every request is verified for the presence of the required permission in the current user subject after it passes authentication. You can control resources managed by CodeReady Workspaces and allow certain actions by assigning permissions to users.
Permissions can be applied to the following entities:
- Workspace
- System
All permissions can be managed using the provided REST API. The APIs are documented using Swagger at \https://codeready-<openshift_deployment_name>.<domain_name>/swagger/#!/permissions.
12.2.1. CodeReady Workspaces workspace permissions Copy linkLink copied to clipboard!
The user who creates a workspace is the workspace owner. By default, the workspace owner has the following permissions: read, use, run, configure, setPermissions, and delete. Workspace owners can invite users into the workspace and control workspace permissions for other users.
The following permissions are associated with workspaces:
| Permission | Description |
|---|---|
| read | Allows reading the workspace configuration. |
| use | Allows using a workspace and interacting with it. |
| run | Allows starting and stopping a workspace. |
| configure | Allows defining and changing the workspace configuration. |
| setPermissions | Allows updating the workspace permissions for other users. |
| delete | Allows deleting the workspace. |
12.2.2. CodeReady Workspaces system permissions Copy linkLink copied to clipboard!
CodeReady Workspaces system permissions control aspects of the whole CodeReady Workspaces installation. The following permissions are applicable to the system:
| Permission | Description |
|---|---|
| manageSystem | Allows control of the system and workspaces. |
| setPermissions | Allows updating the permissions for users on the system. |
| manageUsers | Allows creating and managing users. |
| monitorSystem | Allows accessing endpoints used for monitoring the state of the server. |
All system permissions are granted to the administrative user. To configure the administrative user, use the CHE_SYSTEM_ADMIN__NAME property. The default value is admin. The system permissions are granted when the CodeReady Workspaces server starts. If the record of the user is not in the CodeReady Workspaces user database, the permissions are granted after the first login of the user.
12.2.3. manageSystem permission Copy linkLink copied to clipboard!
Users with the manageSystem permission have access to the following services:
| Path | HTTP Method | Description |
|---|---|---|
|
| GET | Get free resource limits. |
|
| GET | Get free resource limits for the given account. |
|
| POST | Edit free resource limit for the given account. |
|
| DELETE | Remove free resource limit for the given account. |
|
| POST | Add installer to the registry. |
|
| PUT | Update installer in the registry. |
|
| DELETE | Remove installer from the registry. |
|
| GET | Get logging configurations in the CodeReady Workspaces server. |
|
| GET | Get configurations of logger by its name in the CodeReady Workspaces server. |
|
| PUT | Create logger in the CodeReady Workspaces server. |
|
| POST | Edit logger in the CodeReady Workspaces server. |
|
| GET | Get detailed information about resources for the given account. |
|
| POST | Shutdown all system services, prepare CodeReady Workspaces to stop. |
12.2.4. monitorSystem permission Copy linkLink copied to clipboard!
Users with the monitorSystem permission have access to the following services.
| Path | HTTP Method | Description |
|---|---|---|
| /activity | GET | Get workspaces in a certain state for a certain amount of time. |
12.2.5. Listing CodeReady Workspaces permissions Copy linkLink copied to clipboard!
To list CodeReady Workspaces permissions that apply to a specific resource, perform the GET /permissions request.
To list the permissions that apply to a user, perform the GET /permissions/{domain} request.
To list the permissions that apply to all users, perform the GET /permissions/{domain}/all request. The user must have manageSystem permissions to see this information.
The suitable domain values are:
- system
- organization
- workspace
The domain is optional. If no domain is specified, the API returns all possible permissions for all the domains.
12.2.6. Assigning CodeReady Workspaces permissions Copy linkLink copied to clipboard!
To assign permissions to a resource, perform the POST /permissions request. The suitable domain values are:
- system
- organization
- workspace
The following is a message body that requests permissions for a user with a userId to a workspace with a workspaceID:
Requesting CodeReady Workspaces user permissions
12.3. Configuring authorization Copy linkLink copied to clipboard!
CodeReady Workspaces uses the permissions model for user authorization.
12.3.1. Authorization and user management Copy linkLink copied to clipboard!
Red Hat CodeReady Workspaces uses RH-SSO to create, import, manage, delete, and authenticate users. RH-SSO uses built-in authentication mechanisms and user storage. It can use third-party identity management systems to create and authenticate users. Red Hat CodeReady Workspaces requires a RH-SSO token when you request access to CodeReady Workspaces resources.
Local users and imported federation users must have an email address in their profile.
The default RH-SSO credentials are admin:admin. You can use the admin:admin credentials when logging into Red Hat CodeReady Workspaces for the first time. It has system privileges.
Identifying the RH-SSO URL
Go to the OpenShift web console and to the RH-SSO project.
12.3.2. Configuring CodeReady Workspaces to work with RH-SSO Copy linkLink copied to clipboard!
The deployment script configures RH-SSO. It creates a codeready-public client with the following fields:
- Valid Redirect URIs: Use this URL to access CodeReady Workspaces.
- Web Origins
The following are common errors when configuring CodeReady Workspaces to work with RH-SSO:
- Invalid
redirectURIerror -
Occurs when you access CodeReady Workspaces at
myhost, which is an alias, and your originalCHE_HOSTis1.1.1.1. If this error occurs, go to the RH-SSO administration console and ensure that the valid redirect URIs are configured. - CORS error
- Occurs when you have an invalid web origin.
12.3.3. Configuring RH-SSO tokens Copy linkLink copied to clipboard!
A user token expires after 30 minutes by default.
You can change the following RH-SSO token settings:
12.3.4. Setting up user federation Copy linkLink copied to clipboard!
RH-SSO federates external user databases and supports LDAP and Active Directory. You can test the connection and authenticate users before choosing a storage provider.
See the User storage federation page in RH-SSO documentation to learn how to add a provider.
See the LDAP and Active Directory page in RH-SSO documentation to specify multiple LDAP servers.
12.3.5. Enabling authentication with social accounts and brokering Copy linkLink copied to clipboard!
RH-SSO provides built-in support for GitHub, OpenShift, and most common social networks such as Facebook and Twitter. See RH-SSO documentation to learn how to enable Login with GitHub.
12.3.5.1. Configuring GitHub OAuth Copy linkLink copied to clipboard!
OAuth for GitHub allows for automatic SSH key upload to GitHub.
Prerequisites
-
The
octool is available.
Procedure
Create an OAuth application in GitHub with the following URLs:
-
Enter the CodeReady Workspaces URL as
Homepage URL. The default value ishttps://codeready-openshift-workspaces.<domain>/. Enter the
Authorization callback URLas follows:-
If the Dev Workspace engine is not enabled, enter the RH-SSO GitHub endpoint URL as
Authorization callback URL. The default value ishttps://keycloak-openshift-workspaces.<domain>/auth/realms/codeready/broker/github/endpoint. -
If the Dev Workspace engine is enabled, enter the CodeReady Workspaces OAuth callback URL as
Authorization callback URL. The default value ishttps://codeready-openshift-workspaces.<domain>/api/oauth/callback.
-
If the Dev Workspace engine is not enabled, enter the RH-SSO GitHub endpoint URL as
-
Enter the CodeReady Workspaces URL as
Create a new secret in the project where CodeReady Workspaces is deployed.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - If CodeReady Workspaces was already installed wait until rollout of RH-SSO component finishes.
12.3.5.2. Configuring a Bitbucket server that uses self-signed TLS certificates Copy linkLink copied to clipboard!
The following chapter describes how to configure a Bitbucket (BB) server that uses self-signed TLS certificates so that the CodeReady Workspaces server and workspace components can establish a trusted connection with BB.
Creating ConfigMaps for additional TLS and
gitSelfSigncertificates. This enables:- Launching a factory using a devfile URL.
- Importing and cloning a project.
- Configure the OAuth 1 authentication on the BB server side. For more information, see Configuring Bitbucket Server OAuth 1
- Creating a ConfigMap for importing additional certificates is necessary only if a BB server is setup with self-signed TLS certificates. These certificates are needed for the proper functionality of CodeReady Workspaces server and tools inside of a workspace, which use them for performing Git operations related to a specific repository.
Prerequisites
-
A value of the BB server certification authority (CA) exported in the Base64 ASCII format and stored in a
ca.crtfile. - An instance of CodeReady Workspaces.
Procedure
Provision the CA of the BB server to the CodeReady Workspaces server to enable it to read the devfiles stored in the BB server. To do so, add the following ConfigMap to the
openshift-workspacesproject:oc create configmap bitbucket-ca-cert-for-factory --from-file=ca.crt -n openshift-workspaces
$ oc create configmap bitbucket-ca-cert-for-factory --from-file=ca.crt -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc label configmap bitbucket-ca-cert-for-factory app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=ca-bundle -n openshift-workspaces
$ oc label configmap bitbucket-ca-cert-for-factory app.kubernetes.io/part-of=che.eclipse.org app.kubernetes.io/component=ca-bundle -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Provision the CA of the BB server to the CodeReady Workspaces server to be able to use Git operations. To do so, add a new ConfigMap to the
openshift-workspacesproject:oc create configmap che-git-self-signed-cert --from-file=ca.crt --from-literal=githost=<bitbucket_server_url> -n openshift-workspaces
$ oc create configmap che-git-self-signed-cert --from-file=ca.crt --from-literal=githost=<bitbucket_server_url> -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the CheCluster Custom Resource (CR) to configure the CodeReady Workspaces server.
spec: server: # … gitSelfSignedCert: <boolean>spec: server: # … gitSelfSignedCert: <boolean>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Use
truefor a BB server that use a self-signed cert. Default value:false.
Reference
- For adding a Bitbucket CA certificate into CodeReady Workspaces, see https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#importing-untrusted-tls-certificates.adoc.
12.3.5.3. Configuring the Bitbucket and CodeReady Workspaces integration to use OAuth1 Copy linkLink copied to clipboard!
The following section describes the configuration of the OAuth 1 authentication that is needed for performing read and write operations with Bitbucket (BB) repositories. To use BB repositories with allowed Git operations, such as clone and push, register a BB endpoint with CodeReady Workspaces first, and configure the OAuth 1 authentication.
This procedure requires:
- generating RSA key pairs
- generating a consumer key-secret pair
- creating an application link on the BB side
- configuring BB on the CodeReady Workspaces-server side
This procedure also describes how to activate OAuth 1 for Bitbucket Server to:
- Use devfiles hosted on a Bitbucket Server.
- Enable CodeReady Workspaces to obtain and renew Bitbucket Server Personal access tokens.
Prerequisites
-
The
octool is available. - Bitbucket Server is available from CodeReady Workspaces server.
- An instance of CodeReady Workspaces.
Procedure
Generate an RSA key pair and a stripped-down version of the public key:
openssl genrsa -out <private.pem> 2048
$ openssl genrsa -out <private.pem> 2048Copy to Clipboard Copied! Toggle word wrap Toggle overflow openssl rsa -in <private.pem> -pubout > <public.pub>
$ openssl rsa -in <private.pem> -pubout > <public.pub>Copy to Clipboard Copied! Toggle word wrap Toggle overflow openssl pkcs8 -topk8 -inform pem -outform pem -nocrypt -in <private.pem> -out <privatepkcs8.pem>
$ openssl pkcs8 -topk8 -inform pem -outform pem -nocrypt -in <private.pem> -out <privatepkcs8.pem>Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat <public.pub> | sed 's/-----BEGIN PUBLIC KEY-----//g' | sed 's/-----END PUBLIC KEY-----//g' | tr -d '\n' > <public-stripped.pub>
$ cat <public.pub> | sed 's/-----BEGIN PUBLIC KEY-----//g' | sed 's/-----END PUBLIC KEY-----//g' | tr -d '\n' > <public-stripped.pub>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Generate a consumer key and a shared secret.
openssl rand -base64 24 > <bitbucket_server_consumer_key>
$ openssl rand -base64 24 > <bitbucket_server_consumer_key>Copy to Clipboard Copied! Toggle word wrap Toggle overflow openssl rand -base64 24 > <bitbucket_shared_secret>
$ openssl rand -base64 24 > <bitbucket_shared_secret>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Configure an Application Link in Bitbucket to enable the communication from CodeReady Workspaces to Bitbucket Server.
- In Bitbucket Server, click the cog in the top navigation bar to navigate to Administration > Application Links.
-
Enter the application URL:
\https://codeready-<openshift_deployment_name>.<domain_name>and click the button. -
In the warning message stating
No response was received from the URLclick the button. Complete the Link Applications form and click the button.
- Application Name
-
<CodeReady Workspaces> - Application Type
- Generic Application.
- Service Provider Name
-
<CodeReady Workspaces> - Consumer Key
-
Paste the content of the
<bitbucket_server_consumer_key>file. - Shared secret
-
Paste the content of the
<bitbucket_shared_secret>file. - Request Token URL
-
<Bitbucket Server URL>/plugins/servlet/oauth/request-token - Access token URL
-
<Bitbucket Server URL>/plugins/servlet/oauth/access-token - Authorize URL
-
<Bitbucket Server URL>/plugins/servlet/oauth/access-token - Create incoming link
- Enabled.
Complete the Link Applications form and click the button.
- Consumer Key
-
Paste the content of the
<bitbucket_server_consumer_key>file. - Consumer name
-
<CodeReady Workspaces> - Public Key
-
Paste the content of the
<public-stripped.pub>file.
Create a OpenShift Secret in CodeReady Workspaces project containing the consumer and private keys.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - See the whole script in this GitHub example.
Additional resources
- Bitbucket Server overview
- Download Bitbucket Server
- Bitbucket Server Personal access tokens
- How to generate public key to application link 3rd party applications
- Using AppLinks to link to other applications
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/end-user_guide/index#authenticating-on-scm-server-with-a-personal-access-token.adoc.
12.3.5.4. Configuring GitLab servers Copy linkLink copied to clipboard!
To use a GitLab server as a project sources supplier, register the GitLab server URL with CodeReady Workspaces using the CHE_INTEGRATION_GITLAB_SERVER__ENDPOINTS property and specify the hostname of the server to register.
Example
https://gitlab.apps.cluster-2ab2.2ab2.example.opentlc.com/
https://gitlab.apps.cluster-2ab2.2ab2.example.opentlc.com/
For additional examples of configuring GitLab servers see Understanding CodeReady Workspaces server advanced configuration using the Operator
12.3.5.5. Configuring GitLab OAuth2 with the codeready-server engine Copy linkLink copied to clipboard!
OAuth2 for GitLab allows accepting factories from private GitLab repositories.
Prerequisites
- The GitLab server is running and available from CodeReady Workspaces.
Procedure
Create a Authorized OAuth2 application in GitLab using CodeReady Workspaces as the application
Nameand RH-SSO GitLab endpoint URL as the value forRedirect URI. The callback URL default value ishttps://keycloak-openshift-workspaces.<DOMAIN>/auth/realms/codeready/broker/gitlab/endpoint, where<DOMAIN>is OpenShift cluster domain. Store theApplication IDandSecretvalues. All three types of GitLab OAuth 2 applications are supported: User owned, Group owned and Instance-wide.Create a custom OIDC provider link on RH-SSO pointing to GitLab server. Fill the following fields:
- Client ID
-
a value from the
Application IDfield provided by GitLab server in previous step; - Client Secret
-
a value from
Secretfield provided by GitLab server in previous step; - Authorization URL
-
a URL which have a
https://<GITLAB_DOMAIN>/oauth/authorizeformat; - Token URL
-
a URL which have a
https://<GITLAB_DOMAIN>/oauth/tokenformat; - Scopes
-
set of scopes which must contain (but not limited to) the following set:
api write_repository openid; - Store Tokens
- needs to be enabled;
- Store Tokens Readable
- needs to be enabled
Note-
Substitute
<GITLAB_DOMAIN>with the URL and port of the GitLab installation.
Register the GitLab instance URL with the enabled OAuth 2 support in CodeReady Workspaces using the
CHE_INTEGRATION_GITLAB_OAUTH__ENDPOINTproperty.Warning-
The GitLab instance URL must be present in the list of configured GitLab integration endpoints, set by the
CHE_INTEGRATION_GITLAB_SERVER__ENDPOINTSproperty.
-
The GitLab instance URL must be present in the list of configured GitLab integration endpoints, set by the
Additional resources
In case of having issues CodeReady Workspaces accessing GitLab related to TLS keys, consult with the following docs:
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#importing-untrusted-tls-certificates.adoc.
- https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#deploying-che-with-support-for-git-repositories-with-self-signed-certificates.adoc.
12.3.5.6. Configuring GitLab OAuth2 with the Dev Workspace engine Copy linkLink copied to clipboard!
Prerequisites
- The GitLab server is running and available from CodeReady Workspaces.
Procedure
Create an OAuth2 Authorized application in Gitlab:
-
Enter Che as the application
Name. -
Enter the CodeReady Workspaces OAuth callback URL as the
Redirect URI. The default value ishttps://codeready-openshift-workspaces.<domain>/api/oauth/callback. -
Check the
ConfidentialandExpire access tokenscheckboxes. -
Under Scopes, check the
api,write_repository, andopenidcheckboxes.
-
Enter Che as the application
-
Click
Save applicationand store theApplication IDandSecretvalues. Create a new secret in the project where CodeReady Workspaces is deployed.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The CodeReady Workspaces namespace. The default is openshift-workspaces.
Additional resources
12.3.6. Using protocol-based providers Copy linkLink copied to clipboard!
RH-SSO supports SAML v2.0 and OpenID Connect v1.0 protocols.
12.3.7. Managing users using RH-SSO Copy linkLink copied to clipboard!
You can add, delete, and edit users in the user interface. See RH-SSO User Management for more information.
12.3.8. Configuring CodeReady Workspaces to use an external RH-SSO installation Copy linkLink copied to clipboard!
By default, CodeReady Workspaces installation includes the deployment of a dedicated RH-SSO instance. However, using an external RH-SSO is also possible. This option is useful when a user has an existing RH-SSO instance with already-defined users, for example, a company-wide RH-SSO server used by several applications.
|
| RH-SSO realm name intended for use by CodeReady Workspaces |
|
|
Name of the |
|
| Base URL of the external RH-SSO server |
Prerequisites
In the administration console of the external installation of RH-SSO, define a realm that contains the users to connect to CodeReady Workspaces:
In this
realm, define an OIDC client that CodeReady Workspaces will use to authenticate the users. This is an example of such a client with the correct settings:Note-
Client Protocol must be
openid-connect. -
Access Type must be
public. CodeReady Workspaces only supports thepublicaccess type. -
Valid Redirect URIs must contain at least two URIs related to the CodeReady Workspaces server, one using the
httpprotocol and the otherhttps. These URIs must contain the base URL of the CodeReady Workspaces server, followed by/*wildcards. Web Origins must contain at least two URIs related to the CodeReady Workspaces server, one using the
httpprotocol and the otherhttps. These URIs must contain the base URL of the CodeReady Workspaces server, without any path after the host.The number of URIs depends on the number of installed product tools.
-
Client Protocol must be
With CodeReady Workspaces that uses the default OpenShift OAuth support, user authentication relies on the integration of RH-SSO with OpenShift OAuth. This allows users to log in to CodeReady Workspaces with their OpenShift login and have their workspaces created under personal OpenShift projects.
This requires setting up an OpenShift "RH-SSO Identity Provider". When using an external RH-SSO, configure the RH-SSO manually. For instructions, see the appropriate RH-SSO documentations for either OpenShift 3 or OpenShift 4.
- The configured RH-SSO has the options Store Tokens and Stored Tokens Readable enabled.
Procedure
Set the following properties in the
CheClusterCustom Resource (CR):Copy to Clipboard Copied! Toggle word wrap Toggle overflow When installing CodeReady Workspaces with OpenShift OAuth support enabled, set the following properties in the
CheClusterCustom Resource (CR):Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.3.9. Configuring SMTP and email notifications Copy linkLink copied to clipboard!
Red Hat CodeReady Workspaces does not provide any pre-configured MTP servers.
To enable SMTP servers in RH-SSO:
-
Go to
che realm settings > Email. - Specify the host, port, username, and password.
Red Hat CodeReady Workspaces uses the default theme for email templates for registration, email confirmation, password recovery, and failed login.
12.3.10. Enabling self-registration Copy linkLink copied to clipboard!
Self-registration allows users to register themselves in a CodeReady Workspaces instance by accessing the CodeReady Workspaces server URL.
For CodeReady Workspaces installed without OpenShift OAuth support, self-registration is disabled by default, therefore the option to register a new user is not available on the login page.
Prerequisites
- You are logged in as an administrator.
Procedure
To enable self-registration of users:
- Navigate to the Realm Settings menu on the left and open the Login tab.
- Set User registration option to On.
12.4. Configuring OpenShift OAuth Copy linkLink copied to clipboard!
For users to interact with OpenShift, they must first authenticate to the OpenShift cluster. OpenShift OAuth is a process in which users prove themselves to a cluster through an API with obtained OAuth access tokens.
Authentication with the https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/end-user_guide/index#openshift-connector-overview.adoc is a possible way for CodeReady Workspaces users to authenticate with an OpenShift cluster.
The following section describes the OpenShift OAuth configuration options and its use with a CodeReady Workspaces.
12.4.1. Configuring OpenShift OAuth with initial user Copy linkLink copied to clipboard!
Prerequisites
-
The
octool is available. -
crwctlmanagement tool is available. See https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#using-the-chectl-management-tool.adoc.
Procedure
Configure OpenShift identity providers on the cluster. See the Understanding identity provider configuration.
When a user skips the Configuring step of OpenShift "RH-SSO Identity Provider", and the OpenShift cluster does not already contain a configured RH-SSO, CodeReady Workspaces creates an initial OpenShift user for the
HTPasswdidentity provider. Credentials of this user are stored in theopenshift-oauth-user-credentialssecret, located in theopenshift-confignamespace.Obtain the credentials for logging in to an OpenShift cluster and CodeReady Workspaces instance:
Obtain OpenShift user name:
oc get secret openshift-oauth-user-credentials -n openshift-config -o json | jq -r '.data.user' | base64 -d
$ oc get secret openshift-oauth-user-credentials -n openshift-config -o json | jq -r '.data.user' | base64 -dCopy to Clipboard Copied! Toggle word wrap Toggle overflow Obtain OpenShift user password:
oc get secret openshift-oauth-user-credentials -n openshift-config -o json | jq -r '.data.password' | base64 -d
$ oc get secret openshift-oauth-user-credentials -n openshift-config -o json | jq -r '.data.password' | base64 -dCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Deploy CodeReady Workspaces using OperatorHub or the crwctl, see the
crwctl server:deployspecification chapter. OpenShift OAuth will be enabled by default.
12.4.2. Configuring OpenShift OAuth without provisioning OpenShift initial OAuth user Copy linkLink copied to clipboard!
The following procedure describes how to configure OpenShift OAuth without provisioning the initial OAuth user.
Prerequisites
-
crwctlmanagement tool is available. See https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#using-the-chectl-management-tool.adoc.
Procedure
If you have installed CodeReady Workspaces by using the Operator, configure the following values in the codeready-workspaces Custom Resource:
spec: auth: openShiftoAuth: true initialOpenShiftOAuthUser: ''spec: auth: openShiftoAuth: true initialOpenShiftOAuthUser: ''Copy to Clipboard Copied! Toggle word wrap Toggle overflow If you have installed CodeReady Workspaces by using the
crwctltool, use the--che-operator-cr-patch-yamlflag:crwctl server:deploy --che-operator-cr-patch-yaml=patch.yaml ...
$ crwctl server:deploy --che-operator-cr-patch-yaml=patch.yaml ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
patch.yamlfile must contain the following:spec: auth: openShiftoAuth: true initialOpenShiftOAuthUser: ''spec: auth: openShiftoAuth: true initialOpenShiftOAuthUser: ''Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.4.3. Removing OpenShift initial OAuth user Copy linkLink copied to clipboard!
The following procedure describes how to remove OpenShift initial OAuth user provisioned by Red Hat CodeReady Workspaces.
Prerequisites
-
The
octool installed. - An instance of Red Hat CodeReady Workspaces running on OpenShift.
-
Logged in to OpenShift cluster using the
octool.
Procedure
Update codeready-workspaces custom resource:
oc patch checluster/codeready-workspaces -n openshift-workspaces --type=json -p \ '[{"op": "replace", "path": "/spec/auth/initialOpenShiftOAuthUser", "value": false}]'$ oc patch checluster/codeready-workspaces -n openshift-workspaces --type=json -p \ '[{"op": "replace", "path": "/spec/auth/initialOpenShiftOAuthUser", "value": false}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.5. Configuring Minikube with GitHub Authentication Copy linkLink copied to clipboard!
On Minikube, crwctl provides a default OpenID Connect (OIDC) issuer, which can serve as a bridge to third party RH-SSO, such as GitHub. Dex is the default OIDC issuer, preconfigured with static users. Configure Dex to use GitHub authentication.
Prerequisites
- CodeReady Workspaces is installed on Minikube. See https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#installing-che-on-minikube.adoc.
Procedure
Get Minikube IP and remember it as
<minikube_ip>:minikube ip
$ minikube ipCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create an OAuth App for your Minikube instance in GitHub. See GitHub documentation.
Application name: CodeReady Workspaces Homepage URL: https://<minikube_ip>.nip.io Authorization callback URL: https://dex.<minikube_ip>.nip.io/callback
Application name: CodeReady Workspaces1 Homepage URL: https://<minikube_ip>.nip.io2 Authorization callback URL: https://dex.<minikube_ip>.nip.io/callback3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
In the GitHub OAuth application page, click and remember the value of the generated client secret as
<client_secret>. Edit the Dex config map:
oc edit configmap dex -n dex
$ oc edit configmap dex -n dexCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Note: To remove Dex static users, delete all enablePasswordDB and staticPasswords sections.
Restart the Dex pod:
oc delete pod dex -n dex
$ oc delete pod dex -n dexCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification steps
- Open CodeReady Workspaces URL. The dashboard displays GitHub login prompt.
12.6. Removing user data Copy linkLink copied to clipboard!
12.6.1. Removing user data according to GDPR Copy linkLink copied to clipboard!
The General Data Protection Regulation (GDPR) law enforces the right for individuals to have personal data erased.
The following procedure describes how to remove a user’s data from a cluster and the RH-SSO database.
The following commands use the default OpenShift project, openshift-workspaces, as a user’s example for the -n option.
Prerequisites
A user or an administrator authorization token. To delete any other data except the data bound to a user account,
adminprivileges are required. Theadminis a special CodeReady Workspaces administrator account pre-created and enabled using theCHE_SYSTEM_ADMIN__NAMEandCHE_SYSTEM_SUPER__PRIVILEGED__MODE = trueCustom Resource definitions.spec: server: customCheProperties: CHE_SYSTEM_SUPER__PRIVILEGED__MODE: 'true' CHE_SYSTEM_ADMIN__NAME: '<admin-name>'spec: server: customCheProperties: CHE_SYSTEM_SUPER__PRIVILEGED__MODE: 'true' CHE_SYSTEM_ADMIN__NAME: '<admin-name>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow If needed, use commands below for creating the
adminuser:oc patch checluster/codeready-workspaces \ --type merge \ -p '{ "spec": { "server": {"customCheProperties": {"CHE_SYSTEM_SUPER__PRIVILEGED__MODE": "true"} } }}' \ -n openshift-workspaces$ oc patch checluster/codeready-workspaces \ --type merge \ -p '{ "spec": { "server": {"customCheProperties": {"CHE_SYSTEM_SUPER__PRIVILEGED__MODE": "true"} } }}' \ -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch checluster/codeready-workspaces \ --type merge \ -p '{ "spec": { "server": {"customCheProperties": {"CHE_SYSTEM_ADMIN__NAME": "<admin-name>"} } }}' \ -n openshift-workspaces$ oc patch checluster/codeready-workspaces \ --type merge \ -p '{ "spec": { "server": {"customCheProperties": {"CHE_SYSTEM_ADMIN__NAME": "<admin-name>"} } }}' \ -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteAll system permissions are granted to the administrative user. To configure the administrative user, use the
CHE_SYSTEM_ADMIN__NAMEproperty. The default value isadmin. The system permissions are granted when the CodeReady Workspaces server starts. If the user record is not in the CodeReady Workspaces user database, the permissions are granted after the first login of the user.Authorization token privileges:
-
admin- Can delete all personal data of all users -
user- Can delete only the data related to the user
-
- A user or an administrator is logged in the OpenShift cluster with deployed CodeReady Workspaces.
A user ID is obtained. Get the user ID using the commands below:
For the current user:
curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user'
$ curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user'Copy to Clipboard Copied! Toggle word wrap Toggle overflow To find a user by name:
curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/find?name=<username>'
$ curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/find?name=<username>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow To find a user by email:
curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/find?email=<email>'
$ curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/find?email=<email>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example of obtaining a user ID
This example uses
vparfonoas a local user name.curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://che-vp-che.apps.che-dev.x6e0.p1.openshiftapps.com/api/user/find?name=vparfono'
$ curl -X GET \ --header 'Authorization: Bearer <user-token>' \ 'https://che-vp-che.apps.che-dev.x6e0.p1.openshiftapps.com/api/user/find?name=vparfono'Copy to Clipboard Copied! Toggle word wrap Toggle overflow The user ID is at the bottom of the curl command output.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procedure
Update the
codeready-workspacesCheCluster CustomResource (CR) definition to permit the removal of a user’s data from the RH-SSO database:oc patch checluster/codeready-workspaces \ --patch "{\"spec\":{\"server\":{\"customCheProperties\": {\"CHE_KEYCLOAK_CASCADE__USER__REMOVAL__ENABLED\": \"true\"}}}}" \ --type=merge -n openshift-workspaces$ oc patch checluster/codeready-workspaces \ --patch "{\"spec\":{\"server\":{\"customCheProperties\": {\"CHE_KEYCLOAK_CASCADE__USER__REMOVAL__ENABLED\": \"true\"}}}}" \ --type=merge -n openshift-workspacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Remove the data using the API:
curl -i -X DELETE \ --header 'Authorization: Bearer <user-token>' \ https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/<user-id>
$ curl -i -X DELETE \ --header 'Authorization: Bearer <user-token>' \ https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/<user-id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Running the following command returns code 204 as the API response:
curl -i -X DELETE \ --header 'Authorization: Bearer <user-token>' \ https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/<user-id>
$ curl -i -X DELETE \
--header 'Authorization: Bearer <user-token>' \
https://<codeready-<openshift_deployment_name>.<domain_name>>/api/user/<user-id>
Additional resources
To remove the data of all users, follow the instructions for https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.15/html-single/installation_guide/index#uninstalling-che.adoc.