PowerShell Desired State Configuration - Part 1
Configuration Management
“Configuration management (CM) is a system engineering process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.”
PowerShell DSC:
Use to deploy distributed heterogeneous configurations for software services and the environment in which these services run by giving declarative configuration.
- It’s cross platform
- Distributed Heterogeneous Configuration Platform
- Declarative configurations
PowerShell DSC comes with new language Keywords to declaratively define Configurations that compile to Managed Object Format (MOF) DSC Providers to apply Configurations to Resources. Also, there is new Cmdlets available to test, apply, and restore Configurations on demand.
What we can do using PS DSC:
- Enabling or disabling server roles and features
- Managing registry settings
- Managing files and directories
- Starting, stopping, and managing processes and services
- Managing groups and user accounts
- Deploying new software
- Managing environment variables
- Running Windows PowerShell scripts
- Fixing a configuration that has drifted away from the desired state
- Discovering the actual configuration state on a given node
DSC Configuration Management
Simplifies configuration - because intent is separate from technology resources.
Prevent configuration drifts - DSC applies any new configurations. After initial application of a new configuration, if the target node drifts from the desired state, DSC reports the discrepancy in logs, and then re-applies the current configuration.
Flexible deployment options - We can use Push/ Pull model.
Enable continuous deployment- Using either own hosted Pull server or Azure Automation DSC pull server we can achieve continues deployment. Whenever there is change in configuration, generate the new MOF file, and then configuration will automatically get updated in next run (based of the refresh frequency). We can also automate this using PS and VSTS release pipeline.
Traditional script v/s DSC
We all know modularity is the king. It helps to understand easily, reduce maintainability efforts and cost, create reusable components, which can be used in different combinations as and when required. Diagram clearly shows the difference; traditional script is seems more monolithic approach. Consider a case where we want to install AD and SQL server with one or more role, in traditional script • We need to ensure all the dependencies must be in place. • Error handling mechanism and ensure that we catch all the errors • How to handle reboot • And they are more technology specific.
Whereas DSC modular approach help us to separate responsibilities. We are now more concern about the configuration intent. LCM engine (which is a OOB feature of Windows server 2012 R2 onwards) will take care of dependencies (use a keyword DependsOn), generate logs and handle errors, reboot resilience. Resource are technology specific, which is written by the Product experts, SMEs and communities. We can get these resources and customize based on our requirement, also we can create our own resources if required.
DSC Components
Local Configuration Management (LCM)
-
Local Configuration Manager is the Windows PowerShell Desired State Configuration (DSC) engine. It runs on all target nodes, and it is responsible for calling the configuration resources that are included in a DSC configuration script.
-
Configuration are declarative PowerShell scripts which define and configure instances of resources. Upon running the configuration, DSC (and the resources being called by the configuration) will simply “make it so”, ensuring that the system exists in the state laid out by the configuration.
- DSC configurations are also idempotent: The Local Configuration Manager (LCM) will continue to ensure that machines are configured in whatever state the configuration declares.
- Resources are the imperative building blocks of DSC which are written to model the various components of a sub-system and implement the control flow of their changing states. They reside within PowerShell modules and can be written to model something as generic as a file or a Windows process or as specific as an IIS server or a VM running in Azure.
-
The Local Configuration Manager (LCM) is the engine by which DSC facilitates the interaction between resources and configurations. The LCM regularly polls the system using the control flow implemented by resources to ensure that the state laid out by a Configuration is maintained. If the system is out of state, the LCM uses more logic inside of the resources to “make it so” per the Configuration declaration.
- Specifies how the LCM applies the configuration to the target nodes. It can take the following values: “ApplyOnly”: DSC applies the configuration and does nothing further unless a new configuration is pushed to the target node or when a new configuration is pulled from a server. After initial application of a new configuration, DSC does not check for drift from a previously configured state.
“ApplyAndMonitor”: This is the default value. The LCM applies any new configurations. After initial application of a new configuration, if the target node drifts from the desired state, DSC reports the discrepancy in logs. “ApplyAndAutoCorrect”: DSC applies any new configurations. After initial application of a new configuration if the target node drifts from the desired state, DSC reports the discrepancy in logs, and then re-applies the current configuration.
- Responsible for validating and applying configuration
- Runs under the context of the SYSTEM account
- Only Administrators can submit configuration
- Defaults to running in Push mode on a clean OS / PSv4 install
- Supports Pull mode via file share or web service
- Pull mode handles custom Resource Provider deployment
- A single MOF file must encompass all the configuration
Managed Object Format (MOF)
The Managed Object Format (MOF) was defined by the Distributed Management Task Force (DMTF), a vendor-neutral industry organization that Microsoft belongs to.
- It acts as middle layer.
- Responsible for deploying configuration.
- One MOF per server.
As I mention earlier DSC is cross platform, so question here is how.
We all know that Windows is API based Operating System whereas Linux is file based. Windows use the WMI whereas Linux use the OMI.
Windows Management Instrumentation (WMI)
WMI is the infrastructure for management data and operations on Windows-based operating systems. You can write WMI scripts or applications to automate administrative tasks on remote computers but WMI also supplies management data to other parts of the operating system and products, for example System Center Operations Manager, formerly Microsoft Operations Manager (MOM), or Windows Remote Management (WinRM).
OMI
OMI stands for Open Management Instrumentation. It’s a join effort between Microsoft and The Open Group - it was formerly known as NanoWBEM, or “Nano Web Based Enterprise Management”.
When we are done with resources and configuration intent authoring; we need to generate the MOF file (no need to worry, we have PowerShell to generate this for us). MOF is basically generated in OMI format, but WMI can interpret it for us if we are using Windows based systems.
DSC Phases
Authoring Phase: May include imperative as well as declarative.
Staging Phase: Fully declarative configuration representation using DMFT standard MOF instance. Configuration is calculated for all nodes.
Make-it-so Phase: Declarative configuration is refined through imperative providers
Push v/s Pull
Easy way to remember difference between Push and Pull
Push: This is who I am and here is my configuration.
Pull: This is who I am and give me my configuration.
I will talk more about DSC implementation in upcoming post.
Please do let me know your thoughts/ suggestions/ question in disqus section.
Related Posts
- PowerShell Desired State Configuration - Part 2
- DevOps Attitude
- Manage Azure DevOps Pipelines Variables
- Enable CI against all Branches
- VSTS Build and Release Agents
About Ajeet Chouksey
