Unable to pass command arguments to docker image in command line mode

[ivansenic]

Describe the bug

When implementing a picocli command line mode application, there is an issue that you can not pass the command and arguments to the docker image. I tried defining the QUARKUS_ARGS as environment variable, but this does not work as well.

Is there any way this can be specified in the docker run command?

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

1. quarkus create cli
2. quarkus image build docker
3. docker run [IMAGE_NAME] - how to pass command options and params here?

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @ebullient (picocli)

[geoand]

I just tried building a container image (using the docker extension) for a sample command line application and the parameters did get picked up when running using docker run someimage my_param1 my_param2.

Can you give it a try please?

[ivansenic]

Here is my output. first without params and then with:

[11:23:28] ise:c2 <ise-format-poms-v1>$ docker run ise/something:1.0.0-SNAPSHOT
Starting the Java application using /opt/jboss/container/java/run/run-java.sh ...
INFO exec  java -Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager -XX:MaxRAMPercentage=50.0 -XX:+UseParallelGC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:+ExitOnOutOfMemoryError -cp "." -jar /deployments/quarkus-run.jar 
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2023-06-28 09:23:38,480 WARN  [io.qua.config] (main) Unrecognized configuration key "quarkus.http.host" was provided; it will be ignored; verify that the dependency extension for this configuration is set or that you did not make a typo
2023-06-28 09:23:38,632 INFO  [io.quarkus] (main) something 1.0.0-SNAPSHOT on JVM (powered by Quarkus 3.1.2.Final) started in 0.421s. 
2023-06-28 09:23:38,632 INFO  [io.quarkus] (main) Profile prod activated. 
2023-06-28 09:23:38,632 INFO  [io.quarkus] (main) Installed features: [cdi, picocli, smallrye-context-propagation]
Hello picocli, go go commando!
2023-06-28 09:23:38,722 INFO  [io.quarkus] (main) something stopped in 0.014s
[11:23:39] ise:c2 <ise-format-poms-v1>$ docker run ise/something:1.0.0-SNAPSHOT test
[11:23:41] ise:c2 <ise-format-poms-v1>$ docker run ise/something:1.0.0-SNAPSHOT test test

Seems impossible since docker run command expects command before the args, what is the command?

$ docker run --help

Usage:  docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

[geoand]

docker run --rm gandrian/getting-started-command-mode:1.0.0-SNAPSHOT ->

exec java -Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager -XX:+ExitOnOutOfMemoryError -cp . -jar /deployments/quarkus-run.jar
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2023-06-28 09:26:18,177 WARN  [io.qua.config] (main) Unrecognized configuration key "quarkus.http.host" was provided; it will be ignored; verify that the dependency extension for this configuration is set or that you did not make a typo
2023-06-28 09:26:18,255 INFO  [io.quarkus] (main) getting-started-command-mode 1.0.0-SNAPSHOT on JVM (powered by Quarkus 999-SNAPSHOT) started in 0.219s. 
2023-06-28 09:26:18,255 INFO  [io.quarkus] (main) Profile prod activated. 
2023-06-28 09:26:18,255 INFO  [io.quarkus] (main) Installed features: [cdi, smallrye-context-propagation]
hello commando
2023-06-28 09:26:18,266 INFO  [io.quarkus] (main) getting-started-command-mode stopped in 0.009s

while docker run --rm gandrian/getting-started-command-mode:1.0.0-SNAPSHOT george ->

exec java -Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager -XX:+ExitOnOutOfMemoryError -cp . -jar /deployments/quarkus-run.jar george
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2023-06-28 09:26:50,186 WARN  [io.qua.config] (main) Unrecognized configuration key "quarkus.http.host" was provided; it will be ignored; verify that the dependency extension for this configuration is set or that you did not make a typo
2023-06-28 09:26:50,264 INFO  [io.quarkus] (main) getting-started-command-mode 1.0.0-SNAPSHOT on JVM (powered by Quarkus 999-SNAPSHOT) started in 0.222s. 
2023-06-28 09:26:50,264 INFO  [io.quarkus] (main) Profile prod activated. 
2023-06-28 09:26:50,264 INFO  [io.quarkus] (main) Installed features: [cdi, smallrye-context-propagation]
hello george
2023-06-28 09:26:50,275 INFO  [io.quarkus] (main) getting-started-command-mode stopped in 0.009s

[ivansenic]

@geoand Haha, awesome.. Let me redo the whole process, upgrade my cli to latest and try to get same as you.. That's what I am actually looking for..

[ivansenic]

OK I think I know what's happening.. So checking your example, seems that the Dockerfile there (https://github.com/quarkusio/quarkus-quickstarts/blob/main/getting-started-command-mode/src/main/docker/Dockerfile.jvm) is not same as the Dockerfile that is created when you run quarkus create cli. This gets generated using the quarkus command:

####
# This Dockerfile is used in order to build a container that runs the Quarkus application in JVM mode
#
# Before building the container image run:
#
# ./mvnw package
#
# Then, build the image with:
#
# docker build -f src/main/docker/Dockerfile.jvm -t quarkus/cli-jvm .
#
# Then run the container using:
#
# docker run -i --rm -p 8080:8080 quarkus/cli-jvm
#
# If you want to include the debug port into your docker image
# you will have to expose the debug port (default 5005 being the default) like this :  EXPOSE 8080 5005.
# Additionally you will have to set -e JAVA_DEBUG=true and -e JAVA_DEBUG_PORT=*:5005
# when running the container
#
# Then run the container using :
#
# docker run -i --rm -p 8080:8080 quarkus/cli-jvm
#
# This image uses the `run-java.sh` script to run the application.
# This scripts computes the command line to execute your Java application, and
# includes memory/GC tuning.
# You can configure the behavior using the following environment properties:
# - JAVA_OPTS: JVM options passed to the `java` command (example: "-verbose:class")
# - JAVA_OPTS_APPEND: User specified Java options to be appended to generated options
#   in JAVA_OPTS (example: "-Dsome.property=foo")
# - JAVA_MAX_MEM_RATIO: Is used when no `-Xmx` option is given in JAVA_OPTS. This is
#   used to calculate a default maximal heap memory based on a containers restriction.
#   If used in a container without any memory constraints for the container then this
#   option has no effect. If there is a memory constraint then `-Xmx` is set to a ratio
#   of the container available memory as set here. The default is `50` which means 50%
#   of the available memory is used as an upper boundary. You can skip this mechanism by
#   setting this value to `0` in which case no `-Xmx` option is added.
# - JAVA_INITIAL_MEM_RATIO: Is used when no `-Xms` option is given in JAVA_OPTS. This
#   is used to calculate a default initial heap memory based on the maximum heap memory.
#   If used in a container without any memory constraints for the container then this
#   option has no effect. If there is a memory constraint then `-Xms` is set to a ratio
#   of the `-Xmx` memory as set here. The default is `25` which means 25% of the `-Xmx`
#   is used as the initial heap size. You can skip this mechanism by setting this value
#   to `0` in which case no `-Xms` option is added (example: "25")
# - JAVA_MAX_INITIAL_MEM: Is used when no `-Xms` option is given in JAVA_OPTS.
#   This is used to calculate the maximum value of the initial heap memory. If used in
#   a container without any memory constraints for the container then this option has
#   no effect. If there is a memory constraint then `-Xms` is limited to the value set
#   here. The default is 4096MB which means the calculated value of `-Xms` never will
#   be greater than 4096MB. The value of this variable is expressed in MB (example: "4096")
# - JAVA_DIAGNOSTICS: Set this to get some diagnostics information to standard output
#   when things are happening. This option, if set to true, will set
#  `-XX:+UnlockDiagnosticVMOptions`. Disabled by default (example: "true").
# - JAVA_DEBUG: If set remote debugging will be switched on. Disabled by default (example:
#    true").
# - JAVA_DEBUG_PORT: Port used for remote debugging. Defaults to 5005 (example: "8787").
# - CONTAINER_CORE_LIMIT: A calculated core limit as described in
#   https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt. (example: "2")
# - CONTAINER_MAX_MEMORY: Memory limit given to the container (example: "1024").
# - GC_MIN_HEAP_FREE_RATIO: Minimum percentage of heap free after GC to avoid expansion.
#   (example: "20")
# - GC_MAX_HEAP_FREE_RATIO: Maximum percentage of heap free after GC to avoid shrinking.
#   (example: "40")
# - GC_TIME_RATIO: Specifies the ratio of the time spent outside the garbage collection.
#   (example: "4")
# - GC_ADAPTIVE_SIZE_POLICY_WEIGHT: The weighting given to the current GC time versus
#   previous GC times. (example: "90")
# - GC_METASPACE_SIZE: The initial metaspace size. (example: "20")
# - GC_MAX_METASPACE_SIZE: The maximum metaspace size. (example: "100")
# - GC_CONTAINER_OPTIONS: Specify Java GC to use. The value of this variable should
#   contain the necessary JRE command-line options to specify the required GC, which
#   will override the default of `-XX:+UseParallelGC` (example: -XX:+UseG1GC).
# - HTTPS_PROXY: The location of the https proxy. (example: "[email protected]:8080")
# - HTTP_PROXY: The location of the http proxy. (example: "[email protected]:8080")
# - NO_PROXY: A comma separated lists of hosts, IP addresses or domains that can be
#   accessed directly. (example: "foo.example.com,bar.example.com")
#
###
FROM registry.access.redhat.com/ubi8/openjdk-11:1.15

ENV LANGUAGE='en_US:en'


# We make four distinct layers so if there are application changes the library layers can be re-used
COPY --chown=185 target/quarkus-app/lib/ /deployments/lib/
COPY --chown=185 target/quarkus-app/*.jar /deployments/
COPY --chown=185 target/quarkus-app/app/ /deployments/app/
COPY --chown=185 target/quarkus-app/quarkus/ /deployments/quarkus/

EXPOSE 8080
USER 185
ENV AB_JOLOKIA_OFF=""
ENV JAVA_OPTS="-Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
ENV JAVA_APP_JAR="/deployments/quarkus-run.jar"

The above one misses the ENTRYPOINT and that's the problem..

Seems that the Dockerfile in the example repository project is completely different and customized, different base images and setup. Any reason to have it like that? Why in the create command, the Dockerfile is not created appropriately for the cli app?

[geoand]

Seems that the Dockerfile in the example repository project is completely different and customized, different base images and setup. Any reason to have it like that? Why in the create command, the Dockerfile is not created appropriately for the cli app?

Not sure, @maxandersen ?

[ebullient]

depends on the template in use for project create, but I'll guess we didn't customize that template for CLI apps. I would also guess that the getting started project was made awhile ago, and has remained static, while templates used by the CLI for project creation have been updated several times...

[gsmet]

Hmmm, that's weird because someone implemented something to update the Dockerfiles in the quickstarts. I will have a look.

[gsmet]

OK there are two issues here:

• I think it was a mistake to remove the ENTRYPOINT entry in the Dockerfiles, I will create a PR to restore it
• Dockerfiles for getting-started* were not updated as they were not following the *-quickstart convention. I will fix it too.

[gsmet]

• Restore ENTRYPOINT in Dockerfile templates #34494
• Include getting-started-* when updating the Dockerfiles quarkus-release#5

Thanks for taking the time to report this and being thorough.