Docker compose development was compromised by the agenda of pushing people to use swarm.

This is why v2 features like resource limits were moved under the deploy: key and you have to use the special "--compatibility" flag to get them to work locally.

This is no longer the case. Compose is an open spec and the v2 and v3 formats are being merged into a unified format (where you don't need version numbers). There are now multiple implementations (eg for ECS/Fargate and ACI), and implementations are being encouraged to support all the options.

As of the September release of Compose version 1.27.0 https://github.com/docker/compose/releases/tag/1.27.0 the config format versions 2 and 3 are merged and "depends_on" – and "extends"! – are back.

This is amazing news, I was not aware of this. Thank you so much for linking! Do you know if it also applies to the cpu/memory limits and health checks? Is it a true full merge of the two specs? (I will investigate myself and post back too)

> "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database.

Most web frameworks will retry until it can connect or give up after a specified timeout time. Basically handle it at the app layer where you have the most control.

But you still run into situations where you need to wait for docker-compose up -d to be "really" up before doing certain things (such as exec'ing into your main container to run tests or migrations).

For that I wrote a simple Bash script at https://github.com/nickjj/wait-until. IMO a problem like this can't really be solved at the Docker Compose level. But without such a script you can easily end up with failing CI tests because there's a multi-second but varied amount of delay on upping a database for the first time. That script has become a part of all of my CI / deployment pipelines.

Wait for a TCP port to come up or wait for a HTTP healthcheck to succeed. I think it's exactly the sort of things that should be supported by the tool out of the box. It's a very common need.

The job of the tool is to manage a bunch of containers that depend on one another and restart them on failure. The tool has to know about dependencies and liveness anyway.

This is an application-level design flaw, not a flaw inherent to docker-compose. Regardless of whether you use docker or even if you use containers at all, your webapp should be able to restart if the connection to the database fails or is interrupted for any reason.

You would have the same problem if you used supervisord for example. The general solution is to auto-retry the connection until it comes back up, or hard fail and auto-restart the entire app in the event of a hard failure (e.g. with restart: on-failure or autorestart=true).

Hm, yes, but to play devil's advocate - if you want compose for orchestration (I don't) then you want that dependence not so much for initial start up, but for triggering restarts on failure.

As it stands, AIUI, all it does is mean that dependency A comes up too (in some order) when you `up B`.

You can define any order or restart behavior you need with v2. As long any container with a service dependency fail hards if that dependency is missing/down, it will be restarted and the whole app will eventually reach an up state.

    restart: on-failure
    depends_on:
      other_service:
        condition: service_healthy

https://docs.docker.com/compose/compose-file/compose-file-v2...

https://docs.docker.com/compose/compose-file/compose-file-v2...

From GP:

> Problem being, "depends_on" was removed in version 3, with no replacement in sight.

How is v2 relevant?

v2 and v3 specs are merged as of September apparently, so either set of options works in the current version. (See cousin comments above)