Eclipse Che and Codenvy on Docker

Tyler Jewell
Codenvy Blog
Published in
5 min readAug 13, 2015

--

EclipseCheandCodenvyonDocker

It is now possible to install a multi-node Codenvy On-Prem and Eclipse Che using Docker.

Docker containers wrap a piece of software into a filesystem that contains everything it needs to run: code, runtime, system tools, and libraries. Containers guarantee that the software will always run the same, regardless of the environment that it is running in. Containers turn packaging and deployment into atomic, independent units which make it easier for software development teams to improve their DevOps pipeline by making releases smaller, more consistent, and, ultimately, more boring.

Codenvy has been using containers to power builds, runners, and workspaces for several years. We now support running Codenvy within containers.

Eclipse Che

Eclipse Che is a modern, open source software development environment. It is the engine that powers Codenvy by providing structured workspaces, project typing, and modular extensions packaged as plug-ins. Che can be used as a desktop IDE, a RESTful workspace server, or as an SDK for creating new tooling with plug-ins. We now maintain labeled Docker images that will launch a default Eclipse Che.

Screen Shot 2015-08-11 at 12.31.49 PM

The container is stateless and repeat runs of the container will wipe out data that is saved within the container. You can save your workspace to an external volume mounted outside of the container.

If you do not want to bother with mounting volumes, you can also snapshot the container and save a new image to your local disk. You can then launch the saved image, which restarts the container in the last saved state. This process is stateful, but slower as you have to wait for the snapshot write and read operations to complete.

Screen Shot 2015-08-11 at 12.29.59 PM

Multi-Node Codenvy On-Prem

Codenvy On-Prem is a version of Codenvy that you can run on your own servers. You can run as a single-node (all services in a single host) or as a multi-node system (services clustered and spread across different hosts). It has always been a top objective for us to make it simple and quick to install, upgrade, backup, and customize Codenvy On-Prem.

Screen Shot 2015-08-12 at 10.22.43 AM

You can now install Codenvy On-Prem multi-node using Docker.

While this installation technique is production tested, please read the advisories below to ensure you’re comfortable with certain access control and stability risks that you may run into with Docker. This installer is only supported on Linux.

Some Special Codenvy Magic

Codenvy On-Prem requires eight nodes. With this installer, we launch each node in its own container. The eight containers are identical — instantiated from a specialized CentOS 7 image. After the empty CentOS containers are launched, we invoke Codenvy’s bootstrap installer, which, in turn, installs Puppet to download and configure Codenvy across the pool of containers.

Screen Shot 2015-08-11 at 12.30.52 PM

Codenvy requires each node to be configured with a hostname that matches a certain string pattern. But in order for the various containers to see each other, the /etc/hosts file that exists in each container must be updated with the IP address of the other containers. These IP addresses are not known until after the containers have been launched. So the installer has some additional logic to launch containers, discover their IP addresses, and exec into each container to update their /etc/hosts file with the IP addresses of the other containers. We perform this work to create a discoverable, connected network of containers, and after this is verified, the Codenvy bootstrap installation begins. When restarting containers that have been saved, we do a similar process to update each container with any new IP addresses.

Screen Shot 2015-08-12 at 10.22.31 AM

Containers are deceptively simple. On the surface, they are bite-sized units of deployment. You activate a container from an image and all is good. Container executions are generally stateless, where each execution doesn’t remember what the previous execution did. This means that internal state data, such as what we store for users in LDAP and MongoDB must be externalized.

To compensate, you can either create new images from a running container for use on future runs. Or, you can have Docker write the new data as a layer to the existing image. We have embedded — stop and — restart options into the installation script that will write your container state as layers to the image. In future releases, we’ll support container orchestrators like Docker Swarm, which will give you additional ways to externalize internal data.

Security & Stability Considerations

The Docker installation of Codenvy On-Prem is not supported for single-node configurations. The single node packaging of Codenvy is large and Docker is not well suited to running dozens of microservices within a single container.

All containers for Codenvy On-Prem multi-node must be run in privileged mode which grants the container near-root access to the processes and files running on its host. This is necessary for two reasons:

  1. Our runner nodes must run Docker containers inside them (Docker in Docker).
  2. We use Puppet to perform internal configuration management and it needs access to all nodes and even to some files on the underlying host like AppArmor or SELinux.

Privileged mode is known to be unstable on different operating systems. Please test it thoroughly.

Regards,
Tyler Jewell
Founder and CEO

--

--

MD @ Dell Tech Capital. BOD @ NS1, Orion Labs. Prev: CEO @ WSO2, CEO @ Codenvy (acq. by RHT). Invest @ Sauce Labs, Cloudant, ZeroTurnaround, InfoQ, Sourcegraph.