Hey everyone! I'm currently working on a web application using Docker Compose, which includes various containers like Traefik, PostgreSQL, MinIO, and Node.js. As a network and system administration student, I'm finding it tough to transition from a Docker Compose environment to using Docker Swarm. The main goal is to implement redundancy and load balancing between two Linux VPS servers. I know Swarm isn't as popular in DevOps these days, especially with Kubernetes taking the spotlight, but Kubernetes feels a bit overwhelming for me right now. I'm looking for any advice or tips on accomplishing this migration, and I'd be really grateful for any help or discussion about my project. Thanks in advance and have a great week! Also, I've linked my Docker Compose YAML here: [docker-compose.yaml](https://rentry.co/8asp5p97).
4 Answers
Hey, just a heads up: if you're going for redundancy, you really want to think about how your services interact. For example, having an odd number of manager nodes is crucial for a robust Swarm setup. And for Traefik, unless you're already set up with a load balancer, HA might not be necessary. When it comes to PostgreSQL, I switched over to Kubernetes for easier management, so that might be something to think about as well!
To clarify, migrating from Docker Compose to Swarm is totally viable! It's all about deciding how much redundancy you want. A strong recommendation is to have at least three manager nodes in your Swarm to keep things stable. Honestly, if pricing is tight, you can get away with one manager node and still scale out your worker nodes without issues. Just remember, if that manager goes down, you might need a bit of work to rebuild your Swarm, but it shouldn’t affect your app's workload too much.
It sounds like you're struggling with the whole process of adapting your existing setup for Swarm. While Swarm is fairly user-friendly, getting your load balancing and redundancy right, especially for Traefik and PostgreSQL, can be tricky. You should also consider that having just two VPS might complicate your quorum settings in Swarm. If you're really serious about high availability, you might want to look into setting up a proper three-manager node setup to manage your cluster effectively, even if it means some extra costs.
Yup, I'm with you! Swarm can get complex when you're talking about load balancing and redundancy. Have you checked out the 12-factor app principles from Heroku? They have some solid advice for making your web applications scalable!
For your database setup with PostgreSQL, you might consider using a dedicated HA solution, especially if you're interested in load balancing!
You can absolutely start with a simple Swarm cluster and migrate to Kubernetes later if you find the need to. In fact, I set up a basic HA Swarm using Raspberry Pis with Keepalived to handle failovers. It's quite effective. Just be mindful about having your services spread out and not crammed into one service, which can lead to issues down the line. You're definitely not alone in using Swarm in production!
That's a good point about the manager nodes! I've also found that if I run multiple replicas of my app, it avoids complications related to volume dependencies. It’s a good practice in a Docker Swarm environment.