feat: Add healthcheck command in nerdctl

[subashkotha]

This PR adds support for Docker-compatible health checks in nerdctl run, nerdctl create, and introduces a new nerdctl container healthcheck command to manually trigger health checks.

Key features:

1. Health check configuration via CLI flags (--health-cmd, --health-interval, --health-timeout, etc.)
2. Support for health checks defined in Docker images (HEALTHCHECK in the Dockerfile)
3. Merging logic for health checks:

• CLI flags override image-defined health checks
• Fallback to image-defined health checks if CLI flags not set
• No health check configured by default

4. nerdctl container healthcheck command to manually run health checks
5. Health check configuration is stored as an internal label nerdctl/healthcheck
6. Health state (status and failing streak) is stored in internal label nerdctl/healthstate for quick access
7. Health check results stored in a health.json file in the container’s runtime state directory
8. Tests added for CLI flag parsing, merging behavior, execution of health checks, and health state inspection in nerdctl inspect

Future work (WIP):

1. Automate periodic health checks using systemd.
2. Generate systemd timer and service units based on container lifecycle events.
3. Improve logic to store/fetch health check results.

Related issue - #4157

cc: @Shubhranshu153 @AkihiroSuda

[AkihiroSuda]

CI is failing on Windows

[Shubhranshu153]

reading logs to get current health seems not so robust. i think we should atleast check the possibility of having a db.
@AkihiroSuda thoughts? or having a db for it is over engineering the problem?

[AkihiroSuda]

How could the DB improve the robustness?

[AkihiroSuda]

Maybe ocihook should run healthcheck commands periodically, and serve the health status via a Unix socket?

Then there does not need to be a static health log file nor a DB.

[Shubhranshu153]

db would support atomicity of the writes.
in the case of oci hook is it stored in runc process memory? Not much familiar with it,

[AkihiroSuda]

ocihook is a process executed on events such as "createRuntime" and "postStop":

nerdctl/pkg/ocihook/ocihook.go

Lines 123 to 130 in b8c4b3d

	switch event {
	case "createRuntime":
	return onCreateRuntime(opts)
	case "postStop":
	return onPostStop(opts)
	default:
	return fmt.Errorf("unexpected event %q", event)
	}

https://github.com/opencontainers/runtime-spec/blob/main/runtime.md#lifecycle

ocihook is currently used for CNI, logging, etc.
Periodic health checker could be added here, and it could serve gRPC (or REST) over a Unix socket to provide the latest health status.

[apostasie]

db would support atomicity of the writes.

There is an effort to consolidate atomic, concurrency-safe filesystem operations in internal/filesystem. If needed, these can be used instead of filesystem access in almost all cases.

Generally IMHO we should avoid using the filesystem as an API and instead rely on a higher-level abstraction (eg: store.Store for eg). Leaking implementation details into the consumer (filesystem or db) is bad API, and instead having a storage API will allow swapping out the fs implementation to something else, if need-be.

[subashkotha]

Thanks for the feedback. I'll update the PR to store current health state and failing streak in the container labels, so we no longer need to read the log file during each health check to get current state.

Health check results are still written to a log file, and during inspect we fetch the last five entries to provide recent history. For health.json operations, we’ll use internal/filesystem along with proper locking as recommended to ensure concurrency safety.

[Shubhranshu153]

LGTM. Lets fix the windows test.

[Shubhranshu153]

For the canary errors: compiler issue which the canary is running with go1.25rc. More details available in link
google/go-licenses#312

[Shubhranshu153]

LGTM. Once the fixes are merged we can rebase and do a rebase and run the tests before merge.
Open PR for fixing the failing tests: #4318

@AkihiroSuda can we get a +1 for this. Thank You

[AkihiroSuda]

This doesn't do anything after waiting for the channel?

[subashkotha]

Correct, it doesn't do anything with the value it receives from the channel, it simply drains the channel to prevent a goroutine leak after the process is killed, allowing the goroutine that sends to the channel to complete.

[AkihiroSuda]

Can't we use time.Second here?

[subashkotha]

Sure, these durations are stored as nanoseconds in container labels internally, but I'll express the flag parameters in seconds for improved readability.

[subashkotha]

Hi @AkihiroSuda @Shubhranshu153
Can I get approval on this PR if there are no comments, thanks!

[AkihiroSuda]

Thanks