Using exec in ENTRYPOINT breaks containers using distroless base images
mattlong-finocomp opened this issue · 4 comments
With changes merged in https://github.com/bmuschko/gradle-docker-plugin/pull/1167/files the entrypoint uses exec by default.
This doesn't work for images based on distroless java because there is no shell access.
It also abandons the vector form of entrypoint arguments ie ["my", "vector", "args"] which is a problem for distroless.
In order to provide options to the applications I work on I've always used the JDK_JAVA_OPTIONS environment variable.
I understand that you can't please everybody, but wanted to make you aware of the impact of the change that was merged in hopes that you might reconsider the change given that people can use ENV vars to provide the options already.
Worst case my workaround is for me to specify my own entrypoint that reverts back to the original form.
Whatever you decide it might be worth documenting either supplying Java OPTs via ENV vars or overriding ENTRYPOINT for images without a shell.
Expected Behavior
When running a docker container built upon a distroless java base image, the container runs successfully.
Current Behavior
Seeing the following error:
com.github.dockerjava.api.exception.BadRequestException: Status 400: {"message":"failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory: unknown"}
Context
Distroless images remove shell access as another layer of security hardening.
Switching away from the vector form of arguments is also an issue. See https://github.com/GoogleContainerTools/distroless#entrypoints
Steps to Reproduce (for bugs)
From https://github.com/mattlong-finocomp/gradle-docker-plugin-error
Run gradlew buildImage
In terminal: docker run bmuschko/java-app:latest
Your Environment
Pop!OS 20.04 (Linux)
Java 17
I am probably going to revert the change. It seems like it has a strong impact on other use cases. Thanks for the pointer to JDK_JAVA_OPTIONS. I wasn't even aware of this environment variable. You are right. We'll need to add more documentation to customize the generated Dockerfile.
@bmuschko JAVA_TOOL_OPTIONS might also be relevant, https://docs.oracle.com/en/java/javase/11/troubleshoot/environment-variables-and-system-properties.html#GUID-BE6E7B7F-A4BE-45C0-9078-AA8A66754B97 depending on exactly where you need to hook into java options.