Azure DevOps - Workload Identity Federation
In a previous blog post, I discussed Workload Identity Federation in AKS, the successor to the Azure Pod Identity solutions and a more elegant
If you’re coming from on-premises, you know that before you do any changes on a virtual machine (updates, upgrades, configuration changes, etc.), you do a snapshot of the disk just in case of a failure. This is something we’ve all ignored up to a point until it bit us badly and we’ve then just ran snapshots for every change.
The problem in the cloud is that you do not have the same easy way to do VM snapshots and restores in case of an issue. This changed in Azure when they introduced the OS Disk swap feature which allows administrators to run snapshots of a virtual machine, do their thing and if anything goes wrong they just restore the checkpoint.
As I mentioned above, if anything goes wrong with a VM that you’re maintaining then you have a few options available depending on the situation. Before OS Disk swap existed, your only solution to fixing a broken VM was to either restore it from Azure Backup, download the VHD and hope to fix it from a Hyper-V machine, and the worst case was to redeploy it. Now you have the option of just doing a snapshot of the VM, do your stuff and if something happens just swap in the good disk ?
Swapping the OS Disks is a simple operation that can be done via PowerShell or CLI (no portal support yet). You need either the latest AzureRM PowerShell Module installed on your computer or just use the Azure Cloud Shell – shell.azure.com
For this example, I will use my WorkStation VM in Azure located in the Workstation RG
Let’s start by setting the VM object in a variable:
$VM = Get-AzureRmVM -ResourceGroupName Workstation -Name Workstation-VM
Now it’s time to stop the VM in order to have a consistent snapshot. – You can do skip this step if you don’t want to stop the VM.
Stop-AzureRmVM -Name $VM.Name -ResourceGroupName $VM.ResourceGroupName
While the VM is running or stopped you can now proceed to snapshot the current OS Disk:
$vmDiskName = $VM.StorageProfile.OsDisk.Name
$vmDiskObject = Get-AzureRmDisk -ResourceGroupName $VM.ResourceGroupName -DiskName $vmDiskName
$SnapshotConfig = New-AzureRmSnapshotConfig -SourceUri $vmDiskObject.Id -CreateOption Copy -Location $VM.Location
$takeSnapshot = New-AzureRmSnapshot -Snapshot $SnapshotConfig-SnapshotName "SNAP" -ResourceGroupName $VM.ResourceGroupName
Let’s assume that you utterly broke the VM, beyond repair so now you have to start the OS Disk Swap procedure. This part requires to stop the VM.
#stop the vm and create a new managed disk from the snapshot.
Stop-AzureRmVM -Name $VM.Name -ResourceGroupName $VM.ResourceGroupName
$genMSDiskFromSnapshot = Get-AzureRmSnapshot -SnapshotName SNAP -ResourceGroupName $VM.ResourceGroupName
$newDiskConfig = New-AzureRmDiskConfig -AccountType Premium_LRS -Location $vm.Location -CreateOption Copy -SourceResourceId $genMSDiskFromSnapshot.ID
$newMSDisk = New-AzureRmDisk -DiskName newOSDisk -Disk $newDiskConfig -ResourceGroupName $VM.ResourceGroupName
#Set the new OSDisk
Set-AzureRmVMOSDisk -VM $VM -ManagedDiskId $newMSDisk .Id -Name $newMSDisk.Name
Update-AzureRmVM -VM $vm -ResourceGroupName $vm.ResourceGroupName
The Update command will start up the VM and you will have reverted a disaster ?
After you RDP / SSH to the VM and validate that everything is working as before, you can just take the old disk image and play around with it in Hyper-V instance so you can see what happened or just delete it.
Signing off. Have a good one!