[crdoconnor]

https://docs.docker.com/compose/startup-order/

>The problem of waiting for a database (for example) to be ready is really just a subset of a much larger problem of distributed systems. In production, your database could become unavailable or move hosts at any time. Your application needs to be resilient to these types of failures.

absolute bullshit. docker compose thinks that it can excuse its bugs by dint of the fact that we're supposed to build "more resilient" applications to accommodate them.

and, their proposed workaround with "wait for" is disgusting. their tool should be able to handle readiness detection. it's so fucking basic.

it's not only this but this is an example of the bullshit in this shitty tool excused with shitty reasons.

[nickjj]

> my test of "does my application work given that the database is running" is explicitly not accommodated.

Are you working with tools where this is a problem in practice?

Most web frameworks I've used will keep trying to connect to the DB in a loop until it either connects and things start normally, or it times out after X amount of seconds where X by default is configured to some number that's way higher than it would normally take for your DB to be available, even if it's starting from scratch with no existing volume.

No "wait for it" script needed (and I do agree that type of solution is very hacky). Although to be fair the same page you quoted said the best solution is to handle this at the app level, which is what most web frameworks do.

[crdoconnor]

Yes, I remember it was a problem with Django. It wasn't just the application server, you might need to run some scripts, after the database is up, before kicking off the webserver. Any workflow like this is explicitly unaccommodated.

100% of the solutions ive seen to address this problem have been hacky - either polling bash scripts or explicit waits.

docker compose is a piece of shit.