14 Automating releases with upgrades and rollbacks
The job of a container orchestrator is to run your applications in containers and keep them running. Managers control multiple worker nodes which usually have spare compute capacity, so if containers become unhealthy or servers fail, the work can be scheduled on other machines and your apps stay online. You build health checks into Docker images so the cluster can identify when components fail unexpectedly - but there are also times when you deliberately take containers offline, to upgrade your applications. The application update process is fully automated with Docker Swarm, and you've already worked through that with stack deployments in chapter 13. The update process is highly configurable, and we'll spend time understanding 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 the 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.