Building a Desired State Configuration Configuration

Now that’s a title!  We’ve worked through my reasoning as to why I want Desired State Configuration (DSC) and how to build a pull server.  Today and in the next post we are going to look at how to create configurations which describe how our target systems are supposed to work.

The High Points

Building Configurations

Configurations are the driving force for DSC.  A configuration is a Managed Object Format (MOF) document that describes the how a specified server (or servers) should look.

What You See

A basic configuration may look like

Each instance of a MOF class (except for the OMI_ConfigurationDocument) refer to a DSC Resource and provides the parameters that resource will be called with when the configuration engine runs.  There are a couple of properties that are not passed to the resource module.  The ResourceID is a unique identifier that indicates the resource and the configuration inheritance tree where it is defined (we’ll dig deeper into that shortly).  The ModuleVersion is the version number of the PowerShell module (from the psd1) of the DSC Resource.

Getting From Here To There

We don’t want to write straight MOF files to define configuration, mainly because they are kind of verbose, with a some boilerplate  stuff for each resource.  Fortunately, we’ve got a Domain Specific Language (DSL) in PowerShell v4 to generate them.

The Configuration Keyword

PowerShell v4 contains the keyword “configuration”, which allows us to provide a name for the configuration (like a function name).

It looks just like how you would define a function or workflow. Now let’s put something useful inside of it.

In this most simple of examples, we’ve defined a particular feature to be installed on a Windows Server. When we run this snippet, a wrapper function will be generated (kind of like how a workflow wrapper is generated). At this point, no MOF file has been created or applied, this simply creates a function that can generate a configuration based on the resources specified within. If we execute this configuration

we’ll get a file named localhost.mof in a folder at $pwd/MyFirstServerConfig.

Configuration Default Parameters – OutputPath

If we want to specify the server the configuration applies to, we can wrap the resources in a Node block.

This will create a configuration named Server1. Node names will be important as we move on to talking about targeting via Start-DscConfiguration and using the pull server.

We do have some options as to how the configuration gets generated. We can use the OutputPath to control where the configuration files are deposited.

Configuration Default Parameters – ConfigurationData

Our other major parameter is ConfigurationData. ConfigurationData is a way to separate out your environmental concerns from the configuration documents. We’ll come back to this one after we explore a few more concepts. ConfigurationData is a hashtable that expects a certain structure. The hashtable should contain an key named AllNodes, which is an array of hashtables that describe the nodes whose data you want to inject. For example

NodeName is a common convention for specifying the node name.  We don’t want to use Node, as there are some automatic variables populated in a configuration, one of which is $Node.  All the other keys in the hashtable representing a node are completely up to you.

Just a quick aside.. the node name does not necessarily equate to the server name.  When we get in to targeting (a bit in this post and more in an upcoming one), we’ll see how this is true.

After we have some data in our ConfigurationData hashtable (and the variable doesn’t need to be called ConfigurationData, I just did for convenience sake), we can use that to help drive our configuration. We’ll tweak our configuration function a bit, so that it can take advantage of the extra data being supplied.

Since this is a PowerShell DSL, I can use PowerShell functions, operators, and flow control to manipulate the configuration details. In this case, I’m using a switch statement to add roles to my server based on role definitions I’m supplying in my ConfigurationData.

If we look at the MOF files generated by this, we’ll see that Server1 does not have the FS-FileServer role, but does have the Web-Server role.

And Server2 has the reverse.

To highlight a neat trick since we are using a switch statement and switch can process collections, we can specify more than one role in our hashtable and our configuration should be able to add all the required resources.

If we look at the configuration generated for Server3, we’ll find both Web-Server and FS-FileServer roles described.

Next Up

In the next post, we’ll continue this topic and look at other ways we can parameterize configurations as well as nesting configurations.  We’ll also touch on how to apply these configurations from Start-DscConfiguration and via a Pull Server.  Stay tuned!

About Steven Murawski

Steven is a Cloud Ops Advocate at Microsoft. Steven is an active member of the Chef and WinOps communities and a maintainer for several open source projects, including Chef, Habitat, and Test-Kitchen.