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.
Comments
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>`