Updating containerized applications should be a zero-downtime process that is managed by the container orchestrator. You typically have spare compute power in your cluster that managers can use to schedule new containers during updates, and your container images have health checks so the cluster knows if the new components fail. Those are the enablers for zero-downtime updates, and you’ve already worked through the process with Docker Swarm stack deployments in chapter 13. The update process is highly configurable, and we’ll spend time exploring the configuration options in this chapter.
Tuning update configuration might sound like a topic you can safely skip, but I can tell you from my own experience that it will cause you pain if you don’t understand how rollouts work and how you can modify the default behavior. This chapter is focused on Docker Swarm, but all orchestrators have a staged rollout process that works in a similar way. Knowing how updates and rollbacks work lets you experiment to find the settings that fit for your app so you can deploy to production as often as you like, confident that the update will either work successfully or automatically roll back to the previous version.