im currently looking to move our VM's into a Scale Set,
But i am facing an issue with updating the VM's.
I’ve got a base Image from which I spin up a ScaleSet having 5 instances. Now I have an application update that needs to be pushed to each of these 5 servers, what will be the most suitable and convenient process to achieve this.
I had done some research on this and one of the possible solutions was to ;
Create a New image with the updated application code
Run a Powershell script in templates which replaces the old Image with the newer image and update the Vm’s accordingly.
I am using asp.net for my application. So how do i go about updating each of the VM's in a scale set when ever there is an application update.
I was advised that we could use chef/puppet, but this will work out too expensive at $120 per node
Could someone please suggest a simpler solution. Any help is much appreciated
Use a script\dsc extension to push updates to your app. the process is straight forward and work exactly the same as single VM.
https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-dsc
The scale set "rolling upgrade" feature (currently in preview: https://github.com/Azure/vm-scale-sets/tree/master/preview/upgrade) could probably help; with this feature you simply create your new image, then update the scale set model with the new image, then the scale set will roll out the new image in batches over your infrastructure.
Hope this helps!
Use powershell to deploy to the scaleset. Works like a charm for me :)
$customConfig = #{
"fileUris" = #("https://$storageAccountName.blob.core.windows.net/scripts/script.ps1");
"commandToExecute" = "PowerShell -ExecutionPolicy Unrestricted .\script.ps1";
};
$vmss = Get-AzureRmVmss -ResourceGroupName $resourceGroup -VMScaleSetName $vmssname
Add-AzureRmVmssExtension -VirtualMachineScaleSet $vmss -Publisher Microsoft.Compute -Type CustomScriptExtension -TypeHandlerVersion 1.8 -Name "runscript" -Setting $customConfig
# Send the new config to Azure
Update-AzureRmVmss -ResourceGroupName $resourceGroup -Name $vmssname -VirtualMachineScaleSet $vmss
Related
Few days ago I moved my service from Azure Cloud Services classic to Cloud Services extended support. The latest doesn't have Production/Staging slots. There is a new swap mechanism that is activated if during a deploy we configured the "swappable cloud service". I can do it using Visual Studio publish magic and it works fine.
Now I want to make a deploy using powershell script. The code below just creates a new deploy without activated swap. It works fine.
New-AzCloudService -Name $stagingName `
-ResourceGroupName $resourceGroupName `
-Location $location `
-ConfigurationFile $cscfgFilePath `
-DefinitionFile $csdefFilePath `
-PackageFile $cspkgFilePath `
-StorageAccount $storageAccount `
-KeyVaultName $keyVaultName
I didn't find any samples or clues of how to add the "swappable cloud service" to the New-AzCloudService. I figured out there is such settings in
NetworkProfile.SwappableCloudService.Id but I can't understand how to set it up properly. For example, if I add:
$production= Get-AzCloudService -ResourceGroup $resourceGroupName -CloudServiceName $productionName
$production.NetworkProfile.SwappableCloudService.Id = $production.Name # just to reuse the object
$loadBalancerConfig = CreateLoadBalancerConfig
$networkProfile = #{loadBalancerConfiguration = $loadBalancerConfig; swappableCloudService = $production.NetworkProfile.SwappableCloudService }
New-AzCloudService -Name $stagingName `
...
-NetworkProfile $networkProfile `
I got the error:
New-AzCloudService : Parameter set cannot be resolved using the specified named parameters
Is it possible to set the "swappable cloud service" for New-AzCloudService? How to do it?
Is it possible to set the "swappable cloud service" after the deploy (in any way, Azure portal, API, powershell, etc.)?
I suspect the issue relates to the -NetworkProfile not being supported when -ConfigurationFile, -DefinitionFile, and -PackageFile are used.
In the documentation, -NetworkProfile is used with -PackageUrl and -Configuration instead.
I've asked Microsoft about this as I am having the same issue.
Try $production.Id instead of $production.Name. Or $production.id (I am not sure if the case is important).
I created 2 VMs, one is the domain controller, another is for hosting the applications, then I created 2 images from these VMs by following this article. But now I cannot create VM from the images, even manually create the image from the Azure portal. what I missed?
Here is the code looks like:
foreach($a in $arr){
$a = $a.Trim()
New-AzVM -ResourceGroupName $env:groupName -Name dc$a -ImageName $env:dcImageName -Location $env:location -VirtualNetworkName vNet$a -SubnetName subnet$a -SecurityGroupName ngs$a -PublicIpAddressName publicIp$a -OpenPorts 3389 -Credential $cred
New-AzVM -ResourceGroupName $env:groupName -Name app$a -ImageName $env:appImageName -Location $env:location -VirtualNetworkName vNet$a -SubnetName subnet$a -SecurityGroupName ngs$a -PublicIpAddressName publicIp$a -OpenPorts 3389 -Credential $cred
}
The error is:
##[error]Long running operation failed with status 'Failed'. Additional Info:'OS Provisioning for VM 'dclab1' did not finish in the allotted time. The VM may still finish provisioning successfully. Please check provisioning state later. Also, make sure the image has been properly prepared (generalized).
Best Regards,
Sue.
Currently, I've been given up this solution, I use the snapshot of VHD to create VM instead of creating VM from the images.
From the error message, It seems that your image is not properly prepared (generalized).
Time might be the issue. You could try to generalize the Windows VM using SysprepSysprep. Normally it takes 10 - 15 minutes, you should wait for enough time for the Sysprep. When the status is changed to stop in the Azure portal, you could deallocate and mark the VM as generalized.
Also, make sure you have selectd each of the steps during the generalization process:
I am working on creating an Azure Scaleset for an application. I have it set up so that when I scale out, it downloads this powershell script I've used in the past that will:
download the CI/CD deploy agent to the new VM, install, and fully configure it.
register the new deploy target with my CI/CD pipeline, and configure it to be labeled as my app.
That's all it does. From there, my CI/CD pipeline will auto-deploy my program on to this new machine and configure it for me when it detects the new target for the app. That part works fine. When I first set it up a few weeks ago, it was working fine and it was scaling out and auto-deploying perfectly with no issues.
I noticed today that I suddenly get a 403 trying to download the extension to the machine on provision during scale-out, and it wasn't doing this a couple of days ago. It's like my extension expired or something. This puts my scaleset into a failed state until it scales in and only the original VMS that are always there as a baseline are left.
I've re-installed this and it works, but after a period of time it breaks again. I looked into the JSON of my scaleset, and it has a storage account that looks like iaasv2tempstore as it's name, so this leads me to believe that all extensions are not permanent.
This leaves me with 2 questions:
what is the average lifetime expectancy of a script extension before it's invalidated by Azure deleting it?
Is there a workaround or alternative that allows me to make this permanent, or store it somewhere I have control over to make the script extension not need to be reinstalled frequently?
it doesnt expire. if it gets 403 when trying to download from the blob - probably means you are using SAS token to auth and it expires. If url is accessible to the script extension it wont stop working (unless you block it from talking to Azure, for example).
I ended up following some of what was done here in order to fix the issue.
General Workaround for Azure's lackluster custom extension ui:
Upload the script into blob storage yourself to an account that the VMSS could access.
Run this AZ powershell script. It's not polished enough to handle updating the instances if are in the process of scaling in or out, but it will get the job done.
$fileUri = #("https://somebloburi/blob/filename.ps1")
$storageAcctName = "account"
$storageKey = "accountkey"
$settings = #{"fileUris" = $fileUri; "commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File filename.ps1"};
$protectedSettings = #{"storageAccountName" = $storageAcctName; "storageAccountKey" = $storageKey};
$myVMSS = Get-AzVmss -ResourceGroupName "VMSS-RG" -VMScaleSetName "myVmss"
$myVMSS = Add-AzVmssExtension -VirtualMachineScaleSet $myVMSS -Name "CustomScriptExtension" -Publisher Microsoft.Compute -Type "CustomScriptExtension" -TypeHandlerVersion "1.7" -AutoUpgradeMinorVersion $True -Setting $settings -ProtectedSetting $protectedSettings
Update-AzVmss -ResourceGroupName "VMSS-RG" -VMScaleSetName myVmss -VirtualMachineScaleSet $myVMSS
if you don't script out the auto-upgrade, you can just do it yourself from the UI.
Using my Google Fu, I am not finding any information on how to troubleshoot a corrupted Azure virtual machine. It has been working fine for almost 8 months and I have had to redeploy it 1-2 before because it would not start.
Any helpful pointers or point me to some troubleshooting steps please.
I did a redeploy of my Azure virtual machine and perhaps did not wait long enough before shooting off the support request and creating this post as I am able to access my VM again. I received the following troubleshooting steps from Azure support professional so I am sharing here in case anyone else runs into these issues:
To over come this issue we can proceed to run a series of PowerShell scripts to force update the actual status of the VM on Azure backend, please follow this process:
To easily complete this, we can launch Azure PowerShell, please go to:
https://github.com/Azure/azure-powershell
Click on “Launch Cloud Shell” button:
On the newly open window, click on “PowerShell” link:
Then you can run the script, as is, line per line:
$vmName = "(Your VM NAME)"
$rgName = "(Your resource Group)"
$vm = Get-AzureRmVM -ResourceGroupName $rgName -Name $vmName
update-AzureRmVM -ResourceGroupName $rgName -VM $vm
This should bring the VM to healthy or ready state.
Please let me know the outcome of the PS command, if successful try to start the VM.
If it still shows as “corrupted” please share with support a screenshot of the error.
I have been browsing web regarding Azure Scale Set service and I have been able to find a lot of resources connected to scaling and deploying of scale set, however I was not able to find any information regarding deployment and update of the solutions deployed to the machines within scale set. Please what is the best practise when I want to host e.g. a web solution within scale set? How should I perform deployment and updates?
Thank you in advance.
It will depend on how you configure the scale set to be a web solution to begin with...
For example, if you create the VMSS with a template and then configured the VMSS with a custom script extension, then you could run the template deployment again and update the script.
If you used DSC (windows vm) then you could just update the artifacts source and DSC will do the update while the VMs are running.
If you want to use PowerShell for deployment to the Scale Set.
$customConfig = #{
"fileUris" = #("https://$storageAccountName.blob.core.windows.net/scripts/script.ps1");
"commandToExecute" = "PowerShell -ExecutionPolicy Unrestricted .\script.ps1";
};
$vmss = Get-AzureRmVmss -ResourceGroupName $resourceGroup -VMScaleSetName $vmssname
Add-AzureRmVmssExtension -VirtualMachineScaleSet $vmss -Publisher Microsoft.Compute -Type CustomScriptExtension -TypeHandlerVersion 2.0 -Name "runscript" -Setting $customConfig
# Send the new config to Azure
Update-AzureRmVmss -ResourceGroupName $resourceGroup -Name "$vmssname" -VirtualMachineScaleSet $vmss