Hi, I've created an empty gradle based Spring Boot project to test building it with Gitlab CI.
I'm running: DOCKER_HOST=tcp://docker:2375 ./gradlew -Dorg.gradle.jvmargs=-Xmx4g clean bootBuildImage --imageName=tag.
The command is running in a podman container, that has no docker installed, but podman/docker is available via the DOCKER_HOST environment variable.
Problem: It seems that the docker environment is ignored for the build stage?
The log I receive is:
``Downloading https://services.gradle.org/distributions/gradle-7.6-bin.zip
...........10%............20%...........30%............[40](xxx)%............50%...........60%............70%............80%...........90%............100%
Welcome to Gradle 7.6!
Here are the highlights of this release:
- Added support for Java 19.
- Introduced--rerun` flag for individual task rerun.
- Improved dependency block for test suites to be strongly typed.
- Added a pluggable system for Java toolchains provisioning.
For more details see https://docs.gradle.org/7.6/release-notes.html
Starting a Gradle Daemon (subsequent builds will be faster)
Task :clean UP-TO-DATE Task :compileJava Task :processResources Task :classes Task :bootJarMainClassName Task :bootJar Task :bootBuildImage Building image 'tag' Pulling builder image 'docker.io/paketobuildpacks/builder:base' .................................................. Pulled builder image 'docker.io/paketobuildpacks/builder@sha256:f911ecad3ce001830c384cfe761abddead8c5e5e5bceb95cd12b00af23f146da' Pulling run image 'docker.io/paketobuildpacks/run:base-cnb' .................................................. Pulled run image 'docker.io/paketobuildpacks/run@sha256:2c1875a57b860fbf7a01012f6ba859[47](xxx(xx)e75fb965c' Executing lifecycle version v0.15.3 Using build cache volume 'pack-cache-470b9abee036.build' Running creator [creator] ERROR: failed to initialize docker client: failed to connect to docker socket: dial unix /var/run/docker.sock: connect: connection refused```
Comment From: scottfrederick
When the Spring Boot Gradle plugin bootBuildImage task is used, it calls the Docker Engine API to download a CNB builder image and configure it. It then runs the builder image, and the builder image does the real work of creating the image using buildpacks. The code in the builder image also needs access to the Docker Engine API.
Pulling builder image 'docker.io/paketobuildpacks/builder:base' .................................................. Pulled builder image 'docker.io/paketobuildpacks/builder@sha256:f911ecad3ce001830c384cfe761abddead8c5e5e5bceb95cd12b00af23f146da' Pulling run image 'docker.io/paketobuildpacks/run:base-cnb' .................................................. Pulled run image 'docker.io/paketobuildpacks/run@sha256:2c1875a57b860fbf7a01012f6ba859[47](xxx(xx)e75fb965c'
This output shows that the Spring Boot plugin is able to successfully communicate with the Docker Engine to pull images, using the value of DOCKER_HOST.
Executing lifecycle version v0.15.3 Using build cache volume 'pack-cache-470b9abee036.build' Running creator [creator] ERROR: failed to initialize docker client: failed to connect to docker socket: dial unix /var/run/docker.sock: connect: connection refused```
This shows that the lifecycle process inside the builder container is using its default /var/run/docker.sock address to talk to the Docker Engine API, which is not available. The value of DOCKER_HOST also needs to be made available to the builder container.
You should be able to do this with some additional configuration. I'm not sure exactly what will work best in your scenario, but you can look at the suggested configuration for podman, or try setting DOCKER_HOST directly in the environment passed to the builder process.
Comment From: ncioj10
Thank you for your quick feedback! It was actually really helpful because it made me think about the actual setup. I fixed the problem by taking the paketo images directly and not using the bootBuildImage command. Is there a documentation of the standard parameters for paketo that are being used by the bootBuildImage command?
If anybody in the future wants to do this with Gitlab CI, that is my configuration:
image: paketobuildpacks/builder
stages:
- build
# We somehow need to access GitLab Container Registry with the Paketo lifecycle
# So we simply create ~/.docker/config.json as stated in https://stackoverflow.com/a/41710291/4964553
before_script:
- mkdir ~/.docker
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_JOB_TOKEN\"}}}" >> ~/.docker/config.json
build-image:
stage: build
variables:
BP_JVM_VERSION: "17"
script:
- mkdir -p platform/env
- echo "17" >> platform/env/BP_JVM_VERSION
- /cnb/lifecycle/creator -app=. -platform platform $CI_REGISTRY_IMAGE:latest
Based on this with modifications for JDK 17: Config .
Comment From: scottfrederick
Is there a documentation of the standard parameters for paketo that are being used by the bootBuildImage command?
This is the only place we have CNB builder defaults documented: https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#build-image.customization.
If you are asking about parameters used when invoking the CNB lifecycle as you are now doing directly, we don't explicitly document those. You can see what we're doing internally here: https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-tools/spring-boot-buildpack-platform/src/main/java/org/springframework/boot/buildpack/platform/build/Lifecycle.java#L158-L186