Just writing down that title feels like the beginning of a rant! I can’t believe we’re still debating the subject… But hear me out, I’ll try to be constructive.
Page 2 of 3
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Configuration MyDSCConfig { | |
| Node $ConfigurationData.AllNodes.nodename { | |
| if($Node.roles -contains 'MyRole') { | |
| # do stuff here, like calling DSC Resources | |
| MyCompositeResource StuffForMyRole { | |
| # … | |
| } | |
| } | |
| if($Node.roles -contains 'MyOtherRole') { | |
| MyOtherResource OtherStuff { | |
| # … | |
| } | |
| } | |
| } | |
| } |
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| function Get-DscSplattedResource { | |
| [CmdletBinding()] | |
| Param( | |
| [String] | |
| $ResourceName, | |
| [String] | |
| $ExecutionName, | |
| [hashtable] | |
| $Properties | |
| ) | |
| $stringBuilder = [System.Text.StringBuilder]::new() | |
| $null = $stringBuilder.AppendLine("Param([hashtable]`$Parameters)") | |
| $null = $stringBuilder.AppendLine(" $ResourceName $ExecutionName { ") | |
| foreach($PropertyName in $Properties.keys) { | |
| $null = $stringBuilder.AppendLine("$PropertyName = `$(`$Parameters['$PropertyName'])") | |
| } | |
| $null = $stringBuilder.AppendLine("}") | |
| Write-Debug ("Generated Resource Block = {0}" -f $stringBuilder.ToString()) | |
| [scriptblock]::Create($stringBuilder.ToString()).Invoke($Properties) | |
| } | |
| Set-Alias –Name x –Value Get-DscSplattedResource |
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.
I’ve for long thought Interface Testing was the most repetitive yet critical task to let a Module or commands evolve without breaking backward compatibility, and upsetting those who depends on it.
While Unit Testing ensures the code behaves as expected and meets its design and requirements, Interface Testing for commands or functions focuses on the contracts it offers to its consumer. It ensures the contracts (the command prototype or syntax) are consistent over time.
This is the second article in a “getting started with DSC Development”, covering tools and workflow. The previous post was covering general Windows Automation techniques, some of them existing since the Windows XP days and before!
This time we’ll look at tools, techniques and workflow that will enable us to make changes using scientific method, iteratively.
This is the first article in a series that aim to explore one way of getting started with DSC Development, covering tools and workflow.
In very short and abstract, the life cycle of a Windows Server could look like:
- Deployment (aka OSD)
- Configuration
- Maintenance
- Decommission
This series aims to focus at the Configuration part, mainly in its development phase, but also covers the basics of creating windows Image for experimentation purposes. The idea is to get started experimenting quickly, but I would not use this approach of Image creation for something that needs to be maintained.
I really wanted to play with the Azure Stack, but as a Cloud automation consultant, I don’t have access to a lot of hardware. Most of what I deal with is already in the Cloud, so how do you run one? Moreover, the hardware requirements are high, because the technical preview is only installable on a single host, colocating all its components for now.
@gaelcolas 