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!
No comments:
Post a Comment