Healthcheck Integration?

[mikerimov]

Hi All,

First off, thank you for creating this amazing tool for layer optimization. I love it!

Trying to get the health-checker wired up correctly in my app.

Been using the spring-boot-maven-plugin with the following buildpacks: (Non spring boot app)

Config Info:

                                        <buildpacks>
                                            <buildpack>gcr.io/paketo-buildpacks/amazon-corretto:7.8.1</buildpack>
                                            <buildpack>gcr.io/paketo-buildpacks/health-checker:1.2.0</buildpack>
                                            <buildpack>gcr.io/paketo-buildpacks/java:8.6.0</buildpack>
                                        </buildpacks>

With the following config values health-check specific:

                                          <BP_HEALTH_CHECKER_ENABLED>true</BP_HEALTH_CHECKER_ENABLED>
                                            <BP_HEALTH_CHECKER_DEPENDENCY>thc</BP_HEALTH_CHECKER_DEPENDENCY>
                                            <THC_PORT>8080</THC_PORT>
                                            <THC_PATH>/healthcheck</THC_PATH>

Firing up the container locally, I can clearly see thc installed and if I execute /cnb/process/health-check it attempts to connect to the correct path and port. Great!

The problem
I don't see that there's a docker HEALTHCHECK status being wired in? There's no status being created when I launch it. (Confirmed by AWS Fargate which reports the container status as UNKNOWN) I feel like I'm missing something completely obvious. What's the final step with the buildpacks to get the docker healthcheck directive wired in?

Thanks in advance!

[dmikusa]

I don't see that there's a docker HEALTHCHECK status being wired in?

The HEALTHCHECK setting is specific to Dockerfiles. I'm not sure what it's doing off-hand, but if anyone knows we might be able to replicate that.

The way I've used this is with docker run and arguments.

      --health-cmd string              Command to run to check health
      --health-interval duration       Time between running the check (ms|s|m|h) (default 0s)
      --health-retries int             Consecutive failures needed to report unhealthy
      --health-start-period duration   Start period for the container to initialize before starting health-retries countdown (ms|s|m|h) (default 0s)
      --health-timeout duration        Maximum time to allow one check to run (ms|s|m|h) (default 0s)

There's no status being created when I launch it. (Confirmed by AWS Fargate which reports the container status as UNKNOWN) I feel like I'm missing something completely obvious. What's the final step with the buildpacks to get the docker healthcheck directive wired in?

I don't know about Fargate off the top of my head, but you'd need to set the health check settings in a similar way. The HEALTHCHECK setting in Dockerfile must be adding some sort of metadata to the image itself, so when you run the image on your orchestrator it can know what health check to use. If anyone is aware of the metadata required, we could investigate adding that to the health-checker buildpack.

[mikerimov]

So yes, apparently fargate CAN configure run commands for healthcheck, and I can see how that would be what you were planning for. I'll run with that for now.

s for what the docker healtcheck build directive is doing... doing these are the 3 lowest level specs that I found about the config info.

• https://github.com/opencontainers/image-spec/blob/3a7f492d3f1bcada656a7d8c08f3f9bbd05e7406/media-types.md#applicationvndociimageconfigv1json
• https://github.com/opencontainers/image-spec/blob/3a7f492d3f1bcada656a7d8c08f3f9bbd05e7406/config.md#properties
• https://github.com/moby/moby/blob/master/image/spec/v1.2.md

At least between the 3 it shows where the metadata is stored and where it is updated when the healtcheck is run. Hopefully this helps?

Thank you for the reply!

[dmikusa]

Thanks, that's very helpful. I was looking at the buildpack spec to see if it's possible to export this information and it is not presently possible. I was asking around and I think it's probably something we can get added to the buildpack spec though, so that would enable us to expose this information from buildpacks as well. 🤞