Wowu
Initial rollout ignores healthcheck
The very first docker rollout service seems to ignore the healthcheck:
$ docker rollout foo
==> Service 'foo' is not running. Starting the service.
Network _example_default Creating
Network _example_default Created
Volume "example_foo-mysql" Creating
Volume "example_foo-mysql" Created
Container example-foo-mysql-1 Creating
Container example-foo-mysql-1 Created
Container example-foo-1 Creating
Container example-foo-1 Created
Container example-foo-mysql-1 Starting
Container example-foo-mysql-1 Started
Container example-foo-mysql-1 Waiting
Container example-foo-mysql-1 Healthy
Container example-foo-1 Starting
Container example-foo-1 Started
You can see that the foo service depends_on the foo-mysql service to be healthy and waits for that. But the foo service itself is only started, without waiting for it to be healthy. And this indeed leads to the docker rollout command to finish even though the foo service is not yet ready to receive requests. In this case accessing the service (via Traefik in this case) yields a 404 until it becomes healthy eventually.
Workaround for now:
docker rollout foo
docker compose up --no-deps --no-recreate --wait foo
The rollout starts the service, no matter if it was running or not. The compose ... --wait ensures that execution stops until the service is healthy. The --no-deps and --no-recreate avoid pointless overhead and speed up this step since everything is in place already.
Hi, sorry for taking some time to respond to this issue 😅
May I know what is the reason you want docker rollout to wait until the service is healthy? I really want to keep this tool compatible with docker-compose v1, which does not support --wait. We could implement it with a loop checking if the service is healthy, but I wonder if this is a common use case, especially this only happens on the first run of the tool when no service is running yet.
As explained initially already there should be no difference between the 1st and subsequent deployments of a service. Once a service has been deployed, it should be guaranteed that it is healthy and thus accessible. Right now this is not the case for the 1st deployment. While not that pressing for human interaction there maybe machine actions performed right after bringing up the service which will then fail.
And I don't think that there's much benefit keeping support for Compose v1. As the migration docs say:
From July 2023, Compose v1 stopped receiving updates. It’s also no longer available in new releases of Docker Desktop.
In other words: one must be willingly and with more effort install Compose v1 and accept existing bugs and security issues. Same goes for people which continue to use v1.