3 ms·
Honestly, it depends on what's in your stack and how everything fits together and what's the architecture like. Almost any orchestrator (Nomad, Swarm and Kuber
by KronisLV 5y ago
Honestly, it depends on what's in your stack and how everything fits together and what's the architecture like.
Almost any orchestrator (Nomad, Swarm and Kubernetes) can do a rolling deploy and draining of particular nodes if you ever want to do that either.
Currently my homepage runs on a few containers (horizontal scaling) and a load balancer in front of it, and redeploys have very little impact on the overall experience: https://kronis-dev.betteruptime.com/ https://kronis-dev.betteruptime.com/
That said, for write heavy workloads you'll need to even manage your DB migrations as a multi step process to allow both old and new schema versions to work during redeploy, whereas in other circumstances you'll need to think more about how to roll back either the DB, the app containers/instances or even events in your system (depending on the architecture and how much can go wrong).
In short:
- horizontal scaling can help, as can having a load balancer with health checks
- changes not being breaking between any 2 releases can help (e.g. multi-stage DB migrations)
- complications may arise with stateful services and data stores mostly
- apps and APIs being able to cope with others being offline, if only for a bit (e.g. request replay) can also help
- MuffinFlavored 5y agoI am currently using Terraform almost like Docker Compose to manage about ~5 services + a database + Redis in Docker containers. When I do a deploy, I swap version 0.0.1 for version 0.0.2 for example and it brings 0.0.1 down, then brings 0.0.2 up (aka, not very rolling deploy like). How would I migrate that to Swarm? I'm not using AWS/GCP/any of that. Just locally hosted Docker containers.
- KronisLV 5y agoThis is probably a good starting point: https://docs.docker.com/engine/swarm/swarm-tutorial/ https://docs.docker.com/engine/swarm/swarm-tutorial/ Essentially, if you already have a node or multiple nodes that have Docker, you can initialize a swarm with: docker swarm init --advertise-addr <MANAGER-IP> And, optionally, add nodes as workers to the cluster: docker swarm join --token <JOIN-TOKEN> <MANAGER-IP>:2377 And then you can deploy stacks: docker stack deploy --compose-file docker-compose.yml my_stack Here's a tutorial about stacks: https://docs.docker.com/engine/swarm/stack-deploy/ https://docs.docker.com/engine/swarm/stack-deploy/ You'll probably want to read up on the Compose specification and the values that Docker Swarm and Docker Compose support since last i checked there were some differences in v2 / v3 (which many people still use): https://docs.docker.com/compose/compose-file/ https://docs.docker.com/compose/compose-file/ Of course, if you want a less steep learning curve for actually running Swarm, depending on your personal preferences (GUI vs CLI), you might want to have a look at Portainer, which is a lovely and simple dashboard: https://www.portainer.io/ https://www.portainer.io/ From there, it should mostly be a matter of running multiple replicas of each of your services and doing rolling updates, while having a stable load balancer in front of everything: https://docs.docker.com/compose/compose-file/compose-file-v3/#update_config https://docs.docker.com/compose/compose-file/compose-file-v3... Also, you'll probably want health checks because Swarm can then route traffic to containers only after they have truly started: https://docs.docker.com/compose/compose-file/compose-file-v3/#healthcheck https://docs.docker.com/compose/compose-file/compose-file-v3...
- otterley 5y agoTo be clear, Kubernetes does not know anything about draining traffic from pods or nodes. See my comment elsewhere.