Meet Compute Engine’s new managed instance group updater
Pawel Siarkiewicz
Product Manager
A key feature of Google Compute Engine is managed instance groups, which allows you to manage collections of identical instances as a unit, to quickly deploy new VMs and ensure they're consistently configured. Today, we're pleased to announce a new managed instance group updater, to help you update your Compute Engine VMs programmatically and at scale. The updater is in beta and fully integrated into managed instance groups, making it easier than ever to update the software on your instances, patch and update them, and roll out staged and test deployments.
Specifically, the new managed instance group updater allows you to:
- Programmatically update your instances from one instance template to another
- Specify how many instances to update at a time: one, several or all
- Deploy additional instances (temporarily) to maintain capacity while old instances are being replaced
- Restart, or recreate, all instances in the managed instance group without changing the template
- Control the rate of deployment by configuring a pause between instance updates
- Deploying a simple update
- Deploying a canary test update
- Recreating all instances
Simple update
Let’s start with the basics and deploy an update to the entire managed instance group, one instance at a time. The instance group my-instance-group starts with every instance running the template myapp-version-a, and we want to deploy myapp-version-b because we're deploying a new version of our software (we could also be doing so to patch/update the underlying OS).
The managed instance group deploys myapp-version-b by first deleting an instance with myapp-version-a, while simultaneously creating an instance with myapp-version-b, waiting for that new instance to be healthy and then proceeding to the next instance until all of the instances are updated. If you want to roll back the update, just run the same command, but this time specify myapp-version-a as the target template.
This is the default behavior for the updater, and it works really well for many typical deployments. If your managed instance group is large, however, updating one instance at a time might take too long. Let’s try this again, but this time, let’s update a quarter of the instances at a time.
Note the new parameter, max-unavailable. It tells the updater how many instances can be taken offline at the same time, to be updated to the new template. Whether you have tens, hundreds or thousands of instances, the update proceeds at the rate you specify. If you’re wondering whether you can update all instances at the same time, the answer is yes. Just set max-unavailable to 100% and the managed instance group updates everything at once. This is a great option when consistent uptime doesn’t matter, for example in a testing environment or for batch computations.
Canary testing
Now it’s time to consider a more advanced use case. Deploying new software to a subset of instances before committing fully is known as canary testing and is a best practice for managing robust, highly available systems. It allows you to test new software in a real environment while minimizing the impact of any issues.For our example, let’s deploy myapp-version-b to just one instance.
Here, the managed instance group deletes one instance of myapp-version-a and creates one instance of myapp-version-b. The update does not proceed further. If the instance group needs to scale up or down, it retains that one instance of myapp-version-b so that you can test it and make sure that it works as intended. When you’re ready, you can deploy it to a larger group, for example one half of the instances.
The managed instance group replaces instances running myapp-version-a with instances running myapp-version-b until the balance is 50/50. If autoscaling adds or removes instances, the managed instance group maintains this ratio, keeping the canary deployment at the level you set.
When you’re ready to commit to your new deployment, simply tell the updater that you want all of your instances to be running myapp-version-b. This is identical to what we previously did in the simple update.
Recreating all instances
Sometimes you don’t want to apply a new template, you just want to replace all of your instances, but keep the current template. This is a common pattern if you're using image families and want to make sure that your instances are using the latest version of an image. Starting a rolling replace of all instances follows the same pattern as starting an update.
Notice that the replace action uses the same controls as max-unavailable that our earlier simple update example used to control how many instances to take offline at the same time.
Next steps
We think these are the most common use cases for the managed instance groups updater, but realistically, we've just scratched the surface of everything that’s possible with it. Thanks to flexible controls like max-unavailable and max-surge, support for canary updates and different actuation commands such as start-update, restart and recreate, you now have a lot of options for maintaining your managed instance groups fleet. For more information, please see the documentation, and feel free to reach out to us with questions and feedback in the GCE discussion group.
You can try out the new managed instance group updater today in the console. If you’re new to Google Cloud Platform (GCP) you can also sign up to automatically get $300 worth of GCP credit to try out Compute Engine and the managed instance group updater.
