The rolling upgrade
Now you have a fully-deployed site with web servers, a load balancer, and monitoring. How do you update it? This is where Ansible’s
orchestration features come into play. While some applications use the term ‘orchestration’ to mean basic ordering or command-blasting, Ansible
refers to orchestration as ‘conducting machines like an orchestra’, and has a pretty sophisticated engine for it.
Ansible has the capability to do operations on multi-tier applications in a coordinated way, making it easy to orchestrate a sophisticated zero-downtime rolling upgrade of our web application. This is implemented in a separate playbook, calledrolling_update.yml.
Looking at the playbook, you can see it is made up of two plays. The first play is very simple and looks like this:
What’s going on here, and why are there no tasks? You might know that Ansible gathers “facts” from the servers before operating upon them. These facts are useful for all sorts of things: networking information, OS/distribution versions, and so on. In our case, we need to know something about all of the monitoring servers in our environment before we perform the update, so this simple play forces a fact-gathering step on our monitoring servers. You will see this pattern sometimes, and it is a useful trick to know.
The next part is the update play. The first part looks like this:
This is just a normal play definition, operating on thewebserversgroup. Theserialkeyword tells Ansible how many servers to operate on at once. If it is not specified, Ansible will parallelize these operations up to the default “forks” limit specified in the configuration file. But for a zero-downtime rolling upgrade, you may not want to operate on that many hosts at once. If you had just a handful of webservers, you may want to setserialto 1, for one host at a time. If you have 100, maybe you could setserialto 10, for ten at a time.