paketo buildpacks health-checker

[NValanos]

Hi all,

Sorry if this isn't the proper column for such a question.

I've been using paketobuildpacks/builder-jammy-base as a base image to create spring-boot application images through gitlab-ci by using the create command from /cnb/lifecycle/ with quite the success. Now there is a need to add healthcheck mechanism to these images so that, when the image starts running inside a container, it would check the availability of the application through an already exposed url.

The problem is that the image that is created does not include the curl command or something similar in order to check the availability.

I found out that paketo has its own healthcheck buildpack that helps resolve exactly that problem. The question is: How can I include it in the paketobuildpacks/builder-jammy-base image in order to use it during the images creation. As I understand, it needs to be included inside the /cnb/buildpacks/ folder and then somehow be detected during the lifecycle. Is there a go-to way to achieve something like that? If not, is there any workaround?

Thank you in advance

[dmikusa]

Normally, you'd use pack cli or the Spring Boot build tools, and they would handle this for you. You can give them additional buildpacks, and they will dynamically create a builder that has the new buildpacks.

Since you're not using those tools, that's on you to set up. Essentially what those tools are doing is to a.) download that buildpack image, b.) extract the files and c.) put them into a new builder image at the location you mentioned /cnb/buildpacks. After the files are there, you need to update the builder metadata, so the lifecycle knows about the buildpack you added. I believe the file is /cnb/order.toml.

https://github.com/buildpacks/spec/blob/main/platform.md#ordertoml-toml

Then you can run your build and the lifecycle should know about your buildpack.

---

The other option you can do is to make your own builder. You're using https://github.com/paketo-buildpacks/builder-jammy-base, so you can checkout those files. Modify the builder.toml that's listed there and then run pack builder create builder --config builder.toml. You can publish the image it creates in your registery and then use that for the base of your builds.

[NValanos]

Hello again,

Thank you for the support and for the quick response. I did as you recommended and added the healthcheck buildpacks manually (by extracting it from the docker image and manually including it inside the running paketo-buildpacks/builder-jammy-base container). I also removed any unnecessary buildpack from order.toml . As a result, I ended with the following:

[[order]]
  [[order.group]]
    id = "paketo-buildpacks/java"
    version = "18.6.0"
  [[order.group]]
    id = "paketo-buildpacks/health-checker"
    version = "2.9.0"

Also, as show in the health-checker's documentation, I added the flag BP_HEALTH_CHECKER_ENABLED=true inside the /platform/env/ folder using the following:

echo "true" > /platform/env/BP_HEALTH_CHECKER_ENABLED

The process runs but health-checker never uses the flag. That is also shown in the building logs:

...
fail: paketo-buildpacks/[email protected] provides unused hc
ERROR: No buildpack groups passed detection.
ERROR: Please check that you are running against the correct path.
ERROR: failed to detect: no buildpacks participating
Cleaning up project directory and file based variables 00:00
ERROR: Job failed: exit code 1

If I remove it, the process runs smoothly.

Also for reference, the initial order.toml is the following:

[[order]]
  [[order.group]]
    id = "paketo-buildpacks/ruby"
    version = "0.47.6"
[[order]]
  [[order.group]]
    id = "paketo-buildpacks/dotnet-core"
    version = "1.7.1"
[[order]]
  [[order.group]]
    id = "paketo-buildpacks/go"
    version = "4.15.5"
[[order]]
  [[order.group]]
    id = "paketo-buildpacks/java-native-image"
    version = "11.10.0"
[[order]]
  [[order.group]]
    id = "paketo-buildpacks/java"
    version = "18.6.0"
[[order]]
  [[order.group]]
    id = "paketo-buildpacks/web-servers"
    version = "1.4.3"
[[order]]
  [[order.group]]
    id = "paketo-buildpacks/nodejs"
    version = "7.8.1"
[[order]]
  [[order.group]]
    id = "paketo-buildpacks/python"
    version = "2.27.0"
[[order]]
  [[order.group]]
    id = "paketo-buildpacks/procfile"
    version = "5.11.0"

Lastly, another thing that caught my attention is that inside the folder /cnb/buildpacks/paketo-buildpacks_health-checker/2.9.0/bin/ , the build and detect originally seemed to be links to main , but during the copy, they seem to have been created as their own files, with the same size as the main.
I needed to change their permissions in order for this to move on:

    - chmod 777 /cnb/buildpacks/paketo-buildpacks_health-checker/2.9.0/bin/detect
    - chmod 777 /cnb/buildpacks/paketo-buildpacks_health-checker/2.9.0/bin/build
    - chmod 777 /cnb/buildpacks/paketo-buildpacks_health-checker/2.9.0/bin/main

Is that ok?

Sorry for the long post and thank you in advance!

[dmikusa]

echo "true" > /platform/env/BP_HEALTH_CHECKER_ENABLED

This is probably the issue. Try echo -n. By default, echo adds an EOL character and the buildpack is very picky about the values in "boolean" env variables. It does not treat true\n as true.

[dmikusa]

Lastly, another thing that caught my attention is that inside the folder /cnb/buildpacks/paketo-buildpacks_health-checker/2.9.0/bin/ , the build and detect originally seemed to be links to main , but during the copy, they seem to have been created as their own files, with the same size as the main.

Yes, we symlink build and detect to main, so that there's only one actual binary. The main binary has code for both operations. This saves some disk space in the buildpack images, because we use Go and Go includes the Go runtime in the binary. Stuffing them into one binary reduces the size.

I don't think it would be an issue if your extract/copy process puts the actual main binary as both detect and build. That will use more disk space, but the main binary will work for both.