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.
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.
Let's now review the problems we have with the entrypoint styles:
As a workaround, we suggest:
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.