How's it different than running things with pure docker or before docker? There were backups and no downtime deployments before docker became a thing... docker compose is already a layer above docker (but really just docker).
Things are way simpler with Docker Swarm. You just run a single ingress controller as a separate stack and route all traffic internally.
If you use Traefik as your ingress controller, all you need to do is set labels in your docker compose files and everything just works.
There is absolutely no reason or excuse to use docker compose in anything resembling production.
I work at a university where I make an app meant for maybe a couple of concurrent researchers. Am I seriously supposed to set up Docker Swarm for this or is it OK with you if I run my little setup using Docker-compose on the tiny server that the university has provisioned for me?
Seriously, why do so many people on HN have to act like the entire world of software developers is busy making the next Facebook? I'm sure many (most?) people are making tiny things meant for tiny audiences.
I agree generally, but playing devil's advocate for GP, what I think they meant is that swarm can be run on a single node with little downside/complexity and a lot of upside from docker compose.
See for example:
https://jarredkenny.com/single-node-docker-swarm/
https://devopstuto-docker.readthedocs.io/en/latest/docker_sw...
Manage deployments as stacks, which support history and backtrack deployments.
Blue-green deployments.
Frankly, it boggles the mind how people put to production devtools that are barely managed to be secure when deployed locally, when alternatives are both simpler to deploy and more capable.
I'm sure you're great at setting up servers. That is probably the part of my job I dislike the most, but it's something I have to do, so I do it.
https://docs.docker.com/cloud/aci-compose-features/ https://docs.docker.com/cloud/ecs-compose-features/