I upgraded my application from Spring Boot 3.1 to Spring Boot 3.3. After upgrading the Paketo Buildpack for Health Checkers is not working anymore. It uses the wrong port. My health endpoint is on 8081
.
POM
This configuration worked with Spring Boot 3.1, but not with Spring Boot 3.3.
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<configuration>
<image>
<env>
<BP_HEALTH_CHECKER_ENABLED>true</BP_HEALTH_CHECKER_ENABLED>
<THC_PORT>8081</THC_PORT>
<THC_PATH>/health</THC_PATH>
</env>
<buildpacks>
<buildpack>gcr.io/paketo-buildpacks/adoptium</buildpack>
<buildpack>urn:cnb:builder:paketo-buildpacks/java</buildpack>
<buildpack>gcr.io/paketo-buildpacks/health-checker:latest</buildpack>
</buildpacks>
</image>
</configuration>
<goals>
<goal>build-image-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
Console
With Spring Boot 3.3 the container is shown as unhealthy.
ubuntu@mymachine.aws:~$ docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
02700535df01 gitlab.mycompany.com:5005/mygroup/myservice:17 "/cnb/process/web" 19 minutes ago Up 19 minutes (unhealthy) 8081/tcp myservice
Research
I read Paketo Buildpack for Health Checkers 2.0.0:
- Removes the ability to set
THC_*
env variables at build time and have them included in the image. This is unfortunately a side effect of removing the process type in 1.). Because we're not using a process, thethc
binary is not being started by the launcher and so even if we bake the env variables into the image, they will not be set when thethc
binary runs. All settings env variables forthc
must now be set at runtime.
However, adding
--env THC_PORT=8081
--env THC_PATH=/health
to the run command didn't solve the problem. The container is still unhealthy.
I checked the variables with env
in the container and both are listed with the right values.
cnb@02700535df01:/workspace$ env
HOSTNAME=02700535df01
CNB_PLATFORM_API=0.12
CNB_LAYERS_DIR=/layers
CNB_APP_DIR=/workspace
PWD=/workspace
HOME=/home/cnb
TERM=xterm
THC_PORT=8081
SHLVL=1
CNB_DEPRECATION_MODE=quiet
THC_PATH=/health
PATH=/cnb/process:/cnb/lifecycle:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
_=/usr/bin/env
I checked the health endpoint manually and it shows up.
ubuntu@mymachine.aws:~$ curl http://172.17.0.20:8081/health
{"status":"UP"}
Question
How to change the default port and path of the health checker?
You're almost there. It looks like you're still using the old health check process path, /cnb/process/web
.
From the release notes:
The process type for /cnb/process/health-check has been removed. This while convenient was not safe. It would cause the exec.d helpers to run multiple times for your application, which adds overhead but can also cause problems depending on what the exec.d helpers are doing exactly. See #87 for details.
So in addition to adding the environment variables, you need to change --health-cmd
to /workspace/health-check
or to /layers/paketo-buildpacks_health-checker/thc/bin/thc
, the former is a symlink to the latter.
Ex: docker run -it -e THC_PATH=/actuator/health -e THC_PORT=8081 --health-cmd /layers/paketo-buildpacks_health-checker/thc/bin/thc --health-interval 1s --health-timeout 1s --health-retries 2 --health-start-period 15s -p 8080:8080 apps/maven
You can also remove <THC_PATH>/health</THC_PATH>
and <THC_PORT>8081</THC_PORT>
from your pom.xml. That won't hurt anything, but they're no longer read by the buildpack at build time.
If that doesn't work for some reason, or someone else is reading this having similar issue, run docker inspect
on the failing container and the output will include information about why the health check failed.
I apologize for needing to make this change, but running the health check through the launcher was causing a number of subtle problems for Java users. It was important to get this fixed for everyone.
I'm hoping that in the future, buildpacks will be able to output the metadata required for Docker to read health check information out of the image, so this will be less of an issue. I've got an RFC open about that here -> https://github.com/buildpacks/rfcs/pull/309