Every now and then, it comes a time when I really need to ramp up on certain things.
It can be a new technology, a new product, or a new way of doing things.
This kind of journey is never easy, and I am that kind of person who doesn’t stop before I have a certain level of satisfaction. I expect a lot from myself and have a crazy self-discipline.
Starting early this year, I went deep into DSC to learn more about something that will be impossible to avoid in the next couple of months.
Before continuing, I just want you to know that this will not be yet another blog post that explains the importance of Powershell, which you need to learn ASAP or else you will "flip burgers in the future".
A result of have working with Azure Pack and Azure for the last years has made me much more creative.
Instead of having our out-of-the-box products where we were limited by the actions provided by the GUI, we can now easily create our own custom solutions where integrating several APIs, modules and so on to create new opportunities for our business.
Let us stop for a second on Azure. Microsoft Azure.
We have been talking about the Cloud OS and cloud consistency for over a year now and we should all be very familiar with MS vision and strategy around this topic.
Especially “Mobile first, Cloud first” will give us a hint that whatever comes will appear in Microsoft Azure first.
In the context of DSC, we can see that we can leverage some Azure VM Extensions and Features in our IaaS VMs today.
And that is really the background of this blog post.
Microsoft Azure provides us with several VM Extensions, either directly by Microsoft or some third-parties to enable security, runtime, debugging, management and other features that will boost your productivity working with IaaS VMs in Azure.
When you deploy a virtual machine in the Azure portal, you can decide whether or not the VM Extension should be enabled.
We have several extensions available, all depending on what we are trying to achieve.
The extensions I find most interesting belongs to the category of “Deployment and Configuration Management”.
First, let us talk about a VM extension for “MSEnterpriseApplication”.
Using this Extension, we will effectively implements features that supports VM Roles resource extensions, the same we can leverage on-premises with Azure Pack and Service Provider Foundation.
To add this extension, the VM must already exist in Azure and have the Azure Guest Agent pre-installed.
Running the following cmdlet using the Azure module gives us more details about the extension
With this extension enabled in the VM, we can use the VM Role Authoring tool to author our resource extension (that is the package that we normally import to VMM which contains the application payload). The latest version let us deploy directly to Azure.
If you rather want to use Powershell, you should view the Powershell functionality of the tool and save only the portion of the script that assigns a value to $plainSettings in a text file.
From here, you can store the text file in a variable ($plainSettings) and update your VM with the following cmdlet:
$VM = Set-AzureVMExtension –ExtensionName “MSEnterpriseApplication” –Publisher “Microsoft.SystemCenter” –Version “1.0” –PrivateConfiguration $plainSettings –VM $vmcontext.VM
Next, update your VM directly using the following cmdlet:
Update-AzureVM –ServiceName “ServiceName” –VM $VM –Name “VMName”
So, given the fact that we now have a single tool where we can author and deploy our resource extensions (application payload) to IaaS VMs in both WAP and Azure is good news, however, it is not idempotent.
This is where Desired State Configuration comes into the picture.
Been built on the Common Information Model (CIM) and uses Windows Remote Management (WinRM) as the communication mechanism, DSC is like putting steroids into your Powershell scripts.
I know I will get a lot of Powershell experts on my neck here, but that is at least one way to visualize what DSC is.
Let us say you create a script, deploy it to a node and then you are done.
If someone makes any changes to that configuration afterwards, the Powershell script would not care nor notice.
A Desired State Configuration can ensure that there won’t be any configuration drift and apply and monitor (for example) the configuration.
This is handled by the Local Configuration Manager (LCM) which you can consider as an “agent”, although it is not an agent per definition.
So, looking at the capabilities of DSC, we can quickly understand how important this will be for any in-guest management solution moving forward.
The requirement of using Azure Powershell DSC VM extension is that you must have Azure Powershell module installed. The DSC extension handler has a dependency on Windows Management Framework (WMF) version 5 – which is currently in preview and only supported by 2012 R2. WMF 5.0 will automatically be installed in your IaaS VM as a Windows Update once enabled, and require a reboot.
The following cmdlets are specific to DSC:
Publish-AzureVMDscConfiguration – will upload a DSC script to Azure blob storage, that later will be applied to your IaaS VMs using the Set-AzureVMDscExtension cmdlet
Get-AzureVMDscExtension – Gets the settings of the DSC extension on a particular VM
Remove-AzureVMDscExtension – Will remove the DSC extension from a VM
Set-AzureVMDscExtension – Configures the DSC extension on a VM
Here’s a very easy example on how to apply a DSC script to your VM in Azure, assuming you have the script already created.
Publish-AzureVMDscConfiguration –ConfigurationPath “c:\folder\DSCscript.ps1”
That will create a ZIP package which will be uploaded to a blob storage in Azure.
Next, we will add the config to the VM (which we assume is already stored in the variable named $VM ) )
$VM = Set-AzureVMDscExtension –VM $VM –ConfigurationArchive “DSCscript.ps1.zip” –ConfigurationName “DSCscript”
Once this cmdlet is executed, the following will happen within the VM:
1) WMF 5.0 is downloaded and installed (the latest version) on the server
2) The extension handler looks in the specified Azure container (which is defined when you connect with your subscription) for the .zip file
3) Then the archive is unpacked and any dependent modules are moved into the PS Module path and runs the specified configuration function
Adding that this will also accept parameters gives you an understanding of how flexible, dynamic and powerful the DSC VM Extension will be.
Now, this was all about Microsoft Azure.
What about the things that are taking place in Azure Pack?
I briefly mentioned the VM Role Authoring Tool in this blog post which will be playing an important role in this setting.
The research I have been doing this year isn’t easy to put within a single blog post, especially not if I should describe all the errors and mistakes I have done as part of this journey J
I have been trying to simulate the Azure experience in Windows Azure Pack, but unfortunately, that is an impossible challenge as we don’t have the same possibilities when it comes to the interaction through the API. I am only able to achieve some of the good parts, but that again will qualify for some blog posts in the near future.
Before you start thinking “no, it is not that hard to simulate the exact experience”, I would like to remind you about that everything I do in this context, will always be using Network Virtualization with NVGRE, so there is no data-channel from the datacenter into the tenant environment what so ever.
If you think this is interesting, to learn more about DSC with Azure and Azure Pack, I have to point out the spectacular blog post series by Ben Gelens, where he has done a very good job explaining the complete setup of an entire DSC environment (using Pull) including the authoring of the required VM Role.
I will focus on the Push method in my examples, given the fact that the tenants are isolated and should be able to perform certain actions through self-service.
See you soon!