This is a brief write-up of the results of our review of Eclipse Che (4.6) as a primary development environment in NDS Labs ( NDS-367 - Getting issue details... STATUS ).

Che is a combination developer workspace server and cloud-based IDE, based on the popular Eclipse desktop IDE.   Che is available for local installation, but also serves as the primary technology behind the Codenvy commercial service.  Che can be used to develop in a variety of languages including Java, Python, Node, Go, etc.

Che has two primary components: the workspace server and individual workspaces.  The workspace server is a Java-based web application that allows you to start one or more workspaces.  Each workspace is implemented as a headless docker container that runs a workspace agent.  The workspace container has all of the dependencies for the chosen language, and the web UI communicates with the individual workspace containers via Docker networking. 

While Che at first glance seems like a good fit for labs, it is in essence a Docker container (workspace server) that creates Docker containers (workspaces).  This is not well-suited to our Kubernetes approach.  

We explored using Docker-in-Docker (dind) as a basis for Che, to allow the container to create locally-managed workspace containers. However, the requirement to use the large range of Docker ephemeral ports rendered the tool unusable:

 

The basic experiment is described here:

https://github.com/bodom0015/che-experiment

 

See https://eclipse-che.readme.io/docs/usage-docker-server#section-ports:

If you do not want to expose ports 32768-65535 because of the large port range, you need to reconfigure your Docker daemon to communicate over the docker0 interface. You need to set DOCKER_MACHINE_HOST to 172.17.0.1 and modify machine.docker.che_api.endpoint in the che.properties file.

 

Whereas Cloud9 creates a proxy to reach the debugger (and assumes a single "workspace"), Che requires the arbitrary port range, which is problematic. Connections are made to each workspace container for the terminal (pty) and workspace agent, for example:

This indicates at least two Docker ports per workspace – one for the workspace agent and one for the terminal. With some effort, it might be possible to setup a proxy – or go back to the idea of Che for Kubernetes, using ingress rules in place of ports. Either way, it won't be easy.

 
While it would be nice to support Che, there's a fair amount of work required to adapt to the NDS Labs model. Two options
:

1. Implement Kubernetes support (https://github.com/eclipse/che/issues/1193)
2. Implement a proxy method similar to Cloud9 (https://github.com/eclipse/che/issues/1560)

As of now, Che requiring the full docker ephemeral range renders it unusable in labs, even with dind support.

 

 

  • No labels