Infrastructure as Code and DSC
Prerequisites: Classes, Managing Windows and the cloud
Scripts describe steps. Declarative configuration describes the desired end state and lets a tool work out the steps — and it can be applied repeatedly with the same result (idempotence).
Idempotent scripts
Even without a framework, write scripts that check before they change:
function Set-DesiredFolder {
[CmdletBinding(SupportsShouldProcess)]
param([string]$Path)
if (Test-Path -LiteralPath $Path) {
"$Path already exists - no change"
} elseif ($PSCmdlet.ShouldProcess($Path, 'Create folder')) {
New-Item -ItemType Directory -Path $Path | Out-Null
"$Path created"
}
}
Set-DesiredFolder -Path logs
Set-DesiredFolder -Path logs
logs created
logs already exists - no change
Running it twice is safe: the second run changes nothing.
Desired State Configuration
DSC is PowerShell's declarative configuration platform. DSC v3
is a cross-platform command-line tool (dsc) that reads YAML or JSON
configuration documents and uses resources — which can be written in
PowerShell — to test and set state:
# web.dsc.yaml
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
- name: IIS feature
type: PSDesiredStateConfiguration/WindowsFeature
properties:
Name: Web-Server
Ensure: Present
- name: App folder
type: PSDesiredStateConfiguration/File
properties:
DestinationPath: C:\inetpub\app
Type: Directory
Ensure: Present
dsc config test --file web.dsc.yaml reports drift; dsc config set
fixes it. Every resource implements Get, Test, and Set —
exactly the idempotent pattern above. (Windows PowerShell 5.1 includes the
older DSC v1 with Configuration blocks and MOF files, still found in many
organizations.)
PowerShell alongside IaC tools
For cloud infrastructure, teams usually declare resources with Bicep,
ARM templates, or Terraform, and use PowerShell around them:
deploying templates (New-AzResourceGroupDeployment), preparing
parameters, validating results, and handling the steps the declarative
tools can't.