Windows DSC
| Fiche express | |
|---|---|
| Type | Gestion de configuration déclarative pour Windows |
| Éditeur | Microsoft |
| Techno | PowerShell (blocs Configuration), agent LCM
|
| Équivalents Linux/multi-OS | Ansible (agentless), Puppet (agent) |
| Voir aussi | Powershell · Ansible · Puppet |
Windows DSC (Desired State Configuration) est la plateforme de gestion de configuration déclarative de Microsoft pour l'écosystème Windows/PowerShell. Comme Ansible ou Puppet, elle permet de décrire l'état cible d'une machine (services démarrés, rôles/fonctionnalités Windows installés, fichiers, clés de registre, comptes locaux) plutôt que d'écrire la suite d'actions pour l'atteindre. DSC s'appuie sur des blocs de configuration écrits en PowerShell et sur un agent local, le LCM (Local Configuration Manager), chargé d'appliquer et de maintenir cet état sur la machine.
Anatomie d'une configuration
Une configuration DSC est un script .ps1 contenant un bloc Configuration, qui ressemble syntaxiquement à une fonction PowerShell mais se compile en un document déclaratif (un fichier .mof, au format standard CIM/WMI — Management Object Format) plutôt que de s'exécuter directement.
Configuration WebServerConfig {
param ([string[]]$NodeName = 'localhost')
Import-DscResource -ModuleName PSDesiredStateConfiguration
Node $NodeName {
WindowsFeature IIS {
Ensure = 'Present'
Name = 'Web-Server'
}
File IndexPage {
Ensure = 'Present'
DestinationPath = 'C:\inetpub\wwwroot\index.html'
Contents = '<html><body>Hello DSC</body></html>'
DependsOn = '[WindowsFeature]IIS'
}
Service W3SVC {
Name = 'w3svc'
State = 'Running'
DependsOn = '[WindowsFeature]IIS'
}
}
}
# Compilation : génère un ou plusieurs fichiers .mof (un par nœud ciblé)
WebServerConfig -OutputPath .\WebServerConfig
Chaque bloc à l'intérieur de Node (WindowsFeature, File, Service...) est une invocation de ressource DSC : l'unité de base qui sait vérifier et, si nécessaire, corriger un aspect précis de l'état d'une machine. DependsOn exprime les dépendances d'ordre entre ressources, de façon comparable aux relations d'ordre dans un manifeste Puppet.
Ressources DSC
Une ressource DSC implémente trois opérations conceptuelles (comparables au triptyque get / test / set que l'on retrouve dans d'autres outils de gestion de configuration déclarative) :
- Get — lit l'état actuel de la cible.
- Test — compare l'état actuel à l'état déclaré ; renvoie conforme/non conforme.
- Set — applique les changements nécessaires si
Testa signalé une non-conformité.
Microsoft fournit un socle de ressources intégrées (PSDesiredStateConfiguration : File, Service, Registry, WindowsFeature, Package, User/Group...). Un écosystème de modules complémentaires (souvent distribués via la PowerShell Gallery) couvre des besoins plus spécifiques : rôles Active Directory, IIS avancé, SQL Server, etc. — l'équivalent, pour DSC, des rôles Ansible ou des modules Puppet (Forge).
Le LCM (Local Configuration Manager)
Le LCM est l'agent présent sur chaque nœud Windows, chargé d'appliquer les fichiers .mof compilés et de maintenir la conformité dans la durée. Son comportement se configure lui-même de façon déclarative (méta-configuration) :
[DSCLocalConfigurationManager()]
Configuration LCMConfig {
Node 'localhost' {
Settings {
RefreshMode = 'Push' # ou 'Pull'
ConfigurationMode = 'ApplyAndAutoCorrect'
RefreshFrequencyMins = 30
}
}
}
Deux modes de distribution principaux :
- Push — la configuration compilée (
.mof) est envoyée explicitement au nœud (Start-DscConfiguration), à la demande, depuis un poste d'administration. - Pull — le nœud interroge périodiquement un serveur pull (endpoint HTTP/HTTPS DSC, ou SMB) pour récupérer sa configuration cible et l'appliquer automatiquement — modèle comparable au fonctionnement agent/master d'un master Puppet, à ceci près que le protocole et le format (MOF) sont propres à Microsoft.
Le ConfigurationMode du LCM détermine le comportement en cas de dérive :
- ApplyOnly — applique une fois, ne corrige plus ensuite.
- ApplyAndMonitor — signale la dérive (drift) sans la corriger automatiquement.
- ApplyAndAutoCorrect — réapplique automatiquement l'état déclaré à chaque cycle, à la manière d'un agent Puppet en mode agent/master.
Positionnement face à Ansible et Puppet
| Windows DSC | Ansible | Puppet | |
|---|---|---|---|
| Agent requis | Oui, le LCM (embarqué dans PowerShell/WMF depuis Windows Management Framework 4+ — version exacte à vérifier) | Non (agentless, SSH/WinRM) | Oui (agent + master) |
| Langage | PowerShell (blocs Configuration → compilés en MOF) | YAML (playbooks) | DSL Ruby (manifests) |
| Plateforme cible historique | Windows d'abord (utilisable sur Linux via PowerShell Core, périmètre plus restreint) | Multi-plateforme dès l'origine (Linux, Windows via WinRM, réseau) | Multi-plateforme, historiquement fort sur Linux |
| Modèle de distribution | Push ou Pull (serveur pull optionnel) | Toujours push (exécution à la demande via SSH) | Pull (agent interroge le master périodiquement) |
| Écosystème de modules | PowerShell Gallery, modules DSC tiers | Ansible Galaxy, rôles | Puppet Forge |
Sur un socle très majoritairement Linux, Ansible et Puppet restent les choix par défaut (voir Frontière IaC — Terraform, Ansible, GitOps pour leur articulation avec Terraform). DSC devient pertinent dès qu'une part significative du parc est Windows Server et que l'équipe est déjà outillée en PowerShell : rôles/fonctionnalités Windows, Active Directory, IIS, SQL Server bénéficient de ressources DSC natives et bien maintenues par Microsoft, avec une intégration plus fine à l'écosystème WMI/CIM que ne peuvent l'offrir des outils tiers.
Il existe également une passerelle entre les deux mondes : Ansible dispose de modules capables de piloter des ressources DSC à distance sur des hôtes Windows (win_dsc), permettant de faire cohabiter les deux approches — Ansible en orchestrateur global, DSC pour la conformité fine des ressources Windows spécifiques.