You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A way of configuring docker compose, such that when a user of my project runs a straightforward docker compose up (with no extra options), all services will be killed if the primary one fails or dies.
Detail
When I'm using docker compose, I'm always configuring one primary service and a bunch of satellite services. E.g., I'll have an essential primary web application, with one or more databases or observability tools that it hooks into. I don't know if this describes everyone's usage, but I suspect it's the clear majority.
In this scenario, if the essential application service fails to start, all the satellite services are pointless. So it seems quite weird to me for the default experience to be that docker compose up would fail to start the only thing that really matters, but carry on and show you output from all those pointless satellites as if everything was fine.
I know I can use docker compose up --exit-code-from primary_app, but the locus of control here is wrong. It's not the user of docker compose who should be making this decision, it's the author of the compose.yml who should specify which is the essential application that has to start successfully.
Please provide a way of configuring docker compose, such that when a user of my project runs a straightforward docker compose up, all services will be killed if the essential ones fail or die.
Basically, the functionality of docker compose up --exit-code-from (see docs), but defined from within the project repo.
Possible implementations
essential: true: An option for any number of services to say that if they die, everything has to die. It seems reasonable to assume you might want more than one essential service
COMPOSE_UP_EXIT_CODE_FROM=primary_app in ./.env: If there was a way to set docker compose CLI options by adding environment variables to a local .env file, that would also work.
The text was updated successfully, but these errors were encountered:
TL;DR
A way of configuring docker compose, such that when a user of my project runs a straightforward
docker compose up
(with no extra options), all services will be killed if the primary one fails or dies.Detail
When I'm using docker compose, I'm always configuring one primary service and a bunch of satellite services. E.g., I'll have an essential primary web application, with one or more databases or observability tools that it hooks into. I don't know if this describes everyone's usage, but I suspect it's the clear majority.
In this scenario, if the essential application service fails to start, all the satellite services are pointless. So it seems quite weird to me for the default experience to be that
docker compose up
would fail to start the only thing that really matters, but carry on and show you output from all those pointless satellites as if everything was fine.I know I can use
docker compose up --exit-code-from primary_app
, but the locus of control here is wrong. It's not the user of docker compose who should be making this decision, it's the author of thecompose.yml
who should specify which is the essential application that has to start successfully.Please provide a way of configuring docker compose, such that when a user of my project runs a straightforward
docker compose up
, all services will be killed if the essential ones fail or die.Basically, the functionality of
docker compose up --exit-code-from
(see docs), but defined from within the project repo.Possible implementations
essential: true
: An option for any number of services to say that if they die, everything has to die. It seems reasonable to assume you might want more than one essential serviceCOMPOSE_UP_EXIT_CODE_FROM=primary_app
in./.env
: If there was a way to set docker compose CLI options by adding environment variables to a local.env
file, that would also work.The text was updated successfully, but these errors were encountered: