4 ms·
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
by 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 agoHm, 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 agoYou 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 agoFrom GP: > Problem being, "depends_on" was removed in version 3, with no replacement in sight. How is v2 relevant?
- nikisweeting 6y agov2 and v3 specs are merged as of September apparently, so either set of options works in the current version. (See cousin comments above)