In order to get a good grasp on something new, like a
technology, it is always important to find a use case.
Once you have a use case, I can ensure you that the
learning process is much more interesting, fun – and perhaps easier too.
That is what I did when I went deep into Desired State
Configuration. I found a use case.
My use case was to leverage DSC as part of VM Roles in
Azure Pack in a way that would be valid for the future too.
Here comes some reasons for my decision.
Powershell has been around for some time now, and one of
the best benefits by learning and using the shell is the amount of work you are
able to do, combining modules, components, technologies and much more through
the same API. Considering that everything that MS builds and do – regardless of
cloud, will be accessible and manageable through Powershell in addition to
other options, ensures that this is a real no-brainer.
With Windows Management Framework 4.0, we also got
Powershell Desired State Configuration added to our table.
Powershell Desired State Configuration is Microsoft’s way
to implement an idempotent configuration that ensures that the “desired state”
will be reached by applying the entire configuration, regardless of the current
state.
-
But, what does this really mean? Aren’t we able
to do everything using native Powershell scripts already?
That is correct. There’s no “limits” by using Powershell
natively today.
However, with native Powershell scripts you are
responsible for building all the error handling and logic into your scripts. And
as you probably know, that can be both very time consuming and challenging.
Desired State Configuration handles this automatically
for you, letting you make and deploy any incremental changes to your configuration
over time without risking the system to be put in a bad state.
If you have any configuration drift? Depending on how the
Local Configuration Manager is
configured – the engine that’s responsible for applying the configuration and
follow the instructions, the system can heal itself by enforcing the desired
state.
Think of Powershell Desired State Configuration as a
contract between you and your nodes (manageable objects).
In order to create and deliver this “contract”, Desired
State Configuration is based on CIM – and use WinRM for communicating. CIM uses
a language called Manaed Object Format – often referred to as “MOF”. Powershell
Desired State Configuration is a way to create and distribute MOF files that
can be applied to systems supporting this standard.
The way it’s applied to the node(s) is either through “Push”
or “Pull”.
(The difference
between Push and Pull is out of scope right now and deserves a dedicated blog
post later on. I promise).
To put it short, the Pull mechanism requires some
infrastructure in order to work, where the node(s) are talking to the Pull
server – either through SMB, Http or Https.
The Push method is pretty straight forward and what you
can start using right out of the box. DSC requires that WinRM listeners are
configured so that the CIM can push the configuration to the remote systems.
Here’s an example of how a Powershell DSC Configuration looks like:
configuration DNS
{
node kndsc006
{
WindowsFeature
DNS
{
Name =
"DNS"
Ensure =
"Present"
IncludeAllSubFeature = $true
}
}
}
DNS
Start-DscConfiguration -wait -force -Verbose .\DNS
As you can see, the format here is quite easy to read.
We can easily see that we will install (Ensure = "Present") DNS (Name = "DNS") on the target node (kndsc006).
Actually,
it is so easy to read that Powershell newbies like me are able to manage J
Hopefully this gave you some more context about the “why”,
but we are not done yet.
In Azure today, we are able to leverage DSC as part of
the VM extension, meaning we can create – upload – and apply our DSC
configuration to Azure IaaS virtual machines. The method of applying the config
for these VMs are “Push”.
As you probably know, we don’t have the exact same
capabilities on-prem in order to leverage DSC as part of Azure Pack. However,
we are able to simulate the same experience at some extent, by using the
combination of DSC, SMA and VM Roles (http://kristiannese.blogspot.no/2015/03/application-modeling-with-vm-roles-dsc.html
)
Moving forward, we know that the consistency across clouds
will be as near as 1:1 with the introduction of Azure Resource Manager that
will introduce us for a complete new way to interact with our cloud services –
regardless of location. Also worth to note, the Azure Resource Manager itself
will be idempotent.
What about your existing DSC scripts?
Exactly, that is the main point here. These
configurations will be valid using Azure Resource Manager too J
So in essence, you invest in DSC now and use it both for
Azure Pack (VM Roles + SMA) and Azure (VM Extension), and later on you can
reuse the investment you’ve made into the era of Azure Resource Manager.
Hopefully this gave you some inspiration to start
learning Desired State Configuration, available in Windows Management Framework
4.0 – but also available in 5.0 (which is in Preview).
Please note that everything you do in Azure when using
the DSC VM Extension there is based on the 5.0 version.
