This was originally posted on stevenmurawski.com.
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.
DSC
- Resources
- Configuration DSL
- Pattern to Separate Environmental Data
- Pull Server
- Linting Tool
- Reporting Endpoint
CHEF
- 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).
REPORTING ENDPOINT
If you are using the DSC REST-based pull server, you can also set up a compliance endpoint, where servers can check it whether or not they are compliant or not. There is no UI, just a database sitting behind it.
On the Chef side, nodes report back to their Chef Server with the status of their inventory before the run, then their inventory and status after the run. Errors are viewable on the Chef Server.
REPORTING DASHBOARD
If you are using DSC, you’ll have to roll your own.
The Chef Server offers a web UI for viewing the status of your organization, uploaded cookbooks, configured roles and environments, and to explore the state of nodes.
INVENTORY TOOL
If you are using DSC, you’ll have to roll your own.
Chef-client includes Ohai, a tool that enumerates the state of the system and logs information about it. That information is available at the time a configuration is being processed, as well as for ad-hoc administrative efforts.
ANALYTICS FRAMEWORK
If you are using DSC, you’ll be rolling your own here too!
Analytics are a new feature for Chef (Enterprise). This platform allows you to do cool stuff like see changes in real-time, integrate with external systems, and tie in compliance controls.
UNIT TEST FRAMEWORK
If you are using DSC, you’ll be rolling your own here as well. We do have Pester as a good general purpose testing framework, but there is no underlying understanding of DSC.
On the Chef side of things, we have ChefSpec. ChefSpec actually runs a local version of the Chef Server and simulates a convergence (bringing the node back into compliance) and makes it easy to test the expected behaviors.
INTEGRATION TEST FRAMEWORK
Again, on the DSC side, we can put together our own testing framework with Pester.
With Chef, we have Test-Kitchen. Test-Kitchen is a test harness to help you run your recipes against a variety of types of nodes and run suites of tests against them, using a variety of frameworks (like Serverspec). Currrently Test-Kitchen doesn’t have support for Windows guests, but that’s changing. My co-worker, Salim Afiune has done a lot of work to improve the Windows support and Matt Wrock has a great post on getting it all to work on Windows.
CLOUD INTEGRATION
DSC does have some “x” resources for Azure, but no other support at the moment.
Chef’s knife tool has extensions for bootstrapping nodes in Azure, EC2, Digital Ocean, Google, and RackSpace among others.
VIRTUALIZATION INTEGRATION
DSC has some basic support for Hyper-V (via the “x” resources).
Chef has support for ESX and OpenStack. I’m sad to say there isn’t Hyper-V support. ;(
PUTTING IT TOGETHER
So, when you look at the overall ecosystems, DSC makes a strong showing on it’s own, but Chef rounds out the edges and provides the tooling that makes extended use and development not just possible, but fun. When you take into account the fact that Chef can use DSC resources, I think it’s hard to debate the enhancements Chef can offer your configuration management story (and it’s just going to keep getting better!).
SO, DSC OR CHEF?
I say YES!