[kjuulh]

I am using docker-compose everywhere. I really enjoy using it. I have a single thing that is annoying for normal production deployments, and that is that it isn't super easy to have a rolling deployment, I just need two replicas for zero downtime deployment, and I don't really want docker swarm. I think it is the networking which breaks at that point, and you have to have a more involved setup, and at that point I'd just use kubernetes, as I know how that works.

Could i survive with 10 seconds of downtime, probably, but I'd really like if I could avoid it.

[derfurth]

That's why I now use uncloud, simple as docker compose and got rolling deployments

https://uncloud.run/docs/guides/deployments/rolling-deployme...

[jimmydoe]

I’m happily taking that 10sec whenever thinking about the lifting I have to do for kube and extra cost.

[Pxtl]

Reading the article over, it really feels like Docker should be targeting Swarm as (instead of being its own platform) a set of incremental enhancements to Docker Compose. "I need healthcheck-restarts" "I need off-host logging", etc.

They've basically lost the war against Kubernetes but they could easily claim a lot of ground when it's just one more tweak you're adding to your docker-compose file as it scales.

[n_e]

Why not use swarm? On a single node it isn't really more complicated than compose, and you get scaling and rolling deployments.

[crummy]

this is a hack I have used and am proud of:

if you use Caddy as your reverse proxy (instead of nginx for example which does not do this), when requests come in and your service is missing because it's being deployed, Caddy waits for a timeout before giving up. this means that visitors during the brief deploy period don't see errors - they just get a slightly longer wait, which often is not obvious depending on how long your service takes to boot.