Desired State Configuration Basics [feedly]

----
Desired State Configuration Basics
// Dev Ops Guys

Before delving into the details of the tooling modules, one should have a basic understanding of the components of DSC.  This post consists of definitions of several key terms:

• ConfigurationExecutable code which produces zero or more MOF documents that can be later processed by the Local Configuration Manager (or an equivalent non-Windows agent) on a server.  A configuration is similar to a PowerShell function, but it has different common parameters and different automatic variables.  There are also keywords available that can't be used outside of a configuration; these are Node and Import-DscResource.
• ConfigurationDataAs mentioned, configurations have different common parameters than normal PowerShell functions.  One of these parameters is -ConfigurationData.  It's a means to pass a complex set of parameters to the configuration.

  This parameter accepts a special hashtable which must conform to certain minimum requirements:  it must contain a key named AllNodes, and the value assigned to the AllNodes key must be an array which contains only other hashtables.  The hashtables inside the AllNodes key must contain a property called NodeName.

  Aside from AllNodes, Microsoft has stated that any other keys in the ConfigurationData table which begin with the prefix PS should be considered taboo; if they extend the required parameters at some point, the new keys will begin with PS.

• ResourceDSC resources contain the executable code necessary to implement the actions described by a MOF document.  For Windows endpoints, DSC resources are small PowerShell modules which expose three commands, at minimum, named Get-TargetResource, Set-TargetResource, and Test-TargetResource.  The parameters passed to these commands are populated by the values in the MOF document.

  DSC resources must also contain a corresponding schema.MOF file which describes the parameters accepted by these PowerShell commands, in the MOF language.

• Local Configuration Manager (LCM)This is the Desired State Configuration agent which runs on every endpoint.  It's part of Windows Management Framework 4.0.  The LCM is responsible for reading the MOF documents which describe the desired configuration of the local computer, loading an executing the resources associated with that configuration, and interacting with the pull server and compliance server to do things like download new MOF documents and resource modules, and report status.
• MOF documentMOF stands for Managed Object Format; it's a standard format for plain text documents which are used to define classes and objects in CIM (Common Information Model.)  By having the MOF document layer, Microsoft has decoupled the PowerShell configuration language from the Local Configuration Manager.  This means that it's possible to produce MOF documents from toolsets other than PowerShell, such as Chef.  It's also possible to use PowerShell configurations to manage non-Windows devices, provided that an agent exists on the non-Windows platform which will read and process the MOF documents (such as OMI on Linux.)
• Pull ServerAn OData-based web service which serves up MOF documents and resource modules to endpoints.  Resource modules are hosted in the form of zip files.  Both resource module zip files and MOF documents also have a corresponding checksum file, which allows the client to make sure they have a complete download.
• Compliance ServerAnother OData-based web service which accepts status reports from endpoints, and stores that data in a database which can be reported on later.

This is very much a birds-eye view of the DSC technology, without going into any great detail.  However, these definitions are enough for us to discuss the roles filled by each of the DSC tooling modules.

----

Shared via my feedly reader

Sent from my iPhone