4 ms·

>>> We even run compose v2.4 to retain the ability to set container memory/cpu limits and define startup order with healthchecks... Does compose finally suppor

>>> We even run compose v2.4 to retain the ability to set container memory/cpu limits and define startup order with healthchecks... Does compose finally support starting containers in order with healthchecks? Last time I checked it didn't and Docker Inc was expressively refusing to support that, in spite of being a very basic use case. See various workarounds over the years: https://stackoverflow.com/questions/31746182/docker-compose-wait-for-container-x-before-starting-y https://stackoverflow.com/questions/31746182/docker-compose-... Compose v2.4 was released long ago and abandoned by docker. Some features/workarounds that worked in that version were killed in the next versions. It seems to me that you're stuck on that old version unable to upgrade because of that? IMO this is a perfect illustration of how Docker sucked in practice (both the product and the company), the industry naturally converged into trying to get rid of it because there was no other choice.

nikisweeting 6y ago
You just define a depends_on: condition: service_healthy, works great in v2.4. v3 is really a different beast, it's not an upgrade in the traditional sense, more of a lateral move with the introduction of swarm. I've even seen Docker employees recommend in forums using v2 independently of v3 if you need certain features (I can try and dig up a link from my archive if you're interested). Compose file version 2 is not deprecated, unlike version 1. It remains stable and supported (though no new features are added), it's very well documented and still widely used because of the additional features it supports over v3. https://docs.docker.com/compose/compose-file/compose-versioning/#version-2 https://docs.docker.com/compose/compose-file/compose-version... (compare with the v1 deprecation notice above it) I don't know about "sucked in practice", we use it because we love it. They released a new version to push users toward swarm, which we don't need. Such is life sometimes. It's had some bugs and problems in the past and if something better comes along we'll use it, but for the time being Docker compose satisfies all our needs and I think it's a beautifully designed UX and reliable piece of software in its current form.
- user5994461 6y ago
  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.

nikisweeting 6y ago

You just define a depends_on: condition: service_healthy, works great in v2.4. v3 is really a different beast, it's not an upgrade in the traditional sense, more of a lateral move with the introduction of swarm. I've even seen Docker employees recommend in forums using v2 independently of v3 if you need certain features (I can try and dig up a link from my archive if you're interested). Compose file version 2 is not deprecated, unlike version 1. It remains stable and supported (though no new features are added), it's very well documented and still widely used because of the additional features it supports over v3. https://docs.docker.com/compose/compose-file/compose-versioning/#version-2 https://docs.docker.com/compose/compose-file/compose-version... (compare with the v1 deprecation notice above it) I don't know about "sucked in practice", we use it because we love it. They released a new version to push users toward swarm, which we don't need. Such is life sometimes. It's had some bugs and problems in the past and if something better comes along we'll use it, but for the time being Docker compose satisfies all our needs and I think it's a beautifully designed UX and reliable piece of software in its current form.

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