Azure VM scale sets have an “upgradePolicy” setting which can be set to “Manual” or “Automatic”. What does this setting do? What should you set it to? and how do you set it?
What upgrade policy means
The upgrade policy of a scale set determines what happens next after you change the scale set model. I.e. regardless of this setting nothing “automatic” happens unless you make a change to the model. Changing the scale set model means changing a property of the scale set which affects VMs, for example, the VM size (sku->name), the OS version, an extension property.
If you change a scale set property in the model (i.e. change a value and update the scale set), then if the upgradePolicy is set to “Manual”, nothing happens. It will be up to you to then apply the model to VMs in the scale set manually. E.g. by calling the Update-AzureRmVmssInstance PowerShell command or the Azure CLI 2.0 az vmss update-instances command. When you apply the model to a VM, this will typically result in a reboot, and if you’re changing the OS version, a reimage.
For more information about how to manually roll out an upgrade across VMs in a scale set, refer to: https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-scale-set.
If the upgradePolicy is set to “Automatic”, when you deploy an updated scale set model, the update will be applied to all the VMs in the scale set at once. This is likely to result in an interruption to your application, which is why it is usually recommended to set this value to “Manual”.
What to set upgradePolicy to
If you don’t mind all your VMs being rebooted at the same time, you can set upgradePolicy to “Automatic”. Otherwise set it to “Manual” and take care of applying changes to the scale set model to individual VMs yourself. It is fairly easy to script rolling out the update to VMs while maintaining application uptime. See https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-scale-set for more details.
If your scale set is in a Service Fabric cluster, certain updates like changing OS version are blocked (currently – that will change in future), and it is recommended that upgradePolicy be set to “Automatic”, as Service Fabric takes care of safely applying model changes (like updated extension settings) while maintaining availability.
How do you set upgrade policy?
A simple way to change the upgradePolicy setting is to change it in the template you used to deploy a scale set and redeploy the template. If you didn’t use a template (for example created it from scratch using imperative PowerShell or CLI commands, or deployed it from the portal), a simple place to change the property is in the Azure Resource Explorer. Find your scale set under Microsoft.Compute in your resource group, and select Edit. Change the upgradePolicy setting and click PUT.
What about fully automated OS updates and patching?
In Azure PaaS v1 (Worker and Web roles), you could deploy cloud services and never have to worry about patching. OS updates were automatically taken care of behind the scenes. People looking at migrating cloud services to scale sets often ask when they can get equivalent functionality on scale sets. Automated patching is a feature that is expected from PaaS. It is reasonable to expect scale sets (which is an infrastructure layer designed to support PaaS solutions) to provide this ability.
Fully automated OS updates is on the scale set roadmap, but for now only manual patching is available. There will be some interim steps along the way, for example expect to see built-in manually triggered rolling updates coming soon.
In theory the primitives available now can be used to create a DIY automated upgrade feature. For example you could write an Azure Function which checks to see if there is a new OS platform image version, then updates the VMSS model with the new version, and then rolls out the update across the scale set. The VMSS Editor tool implements the manually triggered rolling update part of this for example. It’s on my to do list to write a simple auto-upgrade demo, but I won’t try and claim it would be equivalent to a fully automated Azure service.