build: bump docker-compose to v2.24.5, set healthcheck.start_interval to 1s in Docker v25+

[stasadev]

The Issue

It's time to update docker-compose.

The most significant change in v2.24.0:

Breaking change ⚠️
service hash computation logic has been updated to fully ignore replicas/scale. Due to this change, after upgrade all services will be recreated.

How This PR Solves The Issue

• Bumps docker-compose
• Adds a new custom function templateCanUse(feature string) for use in templates, which can perform more complex checks on the go side.
• Adds healthcheck.start_interval (default is 5s and we use 1s) when it is really available (only for Docker Engine API 1.44+, i.e. for Docker v25+) https://docs.docker.com/engine/reference/builder/#healthcheck

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-windows-amd64-installer.zip

See Testing a PR

[stasadev]

The new docker-compose has new aggressive checks, tests are failing:

can't set healthcheck.start_interval as feature require Docker Engine v25 or later

Related issue:

• Regression in docker-compose: can't set healthcheck.start_interval as feature require Docker Engine 1.25 or later docker-library/docker#473

[rfay]

Pretty weird! Nice job chasing it. But it needs to be fixed somewhere or we're stuck with old compose. Seems like compose bug.

[stasadev]

Yes, I will see what can be changed.

[rfay]

Thanks for working on this, I'm probably going to be OK with it, but it does look fragile for the future. I'd sure rather it be fixed in docker-compose. Interested in doing a PR there?

[rfay]

Let's use DockerEngineVersion here

[stasadev]

I decided to use a different technique: introduce a new custom function templateCanUse(feature string) for use in templates, which can perform more complex checks on the go side.

[stasadev]

I'd sure rather it be fixed in docker-compose.

I think they made a reasonable change with error, because healthcheck.start_interval didn't work before Docker v25 and should be considered an invalid option.

it does look fragile for the future

Agree, and for this reason I added a check specifically for the Docker API version https://docs.docker.com/engine/api/#api-version-matrix
This API version (e.g. 1.44) is much more stable than the Docker version (e.g. 25.0.1). The same comparison is used inside docker-compose.

[stasadev]

Looking deeper into the code base, there is a check for the minimum version of Docker to use with DDEV:

ddev/pkg/dockerutil/dockerutils.go

Lines 1733 to 1739 in 2defedb

	// DockerVersionConstraint is the current minimum version of Docker required for DDEV.
	// See https://godoc.org/github.com/Masterminds/semver#hdr-Checking_Version_Constraints
	// for examples defining version constraints.
	// REMEMBER TO CHANGE docs/ddev-installation.md if you touch this!
	// The constraint MUST HAVE a -pre of some kind on it for successful comparison.
	// See https://github.com/ddev/ddev/pull/738.. and regression https://github.com/ddev/ddev/issues/1431
	var DockerVersionConstraint = ">= 20.10.0-alpha1"

And it does some exotic things in comparison, like removing _ce for OpenSUSE (they add this suffix to the version):

ddev/pkg/dockerutil/dockerutils.go

Lines 772 to 783 in 2defedb

	// CheckDockerVersion determines if the Docker version of the host system meets the provided version
	// constraints. See https://godoc.org/github.com/Masterminds/semver#hdr-Checking_Version_Constraints
	// for examples defining version constraints.
	func CheckDockerVersion(versionConstraint string) error {
	defer util.TimeTrack()()
	currentVersion, err := GetDockerVersion()
	if err != nil {
	return fmt.Errorf("no docker")
	}
	// If Docker version has "_ce", remove it. This happens on OpenSUSE Tumbleweed at least
	currentVersion = strings.TrimSuffix(currentVersion, "_ce")

From what I can see, people who build Docker can override the Docker version as they wish, for example from the Arch package (people can set any VERSION env they want when building):

https://gitlab.archlinux.org/archlinux/packaging/packages/docker/-/blob/381210628f4f895b2cee908ffa1179f7ff1150d4/PKGBUILD#L87-94

I would rather set the minimum API version to use with DDEV - this value is set and controlled only by Docker.

@rfay, what do you think about this? (Of course, this is beyond the scope of this PR, and can be done in a new PR).

[rfay]

API version sounds like a fine thing to me.

In general, we've been trying to support as much as we can all the time, and been pretty successful with it over the long term.

[stasadev]

I've updated the PR description with more information about the changes made, it should be fine to merge.

[rfay]

I'll try to manually test. Looks good to me also.

[rfay]

I guess my major worry would be that since healthcheck.start_interval was previously ignored, it not being ignored when using Docker v25 might cause some new issues.

[stasadev]

This check healthcheck.start_interval will simply start in 1s, not in 5s (default).
https://docs.docker.com/engine/reference/builder/#healthcheck

[rfay]

It looks great to me. I tested against Docker 25.0.2 (Docker Desktop) and against Docker 24.0.7 (colima) and the behavior was correct.

The reason I was a little hesitant was that I have misunderstood these configuration values and misused them many times during DDEV's history :)

[rfay]

Pretty brilliant, thanks.