che: Support running VS Code in the containers that don't include the pre-requisites

Depends on:

Is your task related to a problem? Please describe

Currently, Che-Code works perfectly in a UDI8-based container. But, as a user, I should be able to run the Che-Code editor in my own container which, ideally, can be based on any image. E.g.: maven:3.8.6-openjdk-18, registry.access.redhat.com/ubi9/ubi, etc.

For example, if I run Che-Code in a DevWorkspace created from the following Devfile:

schemaVersion: 2.1.0
metadata:
  name: che-code-on-ubi
components:
  - name: dev
    container:
      image: registry.access.redhat.com/ubi8/ubi
      memoryLimit: 7Gi
      cpuLimit: 3500m
  - name: projects
    volume:
      size: 3Gi

Che-Code starts well, as it brings the Node.js runtime copied into the dedicated volume. But there’s a problem when opening a terminal: The terminal process "/sbin/nologin" failed to launch (exit code: 1).

term

Some logs from the container:

[12:27:52] ptyHost was unable to resolve shell environment Error: Unable to resolve your shell environment: Unexpected exit code from spawned shell (code 1, signal null)
    at /checode/checode-linux-libc/out/vs/server/node/server.main.js:92:2608
    at async /checode/checode-linux-libc/out/vs/server/node/server.main.js:68:23642
...
[12:28:08] ExtensionHostConnection#buildUserEnvironment resolving shell environment failed Error: Unable to resolve your shell environment: Unexpected exit code from spawned shell (code 1, signal null)
    at /checode/checode-linux-libc/out/vs/server/node/server.main.js:92:2608
    at async /checode/checode-linux-libc/out/vs/server/node/server.main.js:68:23642

Describe the solution you’d like

It looks like the only problem we should solve it’s opening the VS Code terminal. But need to check if other functionality works well.

Describe alternatives you’ve considered

No response

Additional context

Running Che-Code in a UBI9-based container is problematic as well:

schemaVersion: 2.1.0
metadata:
  name: che-code-on-ubi
components:
  - name: dev
    container:
      image: registry.access.redhat.com/ubi9/ubi
      memoryLimit: 7Gi
      cpuLimit: 3500m
  - name: projects
    volume:
      size: 3Gi

See for more details at https://github.com/eclipse/che/issues/21629. Currently, there’s a workaround described in https://github.com/che-incubator/che-code/tree/main/build/dockerfiles. It also requires a more stable solution.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 1
  • Comments: 26 (22 by maintainers)

Most upvoted comments

I’m working on building Node.js from sources to get independent binary file that doesn’t rely on the current system libraries. Usually ldd node command shows a list of libs with links to the system folder:

image

After building Node.js from sources I have:

image

It allows to avoid errors like:

./node: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory 

so, a workspace starts successfully.

We just had a discussion with @RomanNikitenko and decided that a pragmatic solution is to build a new versions of che-code based on ubi9 nodejs. We already build a libc version using registry.access.redhat.com/ubi8/nodejs-18 and a musl version using docker.io/node:18.16.1-alpine3.18 so that’s about:

  • adding a libc-v2.3 version using registry.access.redhat.com/ubi9/nodejs-18
  • adding the logic to figure out which libc version of vscode to copy at workspace startup

In fact the devfile in the devfile registry has:

  - container:
      (...)
      image: registry.access.redhat.com/ubi9/go-toolset:1.18.9-14
      args: ['tail', '-f', '/dev/null']

@RomanNikitenko the requirement is that the container has to be non terminating. From the documentation:

Either the command defined by the image or by the container component within the devfile must be non-terminating, such as the case of setting command to sleep with the infinity argument.