Another common challenge with DSC, is how to compose DSC configurations.
People have seen the trick of having a Configuration, and the following code within:
https://gist.github.com/gaelcolas/f4440676ede6027f8a204d0aaac478a8
This is a good way to get started and works well for small-ish configurations, but it gets out of hand pretty quickly, as it’s hard to read all the if statements and their content. Some variant of this are using Where clauses around the Node expression.
I’m writing and using a PowerShell module called “Datum” to manage DSC Configuration Data, and raise cattle at work. This is a write up to explain the problem, and why I’m writing it.
I assume you already know a bit about Desired State Configuration, but if it’s new to you or vague, go grab yourself The DSC Book by Don Jones & Missy Januszko, which packs all you need to know about out-of-the-box DSC, and more.
This post tries to explain the DSC Configuration Data composition challenge that I attempt to solve with Datum. It does not include the solution and how to use Datum to solve those problems: you can look on the GitHub repository and see an example of a Control Repository, or come to the PowerShell Summit 2018, where I’ll be presenting Datum used in a DSC Infrastructure.
Here’s a quick function to allow you something close to splatting with DSC resources:
https://gist.github.com/gaelcolas/96ff332c59a38e682cc7cc3aea730f72
Here’s why you may need it.
I’ve created a template to quickly get started building a sample PowerShell Module that includes different components such as Classes, Enum, private and public functions, DSC Resources, some Unit tests, Quality tests, code coverage, deployment, dependency resolution for build, and AppVeyor Integration.
@gaelcolas 