Not 4, but for me at least it's often 3. docker-compose has a bad habit of re-using the existing container, i.e. `docker-compose restart <service>` won't stop the existing service container and create a new one, it restarts the current container. Often the reason I'm restarting the service is because I need a clean, new container to pick up some env change or for some debugging or something, so habitually I restart containers with `docker-compose stop <service> && docker-compose rm -f <service> && docker-compose up -d <service>`.
I mostly like docker-compose just fine, but this is an annoyance & when I first started using docker-compose some years back I definitely lost more time than I would have liked trying to figure out why some change I'd just made didn't seem to have applied. I feel like destroying/creating containers is pretty cheap (that's one of the great things about containers!), so I'm not sure why docker-compose behaves this way. I presume it's for historical reasons and they don't feel comfortable changing it because of backwards compatibility.
Thanks for pointing out `--force-recreate`: I'm pretty sure that didn't exist when I started using `docker-compose`. That reduces my common usage from 3 commands to 2 :).
As a point of minor interest I also avoid `down` vs `stop` because `down` can remove volumes. Reading the `--help` now (I'm not about to actually try it for reasons that will be clear shortly), it appears that's not the default behavior, but I'm pretty sure it was at one point. I `docker-compose down`-ed once and wiped out my local databases and that was an unpleasant morning, and ever since I've avoided it.
That's a round-a-about way of explaining that a certain amount of my programming habits are certainly born of having stepped on numerous rakes in the past, but some of those rakes don't really exist anymore and I don't always notice when they go away. So I appreciate you prompting me to re-examine this particular habit as being out of date.
It's potentially possible. I'd have to look at it again to verify.
What we were struggling with were "conditional services" like running Integration Tests. We only wanted to add that container to the cluster when we wanted to run the tests.
Same with the "demo" mode we added. That spins up an Nginx container with an example front-end app.
It's theoretically possible to define all of the containers in one big Docker Compose config and then turn them on/off with env variables per environment, but it's just hellish to debug. In fact, I suspect that's what the engineer that wrote those started with before getting frustrated with spaghetti.
Sometimes there is just no winning with the computers lol
Edit: Answering the "it isn't 4 commands" bit -- if you just restart a container it won't pick up changes to the Docker Compose config. You have to remove it an add it back to the cluster.
Anyway, wrapping everything in a dev command makes a lot of sense for DX,
and then if generating docker-compose.yml files or importing miniboss is the most straightforward/reliable/maintainable way, all good
If you're dockerizing a dev environment check out batect, it's kind of like the combo of docker-compose + make (i.e. simple script running) that is really the tool we all just want: https://batect.dev/ It can easily define one-off container tasks like integration test runs with just a couple lines of config.
I will check this out. Thank you! I'll also make sure that the "Docker Awesome" list has this info too. I bet there are some cool projects there (and the OPs GitHub project should be added too, come to think of it).
Comments
Would .env files not have worked? Your script generates a .env, with a static docker-compose.yml
Restarting one service isn't 4 commands.
Not 4, but for me at least it's often 3. docker-compose has a bad habit of re-using the existing container, i.e. `docker-compose restart <service>` won't stop the existing service container and create a new one, it restarts the current container. Often the reason I'm restarting the service is because I need a clean, new container to pick up some env change or for some debugging or something, so habitually I restart containers with `docker-compose stop <service> && docker-compose rm -f <service> && docker-compose up -d <service>`.
I mostly like docker-compose just fine, but this is an annoyance & when I first started using docker-compose some years back I definitely lost more time than I would have liked trying to figure out why some change I'd just made didn't seem to have applied. I feel like destroying/creating containers is pretty cheap (that's one of the great things about containers!), so I'm not sure why docker-compose behaves this way. I presume it's for historical reasons and they don't feel comfortable changing it because of backwards compatibility.
I think `docker-compose down <service> && docker-compose up -d --force-recreate <service>` should do it.
Thanks for pointing out `--force-recreate`: I'm pretty sure that didn't exist when I started using `docker-compose`. That reduces my common usage from 3 commands to 2 :).
As a point of minor interest I also avoid `down` vs `stop` because `down` can remove volumes. Reading the `--help` now (I'm not about to actually try it for reasons that will be clear shortly), it appears that's not the default behavior, but I'm pretty sure it was at one point. I `docker-compose down`-ed once and wiped out my local databases and that was an unpleasant morning, and ever since I've avoided it.
That's a round-a-about way of explaining that a certain amount of my programming habits are certainly born of having stepped on numerous rakes in the past, but some of those rakes don't really exist anymore and I don't always notice when they go away. So I appreciate you prompting me to re-examine this particular habit as being out of date.
Unfortunately `docker-compose down` takes no argument. You have to do `docker-compose rm -sf <service>`
It's potentially possible. I'd have to look at it again to verify.
What we were struggling with were "conditional services" like running Integration Tests. We only wanted to add that container to the cluster when we wanted to run the tests.
Same with the "demo" mode we added. That spins up an Nginx container with an example front-end app.
It's theoretically possible to define all of the containers in one big Docker Compose config and then turn them on/off with env variables per environment, but it's just hellish to debug. In fact, I suspect that's what the engineer that wrote those started with before getting frustrated with spaghetti.
Sometimes there is just no winning with the computers lol
Edit: Answering the "it isn't 4 commands" bit -- if you just restart a container it won't pick up changes to the Docker Compose config. You have to remove it an add it back to the cluster.
The conditional services can be done with 'profiles' nowadays.
https://docs.docker.com/compose/profiles/
Anyway, wrapping everything in a dev command makes a lot of sense for DX, and then if generating docker-compose.yml files or importing miniboss is the most straightforward/reliable/maintainable way, all good
Cheers
If you're dockerizing a dev environment check out batect, it's kind of like the combo of docker-compose + make (i.e. simple script running) that is really the tool we all just want: https://batect.dev/ It can easily define one-off container tasks like integration test runs with just a couple lines of config.
I will check this out. Thank you! I'll also make sure that the "Docker Awesome" list has this info too. I bet there are some cool projects there (and the OPs GitHub project should be added too, come to think of it).