I absolutely loathe using it for development environment or testing because of awful design decisions like this wait-for-it hack https://docs.docker.com/compose/startup-order/
I absolutely loathe using it for development environment or testing because of awful design decisions like this wait-for-it hack https://docs.docker.com/compose/startup-order/
I'd be curious to know which tech stack you're using where you even need to use wait for it.
I've built and worked with various Flask, Django, Rails and Phoenix apps and none of them needed wait-for-it. Most of those ran a web server + background worker + redis + postgres.
Everything starts up no problem in development without any extra tooling when using Docker Compose.
Tests in CI are a different story, but I find wait-for-it to not be the tool to fix that problem. Instead I ended up writing this tiny shell script[0] to wait for a process to be ready between running a docker-compose up -d and running my test suite in CI. You'd run into this issue with or without Docker Compose too.
You could use it to wait until you can do a SELECT 1 on your database (the docs cover multiple database examples). The docs also cover why wait-for-it doesn't work to fix waiting for a database and other common use cases.
I find it hard to believe that docker-compose thinks that "start database, wait for port to be available and then start web server, then wait for port 8080 to be available and then kick off tests" is a workflow that ought to require a hacky bash script and a lecture about the importance of resilience. It's a pretty straightforward feature to implement.
I haven't used swarm but I can only imagine how bad that is.
Note that it requires using Compose v2.4, not 3.x.