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.

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.