在 distroless 环境中将可自定义的选项传递给 GraalVM 映像执行

Question

For context, I'm building a java application compiled to GraalVM native image running on a distroless docker image in Kubernetes.

I've been trying to do something rather simple and hit a wall: I'd like to set custom heap size limits per environment via -XmxNNN . To do that, the options with which I'd like to run the application would be held in an environment variable. The problem arises due to the usage of a distroless image - which doesn't have bash and so ENTRYPOINT /application $OPTIONS doesn't work.

Is there an environment variable GraalVM supports on its own, or any other way of setting this?

I dont want to:

• hardcode the values in the Docker image
• hardcode the values by predefining them during native-image build

Answer 1

I am not sure if it will work but please, try setting the JAVA_TOOL_OPTIONS environment variable to the desired value:

JAVA_TOOL_OPTIONS=-XmxNNN

From the documentation :

This environment variable allows you to specify the initialization of tools, specifically the launching of native or Java programming language agents using the -agentlib or -javaagent options. In the following example the environment variable is set so that the HPROF profiler is launched when > the application is started:

$ export JAVA_TOOL_OPTIONS="-agentlib:hprof"

This variable can also be used to augment the command line with other options for diagnostic purposes. For example, you can supply the -XX:OnError option to specify a script or command to be executed when a fatal error occurs.

The GraalVM documentation itself provides an example of use as well, although in a different context.

Answer 2

You could use busybox to get a shell inside a distroless container:

FROM gcr.io/distroless/base

...

COPY --from=amd64/busybox:1.31.1 /bin/busybox /busybox/busybox
RUN ["/busybox/busybox", "--install", "/bin"]

CMD ["/bin/sh", "-c", "java -version"]

You can find an example to this kind of Dockerfile here .

But I don't think this busybox shell is necessary needed.

Altough ENTRYPOINT /application $OPTIONS does not work, this will work ENTRYPOINT ["myapp", "arguments"]

Note that distroless images by default do not contain a shell. That means the Dockerfile ENTRYPOINT command, when defined, must be specified in vector form, to avoid the container runtime prefixing with a shell.

source: github