The following pages and posts are tagged with

TitleExcerpt
CLI Reference CLI syntax and commands The CLI is a Docker-formatted container image that comes with a collection of commands to configure, interact with, and start Che. The CLI also contains commands, such as sync and ssh, for end users to interact with workspaces. ...
Configuring Che on Docker The Che on Docker configuration is handled by modifying the che.env file that is placed in the root directory of a host directory mounted to :/data. This configuration file is generated during the che init phase. If you rerun the che init command in an already initialized...
Multi-user: Installation on Docker System requirements Minimum 4GB of RAM (for the three Che containers and one 2GB workspace) 2 CPUs Ports 8080, 5050, and the ephemeral port range publicly available for inbound connections (32768-65535) ...
Single-User: Installation on Docker This section walks you through the single-user installation of Che on Docker. Prerequisites Use Docker version 17 or higher. Older versions are untested but may work (1.13 or higher). To install the latest Docker version, see https://docs.docker.com/install/.
Infrastructures supported in Eclipse Che Introduction Eclipse Che runs on several infrastructures and container engines: Docker OpenShift: OpenShift Container Platform (OCP), OpenShift Online (OSO), OpenShift Dedicated (OCD), MiniShift Kubernetes
Che on Kubernetes: Admin Guide :page-layout: _auto :admin-context: Kubernetes :ctl-command: kubectl :k8s-namespace: Kubernetes Namespace :docs-registry-link: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/ :che-data-volume-link: https://github.com/eclipse/che/blob/master/deploy/kubernetes/helm/che/templates/deployment.yaml#L57 :cluster-nodes-link: https://kubernetes.io/docs/concepts/architecture/nodes/#management // This content (file) is included in: // // * setup-kubernetes/kubernetes-admin-guide.adoc // * setup-openshift/openshift-admin-guide.adoc // // The 'admin-context' variable (set in the parent files) // is used to determine K8s or OpenShift use. // ifeval::[{admin-context} == "OpenShift"] // :ctl-command: oc // :k8s-namespace: OpenShift Project // endif::[] // // ifeval::[{admin-context} == "Kubernetes"] // :ctl-command: kubectl // :k8s-namespace: Kubernetes Namespace // endif::[] hen the deployment YAML files run, [id="ram-prerequisites"] == RAM prerequisites [id="single-user-prerequisites"] === Single-user prerequisites 3 GB of RAM is required for single-user Che on {admin-context}. Single-user Che uses RAM in this distribution: * Che server pod uses up to 1 GB of RAM. The initial request for RAM is 256 MB. The Che server pod rarely uses more than 800 MB RAM. * Workspaces use 2 GB of RAM. [id="multi-user-prerequisites"] === Multi-user prerequisites You must have at least 5 GB of RAM to run multi-user Che. The Keycloak authorization server and PostgreSQL database require the extra RAM. Multi-user Che uses RAM in this distribution: * Che server: approximately 750 MB * Keycloak: approximately 1 GB * PostgreSQL: approximately 515 MB * Workspaces: 2 GB of RAM per workspace. The total workspace RAM depends on the size of the workspace runtime(s) and the number of concurrent workspace pods. === Setting default workspace RAM limits The default workspace RAM limit and the RAM allocation request can be configured by passing the `pass:[CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB]` and `pass:[CHE_WORKSPACE_DEFAULT__MEMORY__REQUEST__MB]` parameters to a Che deployment. For example, use the following configuration to limit the amount of RAM used by workspaces to 2048 MB and to request the allocation of 1024 MB of RAM: [subs="+attributes"] ---- $ {ctl-command} set env dc/che CHE_WORKSPACE_DEFAULT__MEMORY__LIMIT__MB=2048 \ CHE_WORKSPACE_DEFAULT__MEMORY__REQUEST__MB=1024 ---- [NOTE] ==== * The user can override the default values when creating a workspace. * A RAM request greater than the RAM limit is ignored. ==== [id="requirements-for-resource-allocation-and-quotas"] == Requirements for resource allocation and quotas Workspace pods are created in the account of the user who deploys Che. The user needs enough quota for RAM, CPU, and storage to create the pods. [id="setting-up-the-project-workspace"] == Setting up the project workspace Workspace objects are created differently depending on the configuration. Eclipse Che currently supports two different configurations: * Single {admin-context} project * Multi {admin-context} project [id="setting-up-a-single-openshift-project"] === Setting up a single {admin-context} project To setup a single {admin-context} project: . Define the service account used to create workspace objects with the `CHE_OPENSHIFT_SERVICEACCOUNTNAME` variable. . To ensure this service account is visible to the Che server, put the service and the Che server in the same namespace. . Give the service account permissions to create and edit {admin-context} resources. . If the developer needs to create an object outside of the service accounts bound namespace, give the service account cluster-admin rights by running this command: + [subs="+attributes"] ---- $ {ctl-command} adm policy add-cluster-role-to-user self-provisioner system:serviceaccount:eclipse-che:che ---- In the command above, `eclipse-che` is the Che namespace. [id="setting-up-a-multi-openshift-project"] === Setting up a multi {admin-context} project . To create workspace objects in different namespaces for each user, set the `NULL_CHE_INFRA_OPENSHIFT_PROJECT` variable to `NULL`. . To create resources on behalf of the currently logged-in user, use the user’s {admin-context} tokens. [id="how-the-che-server-uses-PVCs-and-PVs-for-storage"] == How the Che server uses PVCs and PVs for storage Che server, Keycloak and PostgreSQL pods, and workspace pods use Persistent Volume Claims (PVCs), which are bound to the physical Persistent Volumes (PVs) with https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes[ReadWriteOnce access mode]. When the deployment YAML files run, they define the Che PVCs. You can configure link:#storage-strategies-for-che-workspaces[workspace PVC] access mode and claim size with Che deployment environment variables. [IMPORTANT] ==== The following two conditions prevent the user from running multiple workspaces: * Che uses the `common` Persistent Volume Claim (PVC) strategy * Persistent volumes (PVs) use `ReadWriteOnce` (RWO) access mode To work around this limitation, use one of the following measures: * Set `ReadWriteMany` (RWX) access mode for PVs * Use the `unique` PVC strategy * Use the `per-workspace` strategy ==== [id="storage-requirements-for-che-infrastructure"] === Storage requirements for Che infrastructure * Che server: 1 GB to store logs and initial workspace stacks. * Keycloak: 2 PVCs, 1 GB each to store logs and Keycloak data. * PostgreSQL: 1 GB PVC to store database. [id="storage-strategies-for-che-workspaces"] === Storage strategies for Che workspaces The workspace PVC strategy is configurable: [width="100%",cols="25%,25%,25%,25%",options="header",] |=== |strategy |details |pros |cons |*unique (default)* | One PVC per workspace volume or user-defined PVC |Storage isolation |An undefined number of PVs is required |*common* | One PVC for all workspaces in one {k8s-namespace} Sub-paths pre-created |Easy to manage and control storage |Workspaces must be in a separate {k8s-namespace} if PV does not support ReadWriteMany (RWX) access mode |*per-workspace* | One PVC for one workspace Sub-paths pre-created |Easy to manage and control storage |Workspace containers must all be in one pod if PV does not support ReadWriteMany (RWX) access mode |=== [id="unique-pvc-strategy"] === Unique PVC strategy [id="how-the-unique-pvc-strategy-works"] ==== How the unique PVC strategy works Every Che Volume of workspace gets its own PVC, which means workspace PVCs are created when a workspace starts for the first time. Workspace PVCs are deleted when a corresponding workspace is deleted. User-defined PVCs are created with few modifications: - they are provisioned with genarated names to garantee that it is not conflicting with other PVCs in namespace; - subpaths of mount volumes that reference user-defined PVCs are prefixed with `{workspace id}/{PVC name}`. It is done to have the same data structure on PV on different PVC strategies; [id="enabling-a-unique-strategy"] ==== Enabling a unique strategy If you have already deployed Che with another strategy, set the `CHE_INFRA_KUBERNETES_PVC_STRATEGY` variable to `unique` in `dc/che`. Note that existing workspaces data won't be migrated and they will use new unique PVC per Che Volume without cleaning up existing PVCs. If applying the `che-server-template.yaml` configuration, pass `-p CHE_INFRA_KUBERNETES_PVC_STRATEGY=unique` to the `{ctl-command} new-app` command. [id="common-pvc-strategy"] === Common PVC Strategy [id="how-the-common-pvc-strategy-works"] ==== How the common PVC strategy works All workspaces (within one {k8s-namespace}) use the same PVC to store data declared in their volumes (projects and workspace logs by default and whatever additional link:volumes.html[volumes] that a user can define.) User-defined PVCs are ignored and volumes that reference PVCs are replaced with volume that references common PVC. The corresponding containers volume mounts are relinked to common volume and subpaths are prefixed with `'{workspaceId}/{originalPVCName}'`. User-defined PVC name is used as Che Volume name. It means that if Machine is configured to use Che Volume with the same name as user-defined PVC has then they will use the same shared folder in common PVC. A PV that is bound to PVC `che-claim-workspace` will have the following structure: ---- pv0001 workspaceid1 workspaceid2 workspaceidn che-logs projects ... ---- Volumes can be anything that a user defines as volumes for workspace machines. The volume name is equal to the directory name in `${PV}/${ws-id}`. When a workspace is deleted, a corresponding subdirectory (`${ws-id}`) is deleted in the PV directory. [id="enabling-the-common-strategy"] ==== Enabling the common strategy If you have already deployed Che with another strategy, set the `CHE_INFRA_KUBERNETES_PVC_STRATEGY` variable to `common` in `dc/che`. Note that existing workspaces data won't be migrated and they will use common PVC without cleaning up existing PVCs. If applying the `che-server-template.yaml` configuration, pass `-p CHE_INFRA_KUBERNETES_PVC_STRATEGY=common` to the `{ctl-command} new-app` command. [id="restrictions-on-using-common-pvc-strategy"] ==== Restrictions on using the common PVC strategy When the `common` strategy is used and a workspace PVC access mode is ReadWriteOnce (RWO), only one {admin-context} node can simultaneously use the PVC. If there are several nodes, you can use the `common` strategy, but the workspace PVC access mode is ReadWriteMany (RWM). Multiple nodes can use this PVC simultaneously. To change the access mode for workspace PVCs, pass the `CHE_INFRA_KUBERNETES_PVC_ACCESS_MODE=ReadWriteMany` environment variable to Che deployment either when initially deploying Che or through the Che deployment update. Another restriction is that only pods in the same namespace can use the same PVC. The `CHE_INFRA_KUBERNETES_PROJECT` environment variable should not be empty. It should be either the Che server namespace where objects can be created with the Che service account (SA) or a dedicated namespace where a token or a user name and password need to be used. [id="per-workspace-pvc-strategy"] === Per workspace PVC strategy [id="how-the-per-workspace-pvc-strategy-works"] ==== How the per-workspace PVC strategy works The `per-workspace` strategy works similarly to the `common` PVC strategy. The only difference is that all workspace volumes (but not all workspaces) use the same PVC to store data (projects and workspace logs by default and any additional link:volumes.html[volumes] that a user can define). [id="enabling-a-per-workspace-strategy"] ==== Enabling a per-workspace strategy If you have already deployed Che with another strategy, set the `CHE_INFRA_KUBERNETES_PVC_STRATEGY` variable to `per-workspace` in `dc/che`. Note that existing workspaces data won't be migrated and they will use common PVC per workspace without cleaning up existing PVCs. If applying the `che-server-template.yaml` configuration, pass `-p CHE_INFRA_KUBERNETES_PVC_STRATEGY=per-workspace` to the `{ctl-command} new-app` command. [id="updating-your-che-deployment"] == Updating your Che deployment To update a Che deployment: . Change the image tag: + You can change the image tag in one of the following ways: * On the command line, edit the image tag by running: + [subs="+attributes"] ---- $ {ctl-command} edit dc/che ---- + * In the {admin-context} web console, edit the `image:tag` line in the YAML file in *Deployments* * Using the Docker service: + [subs="+attributes,+macros"] ---- $ {ctl-command} set image dc/che che=eclipse/che-server:$pass:[{VERSION}] --source=docker ---- . Update Keycloak and PostgreSQL deployments (optional): * Run the `eclipse/che-keycloak` command. * Run the `eclipse/che-postgres` command. + You can get the list of available versions at https://github.com/eclipse/che/tags[Che GitHub page]. . Change the pull policy (optional): + To change the pull policy, do one of the following: * Add `--set cheImagePullPolicy=IfNotPresent` to the link:openshift-multi-user.html[Che deployment]. * Manually edit `dc/che` after deployment. The default pull policy is `Always`. The default tag is `nightly`. This tag sets the image pull policy to `Always` and triggers a new deployment with a newer image, if available. [id="scalability"] == Scalability To run more workspaces, {cluster-nodes-link}[add more nodes to your {admin-context} cluster]. An error message is returned when the system is out of resources. [id="gdpr"] == GDPR To delete data or request the administrator to delete data, run this command with the user or administrator token: ---- $ curl -X DELETE http://che-server/api/user/{id} ---- [id="debug-mode"] == Debug mode To run Che Server in debug mode, set the following environment variable in the Che deployment to `true` (default is `false`): `CHE_DEBUG_SERVER=true` [id="kubernetes-or-openshift-admin-guide-private-docker-registries"] == Private Docker registries See {docs-registry-link}[{admin-context} documentation]. [id="che-server-logs"] == Che server logs Logs are persisted in a PV .The PVC `che-data-volume` is {che-data-volume-link}[created] and bound to a PV after Che deploys to {admin-context}. To retrieve logs, do one of the following: * Run the `{ctl-command} get log dc/che` command. * Run the `{ctl-command} describe pvc che-data-claim` command to find the PV. Next, run the `{ctl-command} describe pv $pvName` command with the PV to get a local path with the logs directory. Be careful with permissions for that directory, since once changed, Che server will not be able to write to a file. * In the {admin-context} web console, select *Pods > che-pod > Logs*. It is also possible to configure Che master not to store logs, but produce JSON encoded logs to output instead. It may be used to collect logs by systems such as Logstash. To configure JSON logging instead of plain text environment variable `CHE_LOGS_APPENDERS_IMPL` should have value `json`. See more at link:logging.html[logging docs]. [id="workspace-logs"] == Workspace logs Workspace logs are stored in an PV bound to `che-claim-workspace` PVC. Workspace logs include logs from workspace agent, link:what-are-workspaces.html#bootstrapper[bootstrapper] and other agents if applicable. [id="che-master-states"] == Che master states The Che master has three possible states: * `RUNNING` * `PREPARING_TO_SHUTDOWN` * `READY_TO_SHUTDOWN` The `PREPARING_TO_SHUTDOWN` state means that no new workspace startups are allowed. This situation can cause two different results: * If your infrastructure does not support workspace recovery, all running workspaces are forcibly stopped. * If your infrastructure does support workspace recovery, any workspaces that are currently starting or stopping is allowed to finish that process. Running workspaces do not stop. For those that did not stop, automatic fallback to the shutdown with full workspaces stopping will be performed. If you want a full shutdown with workspaces stopped, you can request this by using the `shutdown=true` parameter. When preparation process is finished, the `READY_TO_SHUTDOWN` state is set which allows to stop current Che master instance. [id="kubernetes-or-openshift-admin-guide-che-workspace-termination-grace-period"] == Che workspace termination grace period The default grace termination period of {admin-context} workspace pods is `0`. This setting terminates pods almost instantly and significantly decreases the time required for stopping a workspace. To increase the grace termination period, use the following environment variable: `pass:[CHE_INFRA_KUBERNETES_POD_TERMINATION__GRACE__PERIOD__SEC]`. [IMPORTANT] ==== If the `terminationGracePeriodSeconds` variable is explicitly set in the {admin-context} recipe, the `pass:[CHE_INFRA_KUBERNETES_POD_TERMINATION__GRACE__PERIOD__SEC]` environment variable does not override the recipe. ==== [id="kubernetes-or-openshift-admin-guide-che-workspace-stop-on-pods-removing"] == Auto-stopping a workspace when its pods are removed Che Server includes a job that automatically stops workspace runtimes if their pods have been terminated. Pods are terminated when, for example, users remove them from the {admin-context} console, administrators terminate them to prevent misuse, or an infrastructure node crashes. The job is disabled by default to avoid problems in configurations where Che Server cannot interact with the Kubernetes API without user intervention. The job cannot function with the following Che Server configuration: * Che Server communicates with the Kubernetes API using a token from the OAuth provider. The job can function with the following Che Server configurations: * Workspaces objects are created in the same namespace where Che Server is located. * The *cluster-admin* service account token is mounted to the Che Server pod. To enable the job, set the `pass:[CHE_INFRA_KUBERNETES_RUNTIMES__CONSISTENCY__CHECK__PERIOD__MIN]` environment variable to contain a value greater than `0`. The value is the time period in minutes between checks for runtimes without pods. [id="updating-che-without-stopping-active-workspaces"] == Updating Che without stopping active workspaces The differences between a Recreate update and a Rolling update: [options="header,autowidth"] |=== | Recreate update |Rolling update | Che downtime |No Che downtime | - |New deployment starts in parallel and traffic is hot-switched |=== [id="performing-a-recreate-update"] === Performing a recreate update To perform a recreate update: * Ensure that the new master version is fully API compatible with the old workspace agent version. * Set the deployment update strategy to Recreate * Make POST request to the `/api/system/stop` api to start WS master suspend. This means that all new attempts to start workspaces will be refused, and all current starts and stops will be finished. Note that this method requires system admin credentials. * Make periodical `GET` requests to the `/api/system/state` API, until it returns the `READY_TO_SHUTDOWN` state. Also, you can check for "System is ready to shutdown" in the server logs. * Perform new deploy. [id="performing-a-rolling-update"] === Performing a rolling update To perform a rolling update: * Ensure that the new master is fully API compatible with the old ws agent versions, as well as database compatibility. It is impossible to use database migrations on this update mode. * Set the deployment update strategy set to Rolling. * Ensure `terminationGracePeriodSeconds` deployment parameter has enough value (see details below). * Press *Deploy* button or execute `{ctl-command} rollout latest che` from cli client. [id="known-issues"] ==== Known issues * Workspaces may fallback to the stopped state when they are started five to thirty seconds before the network traffic are switched to the new pod. This happens when the bootstrappers use the Che server route URL for notifying the Che Server that bootstrapping is done. Since traffic is already switched to the new Che server, the old Che server cannot get the bootstrapper's report and fails to start after the waiting timeout is reached. If the old Che server is killed before this timeout, the workspaces can be stuck in the `STARTING` state. The `terminationGracePeriodSeconds` parameter must define enough time to cover the workspace start timeout, which is eight minutes plus some additional time. Typically, setting `terminationGracePeriodSeconds` to 540 sec is enough to cover all timeouts. * Users may experience problems with websocket reconnections or missed events published by WebSocket connection when a workspace is `STARTED` but dashboard displays that it is `STARTING`. In this case, you need to reload the page to restore connections and the actual workspace states. [id="update-with-db-migrations-or-api-incompatibility"] === Updating with database migrations or API incompatibility If new version of Che server contains some DB migrations, but there is still API compatibility between old and new version, recreate update type may be used, without stopping running workspaces. API incompatible versions should be updated with full workspaces stop. It means that `/api/system/stop?shutdown=true` must be called prior to update. [id="deleting-deployments"] == Deleting deployments The fastest way to completely delete Che and its infrastructure components is to delete the project and namespace. To delete Che and components: [subs="+attributes"] ---- $ {ctl-command} delete namespace che ---- You can use selectors to delete particular deployments and associated objects. To remove all Che server related objects: [subs="+attributes"] ---- $ {ctl-command} delete all -l=app=che ---- To remove all Keycloak related objects: [subs="+attributes"] ---- $ {ctl-command} delete all -l=app=keycloak ---- To remove all PostgreSQL-related objects: [subs="+attributes"] ---- $ {ctl-command} delete all -l=app=postgres ---- PVCs, service accounts and role bindings should be deleted separately because `{ctl-command} delete all` does not delete them. To delete Che server PVC, ServiceAccount and RoleBinding: [subs="+attributes"] ---- $ {ctl-command} delete sa -l=app=che $ {ctl-command} delete rolebinding -l=app=che ---- To delete Keycloak and PostgreSQL PVCs: [subs="+attributes"] ---- $ {ctl-command} delete pvc -l=app=keycloak $ {ctl-command} delete pvc -l=app=postgres ---- == Monitoring Che Master Server Master server emits metrics in Prometheus format by default on port `8087` of the Che server host (this can be customized by the `che.metrics.port` link:properties.html#properties-and-environment-variables[configuration property]). You can configure your own Prometheus deployment to scrape the metrics (as per convention, the metrics are published on the `:8087/metrics` endpoint). The Che's Helm chart can optionally install Prometheus and Grafana servers preconfigured to collect the metrics of the Che server. When you set the `global.metricsEnabled` value to `true` when installing Che's Helm chart, Prometheus and Grafana servers are automatically deployed. The servers are accessible on `prometheus-.domain` or `grafana-.domain` domains respectively. The Grafana server is preconfigured with a sample dashboard showing the memory usage of the Che server. You can log in to the Grafana server using the predefined username `admin` with the default password `admin`.
Configuring Kubernetes :page-layout: _auto You can configure the behavior of the Che server by passing environment variables to the Che deployment. There are multiple ways to edit the Che deployment to add new or edit existing environment variables: * To open the Che deployment YAML file in text editor, use: + ----...
Deploying multi-user Che to Kubernetes :page-layout: _auto This section walks you through multi-user deployment of Che on Kubernetes. *Prerequisites* * A Kubernetes cluster with at least 4 GB RAM and RBAC: ** For Minikube 0.26.0 and higher, use the following command: + ---- minikube start --cpus 2 --memory 4096 --extra-config=apiserver.authorization-mode=RBAC ---- + ** For Minikube...
Deploying single-user Che to Kubernetes :page-layout: _auto This section walks you through single-user deployment of Che on Kubernetes. *Prerequisites* * A Kubernetes cluster with at least 4 GB RAM and RBAC: ** For Minikube 0.26.0 and higher, use the following command: + ---- minikube start --cpus 2 --memory 4096 --extra-config=apiserver.authorization-mode=RBAC ---- + ** For Minikube...
Che on OpenShift: Admin Guide :page-layout: _auto :admin-context: OpenShift :ctl-command: oc :k8s-namespace: OpenShift Project :docs-registry-link: https://docs.okd.io/latest/architecture/infrastructure_components/image_registry.html :che-data-volume-link: https://github.com/eclipse/che/blob/master/deploy/openshift/templates/pvc/che-server-pvc.yaml#L14 :cluster-nodes-link: https://docs.okd.io/latest/admin_guide/manage_nodes.html include::../setup-kubernetes/kubernetes-or-openshift-admin-guide.adoc[] [id="create-workspace-objects-in-personal-namespaces"] == Creating workspace objects in personal namespaces You can register the OpenShift server as an identity provider when Che is installed in multi-user mode. This allows you to create workspace objects in the...
Configuration: OpenShift :page-layout: _auto [id="admin-guide"] == Admin Guide See: link:openshift-admin-guide.html[OpenShift Admin Guide] to general information that works both for OS and K8S. [id="configure-che-server"] == Configure Che Server Che server is configured by updating environment variables passed to Che deployment. You can configure Che Server when initially deploying Che (See: link:openshift-single-user.html[Installation Single User],...
Multi-User: Deploying to OpenShift :page-layout: _auto [id="deploying-che-on-supported-openshift-flavors-and-versions"] == Deploying Che on supported OpenShift flavors and versions Multi-user Eclipse Che can be deployed to OpenShift Container Platform 3.6 and later, OpenShift Dedicated, and OpenShift Online Pro. The deployment script creates three DeploymentConfigs for Che, PostgreSQL, and Keycloak. PVCs, services, and routes (Che and Keycloak only)...
Single-User: Deploy to OpenShift :page-layout: _auto [id="supported-openshift-flavors-and-versions"] == Supported OpenShift Flavors and Versions Single User Eclipse Che can be deployed to Minishift, OCP, OSD and OSO v3.6+. [id="pre-requisites"] == Pre-Requisites OpenShift oc client installed locally [id="admin-guide"] == Admin Guide See: link:kubernetes-admin-guide.html[Kubernetes Admin Guide] [id="deployment-diagram"] == Deployment Diagram There are a few essential Kubernetes and...
Quick-Start :page-layout: _auto Eclipse Che is a developer workspace server and cloud IDE. You install, run, and manage Eclipse Che with with different container orchestration engines such as Docker or OpenShift. Eclipse Che is available in two modes: * *Single-user*: This is suited for personal desktop environments. * *Multi-user*: This is...
Single and Multi-User Che :page-layout: _auto Eclipse Che is available in two different modes: single-user and multi-user. **Single-user Che** To use Che on your local machine or to evaluate the platform, start with single-user Che. The advantages of using single-user Che are: * The command line interface pulls fewer images. * The user dashboard...