4 ms·

Docker Swarm all the way. Started with 1 node acting as manager and worker at the same time. Then added more 2 nodes, basically 3 nodes all acting as manager a

Docker Swarm all the way. Started with 1 node acting as manager and worker at the same time. Then added more 2 nodes, basically 3 nodes all acting as manager and workers at the same. Later kept 3 managers and 3 workers and now around 10 workers with the 3 managers. The cluster is full of apps, celery workers, static apps or SSR. To manage it I didn't use any UI. The CLI is really simple to use. Later to give less experienced people access to it i instant Portrainer. It has never stopped working, either upgrading or messing around on production environments. It just works. The only and only complain I have id the way it mess around with IPtable rules I have. The docker swarm networking overrides them. There are several approaches, while they work, they always feel like a hack to be honest. But yeah, they work. It's such a wonderful simple to use software that gets thing.

JoyfulTurkey 4y ago
I fully agree. Docker Swarm was perfect for my small employer with an IT staff of 3 people. Went with the 3 manager nodes, as recommended by Docker, to allow for upgrades without downtime, and things were rock solid. Also liked that encryption of the overlay networks was included. The only thing we missed/wanted was auto-scaling built-in, but we rarely had a need to scale the number of containers.
bityard 4y ago
What are you doing for storage? We're thinking of deploying Docker Swarm where I work onto a VMWare cluster and basically the options boil down to sharing a storage volume between VMs (which vSphere makes difficult) and replicating storage across nodes with something like gluster (which drastically increases storage used and has performance implications).
- sofixa 4y ago
  > We're thinking of deploying Docker Swarm where I work onto a VMWare cluster IMHO that's an anti-pattern. Why would you run two orchestrators on top of one another? Containers also cause scheduling contention on the vSphere side, on top of the waste of CPU from the virtualisation layer. Unless you're in some very specific circumstances, run your container orchestrator on bare metal when on prem.
- Alir3z4 4y ago
  Majority of the applications are purely stateless, for a very few and apps we had to use either a shared volume/storage or simply locking to a specific node. We did first locking to specific node, but later decided to use s3fs for those kind of needs. Never needed the shared storage critically to setup anything heavy-lifting reliable. Although worth noting, from the beginning I had psql running within docker swarm as well, but it was locked to 1 node only, we had a good backup solution to spin up (tried it too) on another node quickly as well. With mode nodes in the cluster, I made the PSQL into its own machine completely separated from docker environment.

JoyfulTurkey 4y ago

I fully agree. Docker Swarm was perfect for my small employer with an IT staff of 3 people. Went with the 3 manager nodes, as recommended by Docker, to allow for upgrades without downtime, and things were rock solid. Also liked that encryption of the overlay networks was included. The only thing we missed/wanted was auto-scaling built-in, but we rarely had a need to scale the number of containers.

bityard 4y ago

What are you doing for storage? We're thinking of deploying Docker Swarm where I work onto a VMWare cluster and basically the options boil down to sharing a storage volume between VMs (which vSphere makes difficult) and replicating storage across nodes with something like gluster (which drastically increases storage used and has performance implications).

sofixa 4y ago
> We're thinking of deploying Docker Swarm where I work onto a VMWare cluster IMHO that's an anti-pattern. Why would you run two orchestrators on top of one another? Containers also cause scheduling contention on the vSphere side, on top of the waste of CPU from the virtualisation layer. Unless you're in some very specific circumstances, run your container orchestrator on bare metal when on prem.
Alir3z4 4y ago
Majority of the applications are purely stateless, for a very few and apps we had to use either a shared volume/storage or simply locking to a specific node. We did first locking to specific node, but later decided to use s3fs for those kind of needs. Never needed the shared storage critically to setup anything heavy-lifting reliable. Although worth noting, from the beginning I had psql running within docker swarm as well, but it was locked to 1 node only, we had a good backup solution to spin up (tried it too) on another node quickly as well. With mode nodes in the cluster, I made the PSQL into its own machine completely separated from docker environment.