KomuraSoft LLC
Nous contacter
Menu

Gérer Windows de façon déclarative avec DSC — démarrer l'IaC avec dsc.exe

· Mis à jour le: · · Windows, DSC, IaC, PowerShell, winget, Gestion de configuration

Historique des révisions (première version, publiée le 28 Aug 2026)
Première publication

Le manuel d’installation d’un nouveau PC, la feuille Excel des étapes de construction du serveur, le fichier BAT secret laissé par quelqu’un qui a depuis quitté l’entreprise — dans de nombreux ateliers, la gestion de configuration Windows repose encore sur « un document qui décrit les étapes » et « un script qui exécute les étapes ». La faiblesse de cette approche est claire : les étapes commencent à s’écarter de la réalité dès l’instant où elles sont exécutées, et le script casse à la deuxième exécution.

Sous Linux et dans le cloud, l’IaC déclaratif (Infrastructure as Code) tel que Terraform et Ansible est devenu la norme. Alors, que faut-il utiliser pour gérer les clients et serveurs Windows eux-mêmes avec le même état d’esprit ? La réponse de Microsoft est DSC (Desired State Configuration), et avec Microsoft DSC v3 (dsc.exe), réécrit en 2025 comme outil en ligne de commande indépendant de PowerShell, il a enfin atteint une forme avec laquelle on peut « tout simplement commencer ».1

Cet article s’adresse aux développeurs et aux responsables informatiques qui gèrent la configuration des clients et serveurs Windows avec des manuels de procédure et des scripts, et qui veulent passer à une gestion déclarative. Il suppose Windows 10/11 et DSC 3.0 ou version ultérieure, avec une maîtrise de base de PowerShell comme connaissance préalable. Le niveau de difficulté est intermédiaire.

1. D’abord la conclusion

Avec DSC, vous écrivez l’« état souhaité » en YAML, pas les « étapes à exécuter ». Les ressources prennent en charge la détection de la différence avec l’état actuel (test) et son application (set), donc le même fichier est sûr (idempotent) quel que soit le nombre de fois où vous l’exécutez, et la configuration devient des données que vous pouvez relire dans Git. Si vous commencez maintenant, Microsoft DSC v3 (dsc.exe) est le seul choix.

La différence entre un script de procédure et une configuration déclarative se voit dans la façon dont ils cassent. Un script qui encode des étapes s’arrête sur une double application ou des erreurs lorsque vous le relancez contre une machine qui a échoué en cours de route ou qui est déjà configurée. Une configuration déclarative ne décrit que l’état souhaité, donc quel que soit le nombre de fois où vous l’exécutez, et depuis n’importe quel état intermédiaire, elle converge vers le même résultat.2

Script de procédure impératif versus configuration déclarativeUn script impératif exécute les étapes depuis le haut, donc le relancer provoque une double application ou un arrêt, alors que DSC déclaratif déclare l'état souhaité et n'applique que la différence, donc il converge vers le même état quel que soit le nombre d'exécutionsImpératif : écrire les étapes (BAT, manuel)Exécuter de haut en basRelance : double application, erreursDéclaratif : écrire l'état (DSC)Détecter la différence avec l'état actuelN'appliquer que la différence, sûr à chaque fois

Figure 1 : Un script impératif est sensible au « nombre de fois où il a tourné » ; une configuration déclarative converge vers le même état quel que soit le nombre d’exécutions.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (17 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Démêler la confusion autour du nom « DSC » — quatre lignées

La première chose qui fait trébucher quand on apprend DSC n’est pas la technique elle-même, mais la confusion dans les résultats de recherche. Quatre lignées de mécanismes portent le nom « DSC », et elles diffèrent par la façon de les écrire, de les exécuter, et par ce avec quoi elles sont compatibles.3

Lignée Ce que c’est Position
PSDSC v1.1 Intégré à Windows PowerShell 5.1 Hérité. LCM résident, format MOF
PSDSC v2 Module pour PowerShell 7 PSDesiredStateConfiguration 2.x
PSDSC v3 (préversion) Module PowerShell Pour la prise en charge Linux d’Azure Machine Configuration
Microsoft DSC v3 dsc.exe autonome Sujet de cet article. Indépendant de PowerShell, multiplateforme

Microsoft DSC v3 n’est pas simplement une mise à jour du PowerShell DSC (PSDSC) antérieur ; c’est un produit distinct, réécrit en coupant la dépendance à PowerShell. Les configurations deviennent des données JSON/YAML au lieu de scripts PowerShell, les ressources peuvent être implémentées dans n’importe quel langage, et il s’exécute de la même façon sur Linux, macOS et Windows.1

Lignée des quatre générations DSCDe PSDSC v1.1 intégré à Windows PowerShell 5.1 dérivent PSDSC v2 pour PowerShell 7 et la préversion PSDSC v3 pour Machine Configuration, tandis que Microsoft DSC v3, réécrit séparément sans dépendance à PowerShell, est la lignée principale actuelleréécriturePSDSC v1.1 (intégré à WinPS 5.1)PSDSC v2 (PowerShell 7)PSDSC v3 préversionMicrosoft DSC v3 (dsc.exe)Azure Machine ConfigurationSujet de cet article

Figure 2 : Rechercher « DSC » renvoie des informations des quatre lignées mélangées. Distinguer de quelle lignée parle un article ou un document est la première chose à faire.

Désormais, « DSC » dans cet article désigne Microsoft DSC v3. Que les actifs des générations antérieures ne soient pas perdus est traité plus loin (section 6).

3. Ce que « déclaratif » veut dire — get, test, set et l’idempotence

Le concept central de DSC est la ressource. Une ressource fournit les opérations de récupération de l’état (Get), d’évaluation (Test) et d’application (Set) pour un type de cible de configuration, tel qu’une « valeur du Registre », une « fonctionnalité Windows » ou une « variable d’environnement ». Toute ressource implémente Get. Pour les ressources qui n’implémentent pas Test, DSC se substitue par un test synthétique qui compare le résultat récupéré à la déclaration. Set n’est implémenté que par les ressources qui peuvent imposer un état ; les ressources en lecture seule telles que les informations d’OS ne l’ont pas.4 L’utilisateur laisse le « comment configurer » à la ressource et n’écrit que « ce qui doit être dans quel état » comme données.

Cette division du travail est ce qui produit l’idempotence. Lorsqu’un document de configuration est appliqué (dsc config set), DSC teste d’abord chaque instance et n’appelle set que sur celles qui ne sont pas dans l’état souhaité. C’est pourquoi appliquer la même configuration un nombre quelconque de fois est sûr. Notez une différence : lorsque vous exécutez dsc resource set sur une ressource unique, set est toujours appelé, et le fait qu’un test s’exécute au préalable dépend de l’implémentation de la ressource (implementsPretest).5

La boucle de convergence de get, test et settest compare l'état souhaité écrit dans le document de configuration avec l'état actuel, rien ne se produit s'il n'y a pas de différence, et s'il y en a une, set n'applique que la différence et get confirme le résultat, un flux de convergence idempotentaucune différencedifférenceDocument de configuration (état souhaité)test : comparer avec l'état actuelNe rien faire (idempotent)set : n'appliquer que la différenceget : confirmer l'état résultant

Figure 3 : Appliquer DSC est une boucle « comparer d’abord, puis ne changer que ce qui est nécessaire », qui vous libère de la notion de nombre d’exécutions.

Regardons la différence avec un script impératif dans le code. Prenons « mettre cette valeur dans le Registre » : dans un script, vous écrivez vous-même le test d’existence, la création et la mise à jour, chacun comme sa propre branche.

# Impératif : écrire les "étapes". Vous gérez vous-même chaque branche et chaque ordre
$path = 'HKCU:\Software\MyCompany\App'
if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
Set-ItemProperty -Path $path -Name 'Mode' -Value 'standard'

Dans DSC, vous écrivez la même chose comme déclaration de l’« état souhaité ». Il n’y a ni test d’existence ni branchement.

# Déclaratif : écrire l'"état". Créer et corriger sont le travail de la ressource
- name: Mode de fonctionnement de l'application
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKCU\Software\MyCompany\App
    valueName: Mode
    valueData:
      String: standard

4. Installer dsc.exe et appeler les ressources une par une

Il y a deux façons d’installer DSC. Extraire l’archive de la version GitHub et l’ajouter au PATH, ou, sous Windows, l’installer avec winget depuis la source Microsoft Store.1

# Rechercher et installer la version stable depuis la source Microsoft Store
winget search DesiredStateConfiguration --source msstore
winget install --id 9NVTPZWRC6KQ --source msstore

Une fois installé, commencez par lister les ressources disponibles sur la machine locale.

dsc resource list

Avant d’écrire un document de configuration, vous pouvez aussi appeler les ressources une par une, isolément. Pouvoir « essayer en petit » est ce qui rend la v3 facile à apprendre.6

# Récupérer l'état actuel (get)
dsc resource get --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode"}'

# Évaluer si l'état souhaité est atteint (test) — ne fait aucun changement
dsc resource test --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode","valueData":{"String":"standard"}}'
Les quatre opérations de la commande dsc resourceSous la commande dsc resource pendent quatre opérations, list pour énumérer les ressources, get pour récupérer l'état actuel, test pour évaluer l'état souhaité sans changements, et set pour appliquer l'état (uniquement pour les ressources qui implémentent Set)commande dsc resourcelist : énumérer les ressourcesget : récupérer l'état actueltest : évaluer seulement, aucun changementset : appliquer (ressources qui prennent en charge Set)

Figure 4 : Les ressources peuvent être appelées isolément sans écrire de document de configuration. Commencer par l’observation, avec get et test seulement, est la voie d’entrée sûre.

Les opérations qui font des changements via set, et les ressources qui traitent HKLM ou les paramètres système, exigent des droits d’administrateur. Le plus sûr est de commencer les essais par des exemples dont la cible d’écriture est dans le périmètre de l’utilisateur (par exemple HKCU).

5. Le document de configuration — écrire l’« état souhaité » en YAML

Un document de configuration déclare plusieurs ressources ensemble. Il s’écrit en YAML ou JSON et définit, au minimum, les deux propriétés $schema et resources. Chaque instance de ressource a un name (un nom d’affichage unique dans le document), un type (le nom pleinement qualifié de la ressource) et des properties (l’état souhaité).2

# standard-pc.dsc.config.yaml — l'état souhaité d'un PC client standard
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
parameters:
  appMode:
    type: string
    defaultValue: standard
resources:
  - name: Mode de fonctionnement de l'application
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: "[parameters('appMode')]"

Avec parameters et variables, les différences entre environnements (valeurs de paramètre par service, par exemple) peuvent s’exprimer dans un seul document. La syntaxe d’expression est un sous-ensemble des fonctions de modèles ARM.2

Structure d'un document de configurationUn document de configuration se compose d'un schéma qui identifie le schéma du document, de parameters et variables qui absorbent les différences d'environnement, et d'un tableau resources d'instances de ressources, chacune ayant name, type et propertiesDocument de configuration (YAML / JSON)$schema : URI du schéma du documentparameters / variablesresources : tableau d'instancesname, type, properties

Figure 5 : Un document de configuration est des données simples, rien de plus que « schéma + paramètres + déclarations de ressources » ; ce n’est pas un programme.

Placez toujours l’« observation » avant d’appliquer. dsc config test signale s’il y a des différences sans rien modifier, et dsc config set --what-if affiche une prédiction de « ce qui changerait si cela était exécuté ».7

# 1. Vérifier s'il y a des différences (aucun changement)
dsc config test --file .\standard-pc.dsc.config.yaml

# 2. Afficher une prédiction de ce que l'application changerait (aucun changement)
dsc config set --file .\standard-pc.dsc.config.yaml --what-if

# 3. Appliquer une fois que vous êtes convaincu
dsc config set --file .\standard-pc.dsc.config.yaml

# 4. Confirmer l'état après application
dsc config get --file .\standard-pc.dsc.config.yaml

Il existe aussi un point d’entrée dans l’autre sens. Pour les ressources listées dans le document d’entrée passé avec --file (uniquement celles qui prennent en charge export), dsc config export génère un document de configuration contenant chaque instance sur le système et l’écrit sur la sortie standard. Il peut servir de point de départ pour consigner l’état actuel d’un environnement existant.8

# Passer un document d'entrée listant les ressources cibles et enregistrer le document de configuration actuel
dsc config export --file .\export-targets.dsc.config.yaml > .\current-state.dsc.config.yaml
Les quatre étapes d'une application sûreVérifier les différences avec dsc config test, qui ne fait aucun changement, prévisualiser les changements avec l'option what-if de dsc config set, appliquer avec set une fois convaincu, et confirmer le résultat avec get, dans cet ordre sûrdsc config test (vérifier les différences)set --what-if (prédire les changements)dsc config set (appliquer)dsc config get (confirmer le résultat)

Figure 6 : Tant que vous conservez l’ordre « observer, prédire, appliquer, confirmer », appliquer une configuration déclarative n’a rien de la peur d’un coup unique.

Qu’un document de configuration soit des données, et non un programme, est son plus grand avantage opérationnel. « Ce qui doit être configuré sur cette machine » se relit comme un diff YAML, et l’historique des changements est, tel quel, l’historique des changements de la configuration.

6. Réutiliser les actifs existants — adaptateurs pour les ressources PSDSC et WinGet Configuration

Entendre que « la v3 est un produit distinct » fait craindre pour les actifs passés, mais DSC v3 peut appeler les ressources PSDSC des générations antérieures via un mécanisme appelé ressources d’adaptateur. Sous les noms actuels dans DSC 3.2 et versions ultérieures, Microsoft.Adapter/PowerShell dessert les ressources basées sur des classes pour PowerShell 7 et Microsoft.Adapter/WindowsPowerShell dessert les ressources basées sur MOF et sur des scripts pour Windows PowerShell 5.1 (auparavant elles s’appelaient Microsoft.DSC/PowerShell et Microsoft.Windows/WindowsPowerShell).9 L’écosystème de ressources PSDSC accumulé sur de nombreuses années est joignable directement depuis un document de configuration v3.

L’autre point de connexion est WinGet Configuration. Les fichiers .winget présentés dans l’article sur le déploiement de postes utilisent DSC v3 directement comme processeur à partir du schéma v3 (WinGet 1.11 et versions ultérieures). Lorsque vous spécifiez dscv3 comme processeur dans les metadata du fichier de configuration, le corps du document est lui-même un document de configuration DSC v3.10

# WinGet Configuration v3 — le corps est un document de configuration DSC v3
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor:
      identifier: dscv3
resources:
  - name: Mode de fonctionnement de l'application
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: standard

Il y a une mise en garde. Un fichier existant au format v2 (le format avec properties.configurationVersion: 0.2.0 et les ressources placées sous properties) ne s’exécute pas tel quel sous le processeur dscv3. Les fichiers v2 continuent de fonctionner avec l’ancien processeur, mais pour les placer sur DSC v3, vous migrez le format en suivant le guide officiel de conversion (« Convert to v3 » dans le dépôt d’exemples).10

La structure en couches centrée sur DSC v3Les couches d'orchestration telles que winget configure et Azure Machine Configuration appellent DSC v3, et DSC v3 appelle les ressources natives directement et les ressources PSDSC existantes via des ressources d'adaptateurwinget configure, Machine Configurationdsc.exe (DSC v3)Ressources natives (Registry etc.)Ressources d'adaptateurRessources PSDSC existantes (actifs PowerShell)

Figure 7 : DSC v3 est un outil autonome et, en même temps, le fondement commun sous des outils de niveau supérieur tels que winget et Azure. Les actifs PSDSC existants pendent sous l’adaptateur.

Autrement dit, les connaissances et les configurations que vous écrivez pour la v3 fonctionnent avec dsc.exe sur votre propre machine, avec winget configure lors du déploiement de postes, et avec Machine Configuration dans la gestion cloud. Ce n’est pas un réapprentissage ; les chemins se rejoignent.1

7. Le mettre en exploitation — gérer dans Git et détecter la dérive

L’endroit où conserver les documents de configuration est un dépôt Git. Les changements de configuration suivent alors le même flux que le développement logiciel : revue dans une pull request, fusion, application. La notion même d’un manuel de procédure que personne n’a mis à jour disparaît.

Le défi après l’application est la dérive de configuration (quelqu’un change un paramètre à la main, et la machine s’éloigne de l’état souhaité). Dans DSC, la détection de dérive consiste simplement à exécuter dsc config test de façon planifiée. Parce que test ne fait aucun changement, la détection et la correction peuvent être séparées, ce qui est une propriété importante. Le schéma d’exploitation sûr est d’automatiser d’abord la détection, et de corriger (set) seulement après avoir vérifié quelles sont les différences.

# Pour les exécutions planifiées : distinguer un échec de test lui-même, les erreurs par ressource et la dérive, et terminer non nul dans tous les cas
$json = dsc config test --file C:\config\standard-pc.dsc.config.yaml
if ($LASTEXITCODE -ne 0 -or -not $json) {
    Write-Error "dsc config test lui-même a échoué (code de sortie : $LASTEXITCODE)"
    exit 2
}
$result = $json | ConvertFrom-Json
if ($result.hadErrors) {
    # La validation du document a échoué ou une ressource s'est terminée non nulle. La vérification n'est pas allée au bout, donc ne pas signaler comme sain
    Write-Error "La vérification de certaines ressources s'est terminée en erreurs. Examiner messages"
    exit 2
}
if ($result.results.result.inDesiredState -contains $false) {
    Write-Error "Dérive de configuration détectée"
    exit 1
}

Pour l’infrastructure de planification, le Planificateur de tâches convient sur les clients (la conception de l’exécution sans surveillance est traitée dans un article distinct) et les runners CI conviennent pour les parcs de serveurs. Pour les organisations qui ont regroupé la gestion dans Azure, Machine Configuration est le service d’orchestration géré qui audite et applique la configuration aux machines virtuelles Azure et, via Azure Arc, aux serveurs locaux.11

Le cycle d'exploitation de la gestion de configuration partant de GitLes documents de configuration conservés dans un dépôt Git sont relus dans une pull request avant d'être appliqués, des exécutions périodiques de test depuis le Planificateur de tâches ou la CI détectent la dérive, et après inspection de la différence le cycle revient à la correction ou à la mise à jour de la configurationdérive détectéela configuration est justela réalité est justeDépôt Git (documents de configuration)Changements relus dans des pull requestsAppliquer avec dsc config setExécution planifiée : dsc config testInspecter la différence et déciderCorriger avec set

Figure 8 : Traiter la dérive n’est pas seulement « corriger ». Si le changement fait sur le terrain est le bon, corriger le document de configuration et le fusionner est la pratique propre de la gestion déclarative.

La branche en bas à droite de la figure 8 est facile à manquer. La dérive n’est pas toujours « mauvaise » ; parfois elle signifie seulement qu’un changement nécessaire sur le terrain n’a pas encore été reporté dans la configuration. Dans ce cas, plutôt que de ramener la machine en arrière, mettez à jour le document de configuration pour qu’il corresponde à la réalité. Tant que vous tenez la discipline selon laquelle la source de vérité est toujours la déclaration dans Git, la gestion ne casse pas, quel que soit le côté vers lequel vous penchez.

8. Contraintes et pièges

Voici, franchement, les contraintes à connaître avant d’adopter.

Il n’y a pas de LCM. Le LCM (Local Configuration Manager) de la v1.1 était un agent résident qui conservait la configuration et effectuait l’application périodique et la correction automatique. La v3 est « une commande qui ne s’exécute que lorsqu’elle est appelée » et ne reste pas résidente comme service.1 Si vous avez besoin d’une imposition continue, vous devez choisir vous-même l’infrastructure d’exécution (Planificateur de tâches, CI, Machine Configuration), comme dans la section précédente. Ce n’est pas une régression mais un changement de conception qui ouvre « la façon dont cela s’exécute » aux outils modernes ; cela reste déroutant si l’on arrive avec l’état d’esprit de l’exploitation pull server de la v1.1.

Gestion des droits d’administrateur. set sur les ressources qui affectent toute la machine (HKLM, fonctionnalités Windows, etc.) exige une élévation, et l’utilisation de ressources PSDSC Windows PowerShell via l’adaptateur suppose aussi une exécution en tant qu’administrateur.6 Séparer les paramètres par utilisateur des paramètres par machine dès l’étape du document de configuration facilite la conception du contexte d’exécution.

N’écrivez pas de secrets dans la configuration. Les documents de configuration sont des données qui vont dans Git. N’y écrivez pas directement des mots de passe ou des clés d’API ; paramétrez-les et passez-les à l’exécution.

Lisez les fichiers de configuration d’autrui avant de les exécuter. Un document de configuration a le pouvoir de modifier le système via les ressources. Avant d’appliquer un fichier .winget ou un document de configuration obtenu depuis un dépôt public, vérifiez son contenu et la fiabilité des ressources qu’il référence. C’est une obligation opérationnelle contre laquelle la documentation officielle, elle aussi, met explicitement en garde.12

Le LCM résident de la v1.1 versus le modèle de commande de la v3Dans PSDSC v1.1 un LCM résident conservait la configuration et gérait le pull périodique et la correction automatique, alors que DSC v3 n'est lancé que comme commande, donc vous choisissez et préparez vous-même l'infrastructure de planification parmi le Planificateur de tâches, la CI et Machine ConfigurationPSDSC v1.1 : LCM résidentConserve la configuration, pull périodique, correction automatiqueDSC v3 : invocation de commande seulementVous fournissez l'infrastructure d'exécutionPlanificateur de tâches, CI, Machine Configuration

Figure 9 : Dans la v3, il n’y a personne « qui se souvient de la configuration et la corrige tout seul ». Que vous le preniez pour un inconvénient ou pour un regain de contrôle sur l’exécution, c’est là que se situe la décision de conception.

9. Synthèse — remplacer le manuel de procédure par un dépôt

  • Si vous commencez maintenant l’IaC déclaratif pour Windows, utilisez Microsoft DSC v3 (dsc.exe). Parmi les quatre lignées appelées « DSC », soyez toujours conscient de celle dont parlent les informations que vous lisez.3
  • DSC écrit l’« état souhaité », pas les « étapes », en YAML/JSON, et test (comparer) et set (appliquer la différence) garantissent une convergence idempotente. Le flux sûr consiste à commencer par l’observation via dsc resource get/test, à vérifier l’impact avec --what-if, puis à appliquer.7
  • Les ressources PSDSC existantes rejoignent le monde v3 via les adaptateurs, et les actifs .winget de déploiement de postes via le schéma v3 de WinGet Configuration (les fichiers au format v2 nécessitent une migration de format suivant le guide de conversion).910
  • La v3 n’a pas de LCM. L’ossature de l’exploitation est de conserver la source de vérité dans Git, de détecter la dérive par des exécutions planifiées de dsc config test, et de suivre la discipline « si la configuration est juste, corriger ; si la réalité est juste, mettre à jour la configuration ».

Le destin d’un manuel de procédure était de s’écarter de la réalité dès l’instant où il était écrit. La gestion de configuration déclarative transforme cet écart en une « différence détectable ». Commencez par écrire une poignée de paramètres de votre propre machine dans un document de configuration et par exécuter dsc config test. Vous devriez sentir comment le manuel de procédure se transforme en dépôt.

Articles associés

Domaines de conseil associés

KomuraSoft LLC accompagne la migration de la configuration des clients et serveurs Windows vers une gestion déclarative, l’automatisation du déploiement de postes et des environnements internes standard, et la transformation de manuels de procédure dépendants d’une personne en quelque chose d’exécutable.

Références

  1. Microsoft Learn, Microsoft Desired State Configuration overview. Sur le fait que DSC v3 est une plateforme de configuration déclarative et idempotente qui s’exécute sur Linux, macOS et Windows sans dépendre de PowerShell ; sur le fait qu’elle n’inclut pas de LCM (Local Configuration Manager), qu’elle est lancée comme commande et qu’elle ne reste pas résidente comme service ; sur sa compatibilité avec les ressources PSDSC via des ressources d’adaptateur ; sur l’installation depuis la source Microsoft Store de winget (ID stable 9NVTPZWRC6KQ) ou depuis les versions GitHub ; et sur le fait que WinGet, Microsoft Dev Box et Azure Machine Configuration sont des partenaires précoces à la couche d’orchestration. ↩ ↩2 ↩3 ↩4 ↩5

  2. Microsoft Learn, DSC configuration documents. Sur le fait qu’un document de configuration est un fichier de données YAML/JSON qui déclare l’état souhaité tandis que « comment le configurer » est la responsabilité de la ressource ; sur le fait que les propriétés obligatoires sont $schema et resources, chaque instance ayant name, type et properties ; sur le fait que parameters et variables réduisent les définitions en double et expriment des valeurs dynamiques ; sur le traitement des documents par les quatre opérations dsc config get/test/set/export ; et sur la prise en charge d’un sous-ensemble des fonctions d’expression des modèles ARM. ↩ ↩2 ↩3

  3. Microsoft Learn, Desired State Configuration (DSC) Overview. Sur le fait que DSC a quatre versions (PSDSC 1.1 intégré à Windows PowerShell 5.1, PSDSC 2.0 pour PowerShell 7, la préversion PSDSC 3.0 utilisée pour la prise en charge Linux d’Azure Machine Configuration, et Microsoft DSC 3.0 comme produit autonome qui ne dépend pas de PowerShell), et sur le fait que Microsoft DSC 3.0 est véritablement multiplateforme et capable d’utiliser les ressources PSDSC existantes. ↩ ↩2

  4. Microsoft Learn, DSC Resources. Sur le fait qu’une ressource est une interface standardisée vers une cible de configuration, où vous écrivez « quel est l’état souhaité » en syntaxe déclarative et la ressource prend en charge « comment le configurer » ; sur le fait que les ressources ont toujours les opérations Get et Test et que la plupart prennent aussi en charge l’imposition via Set ; sur la désignation des ressources par nom de type pleinement qualifié (owner.group.area/name) ; et sur le fait que les ressources d’adaptateur rendent utilisables les ressources qui ne sont pas des commandes. ↩

  5. Microsoft Learn, dsc resource set. Sur le fait que dsc config set teste toujours chaque instance (avec l’implémentation test de la ressource ou un test synthétique) et n’appelle set que sur les instances qui ne sont pas dans l’état souhaité ; sur le fait que, par contraste, dsc resource set autonome appelle toujours set, tout pré-test dépendant de set.implementsPretest dans le manifeste de la ressource ; et sur le fait qu’exécuter dsc resource test avant set est recommandé pour les ressources sans implementsPretest. ↩

  6. Microsoft Learn, Get started with DSC. Sur le flux d’introduction consistant à découvrir les ressources, à les appeler individuellement et à gérer les documents de configuration ; sur le fonctionnement individuel de la ressource Microsoft.Windows/Registry avec get, test et set ; sur la validation, l’application et la confirmation d’une configuration avec dsc config test/set/get ; et sur le besoin d’un terminal administrateur lorsqu’on travaille avec des ressources PSDSC Windows PowerShell. ↩ ↩2

  7. Microsoft Learn, dsc config set. Sur le fait que dsc config set est la commande qui applique au système l’état souhaité d’un document de configuration, et sur le fait que l’option –what-if affiche une prédiction de « ce qui changerait, et comment, si cela était exécuté » sans réellement rien modifier. Également, d’après DSC Resource manifest whatIf property, sur le fait que cette information est synthétisée à partir du résultat de test lorsqu’une ressource n’implémente pas directement le comportement what-if. ↩ ↩2

  8. Microsoft Learn, dsc config export. Sur le fait que la sous-commande export génère et renvoie un document de configuration qui définit chaque instance existante des ressources listées dans le document d’entrée passé avec –file ou –input ; et sur le fait que le document d’entrée est limité aux ressources dont le manifeste a une section export, chaque type de ressource n’étant déclaré qu’une fois. ↩

  9. Microsoft Learn, Microsoft.Adapter/WindowsPowerShell. Sur le fait que la ressource d’adaptateur permet à DSC v3 de découvrir et d’appeler des ressources PSDSC compatibles Windows PowerShell 5.1 (script, classe et binaire) ; sur le fait qu’elle utilise le module intégré PSDesiredStateConfiguration 1.1 ; sur le fait que ce nom remplace l’ancien adaptateur Microsoft.Windows/WindowsPowerShell dans DSC 3.2 ; et sur l’utilisation de Microsoft.Adapter/PowerShell (anciennement Microsoft.DSC/PowerShell) pour les ressources basées sur des classes sous PowerShell 7. ↩ ↩2

  10. Microsoft Learn, WinGet Configuration file v3 schema reference. Sur le fait que le schéma v3 de WinGet Configuration utilise DSC v3 comme processeur ; sur le besoin de WinGet 1.11 ou version ultérieure et du processeur dscv3 (installé automatiquement comme package distinct Microsoft.DesiredStateConfiguration) ; sur la spécification de dscv3 dans metadata.winget.processor.identifier et l’écriture de resources directement à la racine du document ; et sur le fait qu’un guide de conversion depuis le format v2 est fourni dans le dépôt officiel d’exemples. ↩ ↩2 ↩3

  11. Microsoft Learn, Understanding Azure Machine Configuration. Sur le fait que la fonctionnalité Machine Configuration d’Azure Policy audite et configure les paramètres dans l’OS, de façon gérée, pour les machines virtuelles Azure et les serveurs compatibles Azure Arc. ↩

  12. Microsoft Learn, commande configure (winget). Sur le fait que winget configure est la commande qui met une machine dans un état souhaité avec un fichier WinGet Configuration ; sur l’avertissement de relire le contenu du fichier et de vérifier la fiabilité des ressources concernées avant de l’exécuter ; et sur les sous-commandes show/list/test/validate/export pour afficher le contenu d’un fichier, lister les configurations appliquées, comparer l’état actuel à l’état souhaité, valider un fichier et exporter une configuration. ↩

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Il semble y avoir plusieurs versions de DSC. Laquelle dois-je utiliser ?
Si vous commencez maintenant une gestion de configuration déclarative, prenez Microsoft DSC v3 (dsc.exe). Il existe quatre lignées de DSC : PSDSC v1.1 intégré à Windows PowerShell 5.1, PSDSC v2 comme module pour PowerShell 7, PSDSC v3 (préversion) utilisé pour la prise en charge Linux d'Azure Machine Configuration, et Microsoft DSC v3, réécrit comme commande autonome qui ne dépend pas de PowerShell. La v3 est multiplateforme, écrit la configuration comme données YAML/JSON plutôt que comme scripts PowerShell, et peut réutiliser les ressources PSDSC existantes via des adaptateurs. Lors des recherches, ajouter "DSC v3" ou "dsc.exe" facilite la séparation du matériel des générations antérieures.
Quelle est la différence entre DSC v3 et un script de procédure (BAT ou PowerShell) ?
Un script de procédure décrit "les étapes à exécuter", donc vous devez construire vous-même l'idempotence pour éviter une double application ou des erreurs à la deuxième exécution. DSC écrit l'"état souhaité" comme données, et les ressources prennent en charge la comparaison avec l'état actuel (test) et l'application de la différence (set). Quel que soit le nombre de fois où vous exécutez le même document de configuration, il ne fait rien aux éléments déjà dans l'état souhaité, donc vous pouvez le distribuer et le relancer sans vous soucier du nombre d'exécutions. Et parce que la configuration est des données YAML, les revues de diff et l'historique de versions dans Git sont nettement plus simples qu'avec des scripts.
Mes ressources PowerShell DSC existantes et mes actifs WinGet Configuration seront-ils perdus ?
Non. DSC v3 peut appeler les ressources PSDSC existantes, basées sur des classes ou sur MOF, via des ressources d'adaptateur (Microsoft.Adapter/PowerShell et Microsoft.Adapter/WindowsPowerShell dans DSC 3.2 et versions ultérieures ; Microsoft.DSC/PowerShell et Microsoft.Windows/WindowsPowerShell auparavant). WinGet Configuration, à partir de son schéma v3 (WinGet 1.11 et versions ultérieures), utilise DSC v3 comme processeur. Les fichiers .winget au format v2 existants continuent de tourner sur l'ancien processeur, mais pour les placer sur le processeur DSC v3, il faut les convertir au format v3 en suivant le guide officiel de conversion.
Comment imposer une configuration "en continu" avec DSC v3 ?
DSC v3 lui-même est un outil lancé comme commande ; il n'a ni agent résident ni mécanisme de correction automatique comme le LCM (Local Configuration Manager) de la v1.1. Si vous avez besoin d'une application et d'un audit continus, construisez vous-même la détection de dérive en exécutant dsc config test périodiquement depuis le Planificateur de tâches ou la CI, ou placez-le sur une couche d'orchestration telle qu'Azure Machine Configuration (qui peut aussi couvrir les serveurs locaux via Azure Arc).
Je n'ose pas lancer dsc config set tout de suite. Puis-je vérifier l'impact au préalable ?
Oui. L'exécution de dsc config test montre quelles instances de ressources ne sont pas dans l'état souhaité, sans rien modifier. De plus, dsc config set a une option --what-if qui affiche une prédiction de "ce qui changerait, et comment, si cela était exécuté" sans rien modifier réellement. Vérifiez d'abord les différences avec test et --what-if, et n'exécutez set que lorsque vous êtes convaincu ; cette séquence est sûre.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.

Nous contacter
Retour au blog