Azure VM Extensions: Part 2 CustomScriptExtension
This blog post covers some of the battles I have had trying to install some software onto a VM within Azure. There are many ways to go about this and at the end of the day, yeah you live to fight another day.
High level requirements:
1 – Install Zabbix Agent (which is a windows service) onto the same VM and ensure the service starts correctly.
As like most things in life there is more than one way to do something, I could have used RunCommands I could add onto the DSC and added this step into part 1 etc. etc.
I went with using an Azure CustomScriptExtension, maybe not the best option, who knows, but here is how to get this working.
module virtualMachineName_ZabixxInstaller './modules/Microsoft.Compute/virtualMachines/extensions/deploy.bicep' = {
scope: resourceGroup(multiTenantResourceGroupName)
name: 'ZabixxInstaller'
params: {
enableAutomaticUpgrade: false
name: 'ZabixxInstaller'
publisher: 'Microsoft.Compute'
type: 'CustomScriptExtension'
typeHandlerVersion: '1.10'
virtualMachineName: virtualMachineNameBackend
location: location
autoUpgradeMinorVersion: true
settings: {
fileUris: [
'https://${storageAccountName}.blob.core.windows.net/${containername}/InstallZabbixAgentGS.ps1?${DSCSAS}'
'https://${storageAccountName}.blob.core.windows.net/${containername}/zabbix.zip?${DSCSAS}'
]
}
protectedSettings: {
commandToExecute: 'powershell.exe -ExecutionPolicy Unrestricted -File InstallZabbixAgentGS.ps1'
managedIdentity: {}
}
}
dependsOn: [
resourceGroups
virtualMachineBackend
]
}
So lets break this code down, firstly I make use of already written Azure Bicep Resource Modules which you can grab here :- https://github.com/Azure/ResourceModules/
I’m also using version 1.10 of this extension so make sure to watch out for that.
The fileUris are pointing to a storage account that has public access DISABLED, enabling public access is not what you want, notice the part at the end which is a SAS Token, I tried to get this working using a Managed Identity and gave up as running out of time, the docs say you can use a Managed Identity and maybe I will go back and try this now that I have more time, then update this blog post.
“If I generate a new SAS each time you deploy based on deployment time, it will re-run the Script extensions every time, since that SAS value changes. If you move to Managed Identity, the script extension does not have to process when you redeploy, it will be skipped, since the configuration/settings didn’t change. If you want it to redeploy, with no changes, then you can change the value of the forceUpdateTag
value.”
Huge shout out to https://github.com/brwilkinson he was helping me with this a LOT, and was super helpful, I owe it to him for helping me get this working and I owe it to him to go back and test it using Managed Identity.
Summary
So in summary I am generating a SAS token from the existing storage account like I do in Part 1 and then I pass that into fileUris so that I don’t run into permission issues.
- Part 1 – AZURE VM EXTENSIONS: PART 1 DSC EXTENSIONS https://gregorsuttie.com/2023/05/30/azure-vm-extensions-part-1-dsc-extensions/
- Part 3 – AZURE VM EXTENSIONS: PART 3 REFACTORING OUR CODE https://gregorsuttie.com/2023/06/11/azure-vm-extensions-part-3-refactoring-our-code/
Don’t forget to subscribe to my YouTube Channel. And my Newsletter
[…] Part 2 – AZURE VM EXTENSIONS: PART 2 CUSTOMSCRIPTEXTENSION https://gregorsuttie.com/2023/06/05/azure-vm-extensions-part-2-customscriptextension/ […]
[…] Part 2 – AZURE VM EXTENSIONS: PART 2 CUSTOMSCRIPTEXTENSION https://gregorsuttie.com/2023/06/05/azure-vm-extensions-part-2-customscriptextension/ […]
The other architectural consideration I had was private git repos – in all my scenarios I have my scripts etc in a private repo, whereas a lot of sample code leverages a public repo like Git where one can refer to a script in the raw url and use it instead of staging via a storage account.
I think every solution I’ve seen with a VM ends up with the custom script extension!