Theia remote plug-in runtime in sidecar container improvement

[evidolob]

Description

Currently we have base image for remote plugin. So all remote plugin images should inherit it, which is not convenient by it self, and heavily increase remote plugin image build time. Also we have some problems when Thiea IDE and remote plugin runtime has different version(when some one doesn't update remote plugin image) which leads to very strange and difficult to detect bugs.

We can improve that with two options:

1. Add che-theia remote plugin runtime binary at the end of plugin image build
2. Mount and run che-theia remote plugin runtime binary on che workspace start

[evidolob]

@benoitf WDYT?

[benoitf]

@evidolob

yes I think steps are:

1. Move theia-endpoint outside of dockerfiles folder
2. Produce all-in-one binary of the package in another foler
3. @davidfestal is proposing as well to copy binary in a volume so basically we should try to have image without the runtime inside as well. (let's pick up one of the current images) and to provide binary inside a docker image (to allow to grab this binary from a init container)
4. move the insert of the binary to the end of images instead of inheriting parent endpoint image (so layers are re-used at their best) . (and if David is able to run binary outside we could avoid this step and just prune endpoint from all images)

[AndrienkoAleksandr]

1. Move theia-endpoint outside of dockerfiles folder

Seems, done by @tolusha eclipse-che/che-theia#254

2. Produce all-in-one binary of the package in another foler

I complete investigation.
node.js doesn't has embedded mechanism to build executable image from the box(it's not golang...). So to build executable binary we need to use third party libs. But all of them has own pluses and minuses. To build remote-plugin-endpoint I've got not bad result only with nexe tool, but this tool has own limitation too: doesn't support dynamic require and native node libs(native node libs - it's code written on non node, f.e on the c or c++, but wrapped with help node). So for remote-plugin-endpoint we should not use these features to prevent issues with nexe.
So, To package all-in-one binary I experemented with 4 tools:

pkg - doesn't work for our remote-plugin code, because our code uses getMac dependency(like transitive dependency). pkg unable to resolve such kind of libs, see more vercel/pkg#519

node-packer - remote-plugin-endpoint binary compiled with help this tool doesn't work for alpine images at all (pmq20/node-packer#127), and node-packer executable binary doesn't work under alpine too. On the github repo we can see that source code contains node source code with version 8.3.0, but we need node 10.

appImage - main idea - package remote-plugin with help electron and generate with help electron-builder lib binary in the universal linux binary format - AppImage. But such binaries doesn't work in the docker containers, because appImage uses fuse filesystem, which works for docker containers only with privilege mode. Also fuse filesystem need fuse filesystem libs - I could not find any base linux images where are these dependencies are pre-installed.

nexe - I generated binary with platform flag alpine, but this binary works for all another containers which I tested. I tested this binary with images:

• registry.access.redhat.com/ubi8/ubi-minimal
• ubuntu:18.04
• debian:9
• fedora:30
• centos:7
• busybox
• node:10.15-alpine
• opensuse/leap
• cirros
• clefos
• mageia:7
• photon:latest
• proton
• alt
• amazonlinux
• open-liberty
• php
• oraclelinux
• golang:stretch
• alpine

[AndrienkoAleksandr]

All-in-one binary branch https://github.com/eclipse/che-theia/compare/remoteBinary

[AndrienkoAleksandr]

Binary size 136.8Mb

[AndrienkoAleksandr]

@davidfestal is proposing as well to copy binary in a volume so basically we should try to have image without the runtime inside as well. (let's pick up one of the current images) and to provide binary inside a docker image (to allow to grab this binary from a init container)

Hello, @davidfestal Did you mean, that we can use plugin-broker to serve remote-plugin-endpoint binary, and Eclipse CHE master could create volume for remote plugin containers and copy binary inside volume?

[davidfestal]

Well, initially my general idea was that we could provide such binaries (or any additional standalone files) in very lightweight containers that would contain:

• the files to inject,
• a lightweight cp utility (such as the busybox one)
• An env variable that indicates where to copy the provided files to inject.

Then it would be added as an initContainer in the workspace POD with a volume and the right env variable.

Such lightweight container images could be either created at build time (for the remote-plugin-endpoint) or even created on-the-fly by the plugin broker (for plugin archives for example).

[AndrienkoAleksandr]

@davidfestal Do you have a plan to implement your initial idea or this part of task should be done by ide2 team?

[davidfestal]

In fact it seems to me that it would be sufficient to simply:

• add a single optional boolean initContainer field (false by default) on the CheContainer model class,
• and add all the containers with a true value as init containers in the workspace POD.

All the rest of the work would be done in the plugin broker.

However, if I find some time I might be able to prepare the plugin-broker part of this work and test it with the Che Workspace CRD Operator POC.

[davidfestal]

@l0rd Should I open a separate issue for this ?