Cannot create a container image using quarkus container image support for buildpacks, if a custom docker host is required.
Discovered because the underlying library used does not have any magic to determine docker socket paths on macos. When using podman rootless on macos, the docker socket path is not at any location tested by the library, so must be configured manually.
Sadly, the library's DSL builder has a bug as used by quarkus, where editing an existing docker config object to add a docker host, does not in fact, result in the docker socket being configured as expected. The true fix will come with an update to the underlying library, but until then, we can resolve this within Quarkus's usage by avoiding use of the edit capability, and just configuring the docker config object once.
Expected behavior
Container image buildpack extension should create an application image and honor a custom docker host, either via env var, or via quarkus config property.
Actual behavior
Container image buildpack build will fail, and if debug logs for the library are gathered, will indicate the underlying library assumed /var/run/docker.sock when run from macos, regardless of the value of DOCKER_HOST or any config var passed.
If a custom docker host is passed as config to the buildpack extension, then quarkus logs will indicate that host is being used, the library logs will then contradict this and show the /var/run/docker.sock value is used instead (due to the bug related to the DSL processing of editDockerConfig)
The build will fail, because the docker socket mounted into the build-time containers is incorect.
How to Reproduce?
On a working system, move docker.sock to somewhere else, export the new location as DOCKER_HOST env var, build quarkus project using buildpacks container image extension, build will fail.
Output of uname -a or ver
does not matter.
Output of java -version
does not matter.
Quarkus version or git rev
3.16 or above
Build tool (ie. output of mvnw --version or gradlew --version)
michalvavrik
commented
1 day ago
Describe the bug
Cannot create a container image using quarkus container image support for buildpacks, if a custom docker host is required.
Discovered because the underlying library used does not have any magic to determine docker socket paths on macos. When using podman rootless on macos, the docker socket path is not at any location tested by the library, so must be configured manually.
Sadly, the library's DSL builder has a bug as used by quarkus, where editing an existing docker config object to add a docker host, does not in fact, result in the docker socket being configured as expected. The true fix will come with an update to the underlying library, but until then, we can resolve this within Quarkus's usage by avoiding use of the edit capability, and just configuring the docker config object once.
Expected behavior
Container image buildpack extension should create an application image and honor a custom docker host, either via env var, or via quarkus config property.
Actual behavior
Container image buildpack build will fail, and if debug logs for the library are gathered, will indicate the underlying library assumed
/var/run/docker.sockwhen run from macos, regardless of the value of DOCKER_HOST or any config var passed.If a custom docker host is passed as config to the buildpack extension, then quarkus logs will indicate that host is being used, the library logs will then contradict this and show the
/var/run/docker.sockvalue is used instead (due to the bug related to the DSL processing of editDockerConfig)The build will fail, because the docker socket mounted into the build-time containers is incorect.
How to Reproduce?
On a working system, move docker.sock to somewhere else, export the new location as DOCKER_HOST env var, build quarkus project using buildpacks container image extension, build will fail.
Output of
uname -aorverdoes not matter.
Output of
java -versiondoes not matter.
Quarkus version or git rev
3.16 or above
Build tool (ie. output of
mvnw --versionorgradlew --version)should not matter as long as extension is driven
Additional information
No response