Provide a way to use a custom entrypoint which is not a java command

[rmannibucau]

Description of the issue:

Current jib is too opinionated on how to run a java command, even for spring boot apps it is limiting.
Allowing to run a script would be very beneficial for the whole ecosystem.

Expected behavior:

Entrypoint is configurable and can take any command.
It would be neat to synchronize src/main/jib/scripts folder into the image (same layer than the build classes?) to make it smooth and easy to maintain for teams.

[coollog]

Hi @rmannibucau , what kind of things are you doing in your startup script?

gcr.io/distroless/java by design does not include a shell to be able to run arbitrary scripts - it only contains the JVM. If you would like to use a base image that has a shell, gcr.io/distroless/java:debug is an option (the executables are under /busybox/, not /bin/ - so /busybox/sh for eg.).

We generate the entrypoint to provide a easy no-setup way to run the Jib-built container, but this entrypoint can be changed at runtime.

With Docker, you would run the image with docker run --entrypoint <the new entrypoint> <image name>.

For a Kubernetes Pod, it would look like:

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: <name>
    image: <image name>
    command: ['a', 'new', 'entrypoint', 'command']

[rmannibucau]

I'm using this one https://github.com/apache/meecrowave/blob/trunk/meecrowave-maven-plugin/src/main/resources/bin/meecrowave.sh and want to keep the existing config the "API" of my image.

I also want it to be built-in and not rely on a config (--entrypoint) I can't on some cloud provider :(.

[coollog]

@rmannibucau Do you mind sharing which cloud provider does not support an entrypoint config when running a container?

[rmannibucau]

ECS had a lot of issues with that originally (there is still the disclaimer https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html). Also it is generally not desired when you have an ops team which doesn't know what it deploys. I think it is a quick win to support something else than java assuming the script is a portable sh script and it runs a java command at the end - think to tomcat use case where you want to reuse tomcat well known script.

[coollog]

Ah okay. The considerations for allowing an arbitrary entrypoint for a Jib-built image is that:

• we use gcr.io/distroless/java as a base, which won't be able to support most custom entrypoints, so the arbitrary entrypoint should most likely not be a configuration on Jib
• a user could re-package the image with Docker by just using the Jib-built image as FROM and settings a new ENTRYPOINT, but that requires Docker to do so
• another option would be for us to provide a separate plugin that can take an image and set new entrypoints and other container configurations, as well as possibly even doing image merges like suggested in Allow to merge images #580

[rmannibucau]

If you take a custom FROM then any script can work so the plugin can just checks from is set or fail in such a case, no?

Agree it can be another mojo (not plugin ;))

[coollog]

@rmannibucau do you mean using a custom base image in Jib? (That can be configured already)
Agreed that it could just be another mojo/task too.

[rmannibucau]

Yep, im happy to push a meecrowave image, just need to ensure jib pushes the bin and libs in right folders then (same would apply for tomcat)

[patflynn]

@rmannibucau it could be worth experimenting with trying to get meecrowave to fit into the jib model rather than the other way around. A lot of what's in the meecrowave.sh seems unnecessary in the context of a jib container.

[coollog]

@rmannibucau Yep, if you use a custom base image, Jib will have all the files in that base image be in the same file paths in the final Jib image as in the base image.

[rmannibucau]

You can make it fit jib without any work (classpath deploymznt works with Cli main) but you dont want since ops know very well tomcat admin and meecrowave is a plain copy. It is the typical "practical for ops" vs "easy for dev" choice. Also being able to customize env in prebuilt scripts make it smooth compare to a long docker command and assuming you can do all the tuning in cloud providers (we are far from "image means portable" world in the cloud sadly).

[ccope]

I'm running into an issue where I have multiple container configs that tune the JVM differently. I want to be able to just pass those settings into a single docker image, but CMD arguments get appended after the classname and get misinterpreted as the class to run. The previous build tool I was using got around this by making the entrypoint a shell script which could rearrange the arguments to satisfy the java command.

[coollog]

Requesting more comments from @GoogleContainerTools/java-tools .

@ccope You can set JVM flags using the container.jvmFlags configuration parameter. Also, you can set additional JVM flags when running an image with JAVA_TOOL_OPTIONS.