Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Available entrypointStyle options not working with OpenShift-certified Java images #496

Open
aritzbastida opened this issue May 27, 2022 · 1 comment
Labels
status/need-feedback Calling participant to provide feedback
Milestone

Comments

@aritzbastida
Copy link

aritzbastida commented May 27, 2022

We are trying to deploy Spring Cloud Data Flow in OpenShift 4, which is a Kubernetes-certified platform. However, we found out that, currently, none of the entrypoint styles available work with our Java images created with Red Hat S2I (Source-to-Image).

Specifically, we are using the ubi8/openjdk-17 builder image. As you can see in the following excerpt, there is a default CMD instruction in the Dockerfile, but no ENTRYPOINT.

  ...
  # Define the working directory
  WORKDIR /home/jboss
  # Define run cmd
  CMD ["/usr/local/s2i/run"]
  ADD help.md /
## /
## END target image

Let's now review the problems we have with the entrypoint styles:

  • exec: Command line arguments are set in the container "args" attribute. However, the side-effect of this is replacing CMD instruction altogether, and, because there is no ENTRYPOINT, the first argument is interpreted as the executable, resulting in a container creation error.
  • boot: Same as above.
  • shell: Command line arguments are transformed to discrete environment variables (one variable per agument). The container can now start, but Spring Batch jobs now have no way to read the job parameters (expected as command-line arguments). Even if we changed Spring Batch to read from the environment, there would be no way to find out which variables come from the command-line. For example, "run.id" parameter is transformed to "RUN_ID" environment variable. How is Spring Batch supposed to know that is a parameter?

As a workaround, we suggest:

  • For "exec" and "boot" styles, adding a new configuration property to specify the "command" for the container (spec.containers[].command). This would configure the executable, by specifying a explicit entrypoint, and the arguments would be interpreted as intended.
  • For "shell" style, mapping all command line arguments as the value of a single environment variable, the name of which could be configurable. For example, S2I supports JAVA_ARGS variable, which is used by the launch script to append Java arguments. See this issue.

We made local modifications in the source code, and now can start our Java image with any of the 3 styles. If you wish, we can contribute the changes with a PR, for you to review.

@github-actions github-actions bot added the status/need-triage Team needs to triage and take a first look label May 27, 2022
@markpollack
Copy link
Contributor

Please do make the PR, sounds like it would be a great contribution.

@markpollack markpollack added status/need-feedback Calling participant to provide feedback and removed status/need-triage Team needs to triage and take a first look labels Jul 27, 2022
@markpollack markpollack added this to the 2.9.0-M1 milestone Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/need-feedback Calling participant to provide feedback
Projects
None yet
Development

No branches or pull requests

2 participants