PowerShell DSC and Puppet — Why It Is Not Either/Or

The content below is taken from the original ( PowerShell DSC and Puppet — Why It Is Not Either/Or), to continue reading please visit the site. Remember to respect the Author & Copyright.

In this Ask the Admin, I’ll discuss why Puppet and DSC together is often the best configuration management solution in mixed Windows/Linux environments.

 

 

If you are not familiar with Puppet, it is roughly equivalent to PowerShell Desired State Configuration (DSC), a PowerShell technology that’s built in to modern versions of Windows. Both Puppet and DSC are configuration management tools that allow system administrators and developers to define how servers should be configured using a declarative syntax.

In standard PowerShell code, or Ruby in the case of Puppet, you use imperative syntax to execute a series of instructions to achieve your required configuration.

  1. Install this component.
  2. Configure these settings.
  3. If x is true, let setting z be equal to y.
  4. Reboot.

To install and configure Active Directory in Windows Server using PowerShell, you need to know how to install the required roles and features and then how to configure them. But using declarative syntax, you state how you want your server to be configured. Or how you want it to ‘look’. You don’t need to know the technical steps required to achieve the desired result. Or as Puppet puts it, ‘Modeling instead of scripting’.

  1. Make sure Active Directory is present with these parameters (…)

This is a significant departure from how system administrators have traditionally configured Windows Server because the available tools for Windows weren’t designed with DevOps environments in mind.

Group Policy vs. Text-Based Configuration Management

Group Policy and DSC overlap with each other but solve different problems. You might build your server using DSC. I.e. decide which roles and features should be installed. Group Policy is better suited to managing configuration settings. For example, you might choose to apply Microsoft’s security baseline Group Policy template, which contains hundreds of recommended settings. DSC can be used to apply hundreds of security settings but the required manifests could become unwieldy to manage.

For more information about Microsoft’s security baseline Group Policy templates for Windows, see Microsoft Launches the Security Compliance Toolkit 1.0 on Petri.

Text-based declarative manifest files that determine how servers are configured have several advantages over Group Policy. The first is versioning and change control. The Advanced Group Policy Management (AGPM) tool provides version control for Group Policy but is only available to Microsoft customers with Software Assurance. AGPM is part of the Microsoft Desktop Optimization Pack (MDOP). But text files can be checked in to any source control solution, like GitHub. You are not locked into using a tool that is not widely available and only supports Windows.

On that note, text files don’t require special tools to edit them. Unlike Group Policy Objects (GPOs), which were designed to manage Windows via APIs, text files can be created, edited, and verified by anyone who has permission to read them. Text files are especially suited to the principles of DevOps, which include defining everything in plain text and that all code should be documented and versioned. You can’t script Group Policy settings, they need to set manually in the UI. And there are other arguments in the DSC vs Group Policy debate, such as DSC is easier to extend and is idempotent by nature.

Using Puppet and DSC Together

If DSC and Puppet are very similar, why would you use them both? In scenarios where Linux and Windows co-exist, Puppet is the logical choice because it is more mature than DSC and has a lot of support in the developer community. Besides the ability to manage Linux and Windows, Puppet can manage network devices, like Cisco switches, and cloud infrastructure, such as Azure virtual machines. Puppet has a supported PowerShell DSC module that has been rigorously tested and allows you to use Puppet to configure Windows Server using DSC. While PowerShell DSC can be used to manage Linux, it isn’t backed up by the huge library of modules that are available for Puppet.

The Puppet console dashboard (Image Credit: Russell Smith)

The Puppet Console Dashboard (Image Credit: Russell Smith)

When you download the PowerShell DSC module for Puppet, you get all the DSC resources that are currently available in the PowerShell Gallery at the time the module shipped. So, when using Puppet with DSC, you don’t need to grab DSC resources individually and install them on each client. This is particularly beneficial for servers that don’t have Internet access.

DSC is great but Puppet is a more mature configuration management solution. Unlike DSC, Puppet provides a dashboard that displays an explicit view of the compliance of your entire environment. There’s also the ability to generate reports. Microsoft’s DSC Environment Analyzer (DSCEA) resource creates compliance reports for Power BI or in HTML format but it is an add-on that needs to be configured separately.

Puppet manifests are more concise and intelligent than the DSC counterparts. Dependencies can be indicated using chaining arrows and resources refreshed when a dependent resource changes. Puppet manifests can be validated before they are run and changes simulated before being applied.

PowerShell DSC doesn’t maintain a record of changes made to nodes. Information is recorded about the status of the overall operation in the Event Log on each run, which you can pull out manually. The results can be stored on a DSC pull server if you choose to use one. If you want to see historical changes made to nodes, Puppet is a better solution. You can view historical changes in Puppet’s console with detailed information about the changes made and ‘changed from’ and ‘changed to’ values. If a DSC resource fails to run, the error will appear in the console. You’ll need to use DSC tools to understand why it’s failing but you will be made aware that something is wrong. Puppet also has better central management of configurations, roles, and permissions.

If you are in the process of deciding how to manage your infrastructure, Puppet should be on your radar. Even if you don’t need to manage Linux or other non-Microsoft infrastructure, Puppet offers many advantages over a DSC-only solution. And if you are already familiar with PowerShell DSC, learning how to write Puppet manifests isn’t a big learning curve.

Sponsored

Microsoft has a good introduction to the topic on Channel 9: Better Together: PowerShell Desired State Configuration (DSC) and Puppet. Check it out if you’d like to know more about how PowerShell DSC and Puppet can be used together. Over the next few weeks, I’ll be covering some of the basics of how to use Puppet to manage Windows Server on Petri.

The post PowerShell DSC and Puppet — Why It Is Not Either/Or appeared first on Petri.