In my experience, people that disparage containerization are either forgetting or weren’t around to know about how awful bespoke and project specific build and deploy practices actually were. Not that docker is perfect, but the concept of containerization is so much better than the alternative it’s actually kind of insane.
Exactly. If containerization solves one thing, it’s installing two pieces of software that e.g. want a different version of system Python installed. I love Debian but it won’t help you much here.
Docker has come a long way. There was a time when the documentation struggled to coherently describe what images were, and other tools were good-enough to not bother. Today there are imagines for most things, the documentation is clear, and support is widespread. But being able to setup a server on a Linux box is still a basic skill that any web administrator should know how to do. People make the mistake of thinking because they use Docker that they should use proprietary cloud hosting. My controversial belief is that the right solution for at least 90% of web services just slapping docker-compose on a VM, running SQLite in WAL backed up by Litestream, and maybe sync logs with Vector if you want to get real crazy. Run a production web service for $30/mo without cloud lock-in or bs. It's kind of funny I built a CD for AWS and it made me disillusioned with the whole thing. But yeah, Docker is good.
docker swarm is also a decent solution if you do need to distribute some workloads, while still using a docker compose file with a few extra tweaks. I use this to distribute compute intensive jobs across a few servers and it pretty much just works at this scale. The sharp edges I've come across are related to differences between the compose file versions supported by compose and swarm. Swarm continues to use Compose file version 3 which was used by Compose V1 [1].
> Any tips on the minimum hardware or VPS's needed to get a small swarm cluster setup?
From my testing, Docker Swarm is very lightweight, uses less memory than both Hashicorp Nomad and lightweight Kubernetes distros (like K3s). Most of the resource requirements will depend on what containers you actually want to run on the nodes.
You might build a cluster from a bunch of Raspberry Pis, some old OptiPlex boxes or laptops, or whatever you have laying around and it's mostly going to be okay. On a practical level, anything with 1-2 CPU cores and 4 GB of RAM will be okay for running any actually useful software, like a web server/reverse proxy, some databases (PostgreSQL/MySQL/MariaDB), as well as either something for a back end or some pre-packaged software, like Nextcloud.
So, even 5$/month VPSes are more than suitable, even from some of the more cheap hosts like Hetzner or Contabo (though the latter has a bad rep for limited/no support).
That said, you might also want to look at something like Portainer for a nice web based UI, for administering the cluster more easily, it really helps with discoverability and also gives you redeploy web hooks, to make CI easier: https://www.portainer.io/ (works for both Docker Swarm as well as Kubernetes, except the Kubernetes ingress control was a little bit clunky with Traefik instead of Nginx)
You can do Docker Swarm with a single node (both manager and worker). For a high availability setup, you need a majority of manager nodes for a quorum, so a minimum of three nodes to tolerate a single failure.
I actually just migrated my 4-node homelab from Docker Swarm to standalone instances. My nodes all have very different performance characteristics so I had every one of my services restricted to a specific node - in effect, not making use of most of the useful features of Swarm.
Some features of Swarm are nifty, but in particular I found that a) managing every service onto a single node is counter to the point of Swarm and b) I didn't like any of the options for storage. (1. Local storage, making containers even less portable across nodes. 2. Shared replicated storage, complicated. 3. Online file backend, expensive. 4. NFS shares, and then my NAS is a point of failure for every one of my nodes.)
git and ansible are not mutually exclusive. containers are not silly.
you'll come around some day