4 ms·

Problem being, "depends_on" was removed in version 3, with no replacement in sight. I honestly don't understand why they'd remove that? why make a new configur

Problem being, "depends_on" was removed in version 3, with no replacement in sight. I honestly don't understand why they'd remove that? why make a new configuration format just to remove critical options? what is the developer supposed to do instead? when will compose stop accepting the v2 format so we're definitely screwed for good? (yes the writing is on the wall). P.S. For readers who don't have context. Make a basic compose file with a webserver and a database. "docker-compose up" is failing half the time out-of-the-box because the web server starts before the database.

nickjj 6y ago
> "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 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.
- user5994461 6y ago
  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.
Rapzid 6y ago
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.
- justincormack 6y ago
  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.
nikisweeting 6y ago
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).
- OJFord 6y ago
  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`.
  - nikisweeting 6y ago
    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/#restart https://docs.docker.com/compose/compose-file/compose-file-v2... https://docs.docker.com/compose/compose-file/compose-file-v2/#depends_on https://docs.docker.com/compose/compose-file/compose-file-v2...
    - klibertp 6y ago
      From GP: > Problem being, "depends_on" was removed in version 3, with no replacement in sight. How is v2 relevant?
      - nikisweeting 6y ago
        v2 and v3 specs are merged as of September apparently, so either set of options works in the current version. (See cousin comments above)
nicwolff 6y ago
As of the September release of Compose version 1.27.0 https://github.com/docker/compose/releases/tag/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.
- nikisweeting 6y ago
  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)

nickjj 6y ago

> "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 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.

user5994461 6y ago
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.

Rapzid 6y ago

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.

justincormack 6y ago
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.

nikisweeting 6y ago

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).

OJFord 6y ago
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`.
- nikisweeting 6y ago
  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/#restart https://docs.docker.com/compose/compose-file/compose-file-v2... https://docs.docker.com/compose/compose-file/compose-file-v2/#depends_on https://docs.docker.com/compose/compose-file/compose-file-v2...
  - klibertp 6y ago
    From GP: > Problem being, "depends_on" was removed in version 3, with no replacement in sight. How is v2 relevant?
    - nikisweeting 6y ago
      v2 and v3 specs are merged as of September apparently, so either set of options works in the current version. (See cousin comments above)

nicwolff 6y ago

As of the September release of Compose version 1.27.0 https://github.com/docker/compose/releases/tag/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.

nikisweeting 6y ago
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)