Start remote endpoint binary using entrypint.sh script with UID fix.

[AndrienkoAleksandr]

What does this PR do?

eclipse-che/che#13387

What issues does this PR fix or reference?

Start remote endpoint binary using entrypint.sh script with UID fix.

Signed-off-by: Oleksandr Andriienko [email protected]

[che-bot]

E2E Happy path tests of Eclipse Che Single User on K8S (minikube v1.1.1) has failed:

• build details
• test report
• logs and configs
• "che-theia" docker image: maxura/che-theia:499
• "che-theia-endpoint-runtime" docker image: maxura/che-theia-endpoint-runtime:499
• "che-remote-plugin-runner-java8" docker image: maxura/che-remote-plugin-runner-java8:499
• "che-remote-plugin-kubernetes-tooling-1.0.0" docker image: maxura/che-remote-plugin-kubernetes-tooling-1.0.0:499
• Happy path tests DevFile
• https://github.com/orgs/eclipse/teams/eclipse-che-qa please check this report.
  Use command "crw-ci-test" to rerun the test.

[benoitf]

hello, how can you be sure that /etc/passwd is writeable ? (I see that you're checking that it's writeable or not)

But how does it work when image entrypoint is already writing data to passwd file.

I would say that this endpoint is part of the devfile 'uid images fix' but it's not part of che-theia endpoint

[AndrienkoAleksandr]

But how does it work when image entrypoint is already writing data to passwd file.

I think whoami returns than user name and we don't touch /etc/passwd.

[benoitf]

in which case do we need it ? If images are patched this is not used and if images are not patched it will do nothing as passwd is not writable

[AndrienkoAleksandr]

Image could contains own entrypoint.sh. We override entrypoint to start remote binary and this script doesn't start. Plugin writer can fix it in the meta.yaml definition: simply changing command to start entrypoint.sh and than start remote binary using env. For me it's looks good and pretty configurable, but not all developers happy of that, see discussion in the pr: eclipse-che/che-plugin-registry#233

[benoitf]

@AndrienkoAleksandr the question is why we need to override entrypoint and not executing command after container is available ?
I mean entrypoint could do a lot of stuff and responsibility is to image creator.

[AndrienkoAleksandr]

why we need to override entrypoint and not executing command after container is available

There are some images which doesn't has entrypoint at all, but we want to use them like sidecar image with remote plugin. So override command is pretty good for this case. And we don't know what is CMD and Entrypoint content in the Dockerfile, so we can execute it and automate this process. Image creator knows or should know about Entrypoint and CMD and if he really need to start some extra stuff, he can do it the plugin meta.yaml: meta.yaml#Containers#Container[i]#(Command or Args).

But actually there is one way when we can start entrypoint.sh and then start remote binary, but for me it's looks to much tricky:

So, let's skip guessing where is located entrypoint.sh. Some our images uses wrapper script pattern(some code-ready images, and images for dev containers https://github.com/eclipse/che-devfile-registry/blob/master/arbitrary-users-patch/entrypoint.sh). Such scripts ussualy has such content:

/some-path/entrypont.sh

#!/bin/sh

# fix some permission

exec "$@" # to start command defined in the Dockerfile CMD

Dockerfile

### some useful stuff 

ENTRYPOINT [ "/entrypoint.sh" ]
CMD ["some", "command"]

Currently remote-runtime injection override command(ENTRYPOINT in the Dockerfile), so this entrypoint.sh script never happen, only if sidecar writer defines in the meta.yaml: start entrypoint.sh and than remote binary:

/entrypoint.sh; {PLUGIN_REMOTE_ENDPOINT_EXECUTABLE}.

But we can change this behavior and override args(CMD in the Dockerfile) instead of ENTRYPOINT, than if image has entrypoint.sh wrapper script, this script will be launched and than script starts remote binary by exec "$@". Because our CMD will be overrided to start remote runtime {PLUGIN_REMOTE_ENDPOINT_EXECUTABLE}.

For all another cases plugin writer could take a look image and consider how to override command(ENTRYPOINT) with args(CMD) in the plugin meta.yaml or writer can hardcode in the image start remote binary using env varibles. Maybe plugin writer wants to start some endless process with service for VSCode extension and detach it and then start {PLUGIN_REMOTE_ENDPOINT_EXECUTABLE}.

[benoitf]

I think the plugin writer should only add an "infinite command" like tail -f /dev/null if the container image is not living forever. This is what users do on their devfile when picking up external images.

But IMHO plugin's writer should not care about how injection of Che-Theia remote endpoint binary is managed.
And in another hand, endpoint should respect what has been defined by image creator.

It means also that che can change the logic without impacting at all all plug-ins.

[AndrienkoAleksandr]

So, what do you propose?

[benoitf]

If creating home directory is mandatory for the endpoint, it should be done by plugin-remote code
Uid fix should be done elsewhere ( if images need to be patched)
So no custom entrypoint there, enhance plugin-remote.ts checks that will be included in the all-in-one binary. And if some of requirements are not there, binary should exit with exit code and error message