We upgraded our cluster today to the latest version of Elasticsearch, 0.20.4.
As we were previously running on 0.20.1, this deploy includes a handful of new features and bug fixes from 0.20.2, 0.20.3, and 0.20.4. Some of these recent versions of Elasticsearch include bug fixes for issues such as we saw earlier in January.
Maintaining an up to date system free from outdated dependencies and bitrot is one of our main priorities as a service provider. As such, we try to stay as up to date as possible with the latest version of Elasticsearch, and have designed our systems in order to minimize the cost of deploying the latest version of Elasticsearch.
“My Code’s Deploying!”
Deploying new versions of our internal services, Elasticsearch included, is a very deliberate process for us. Getting the code and configurations onto the servers tends to be straightforward. It’s the restarts that can be nerve-wracking.
Our rolling restarts go through a very thorough checklist which look something like this:
- Gracefully remove a server from our load balancers to stop it from receiving new requests.
- Wait for all current requests to finish processing.
- Restart the service with the new code and configurations.
- Poll the service health checks. For Elasticsearch, we wait until the cluster status is green and everything has completely initialized and rebalanced itself.
- Add the server back to our load balancers.
- Wait a few seconds until requests start processing.
This is an unhurried process, but after a few years of experiencing managing production hosting services, we wouldn’t have it any other way.
The best part? Deploying new services becomes the perfect legitimate excuse for slacking off.
