Setting the table
First off, let me get on record - I LOVE DSC. When I was at Stack Exchange, I rolled Desired State Configuration out during the Server 2012 R2 preview timeframe. I coddled it through the move to RTM and then to General Availability. At the PowerShell Summit in April, Jeffrey Snover asked how I liked the WMF5 preview. I had to tell him I hadn’t really played much with it. He advised me that it had a bunch of updates for problems I reported. That night, I rolled WMF5 into production on my build servers.
I’m not the only one who has run DSC in a production capacity, but I was one of the first. While the ecosystem is building, there are still a lot of rough edges and gaps when looking to use DSC as the primary configuration management platform.
The more time I spend with Chef, the more I’m convinced that we have THE best platform to embrace Desired State Configuration.
Mise en place
Let’s look at what we have to work with.
-
Resources
-
Configuration DSL
-
Pattern to Separate Environmental Data
-
Pull Server
-
Linting Tool
-
Reporting EndpointChef
-
Resources
-
Configuration DSL
-
Pattern to Separate Environmental Data
-
Pull Server
-
Linting Tool
-
Reporting Endpoint
-
Reporting Dashboard
-
Inventory Tool
-
Analytics Framework
-
Unit Test Framework
-
Integration Test Framework
-
Cloud Integration
-
Virtualization Integration
Inspecting our ingredients
Resources
Both DSC and Chef offer default primitives for configuration management, as well as a way to create custom resources. Chef also has a preview of our ability to integrate DSC resources as Chef resources.
DSC’s resources are written in Powershell or are WMI based. Chef’s resources are written in Ruby.
Configuration DSL
DSC provides language extensions (new keywords and an updated parsing mechanism) to PowerShell. The full language is available to you to aid in generating the configuration document. Configurations are identified by the “configuration” keyword. The configuration command outputs a MOF document that describes the structure of the target node.
Chef’s configurations are built in Ruby. Like how DSC allows you to use the full power of PowerShell in a configuration command, you have the full power of Ruby when you author a recipe in Chef. Recipes are evaluated on the nodes they apply to. The chef-client processes all the recipes to run on a client and builds a resource collection to apply to the node. (The Chef docs have much more detail on this process.)
Pull Server
DSC ships with two basic pull server options. The first is to use a file share. You stash your configurations and your custom resources out on a file share and can point your nodes to that share to look for their configurations and fun new bits. The second is a REST-based (actually OData based) endpoint. There is no UI or management tooling for this endpoint. It is very scalable, since all it really does is serve up files.
Chef Server (there are three flavors - open source, hosted, and enterprise), provides a central location for deploying recipes and cookbooks (how recipes and resources are packaged), as well as central data store that is searchable by nodes during their configuration application. There is a web UI for Chef Server that lets you explore the uploaded cookbooks, metadata, and more.
Linting Tool
The DSC ecosystem has a contribution from DSC Resource Kit of the xDSCResourceDesigner, which has a function Test-xDscResource. This command validates the structure of the resource, including validating that the schema.mof document (required metadata) matches the parameters. It recommends proper annotation of command output.
The Chef ecosystem has FoodCritic, FoodCritic has a series of built in rules and is extensible. FoodCritic checks everything from looking for updated metadata, to improper looping, to missing files and much more (45 rules out of the box).