Desired State Configuration (DSC)

Introduction

Depuis quelque temps, on entend beaucoup parler de systèmes de gestion de configuration. Ils permettent de configurer un ensemble de machines de manière idempotente et en un temps record. L’idempotence est la caractéristique d’une opération à toujours reproduire le même résultat, peu importe l’environnement. Dans le cas présent, il s’agit de toujours avoir la même configuration, quel que soit le nombre de machines. Microsoft a créé Desired State Configuration (DSC) dans ce but. Il existe d’autres solutions similaires, la plus connue aujourd’hui est sans doute Ansible, mais on trouve aussi Chef et Puppet.

DSC permet d’éviter les dérives de configuration. Si le cas se présente, il est capable de remédier à la situation. L’autre avantage sur la gestion de configuration est le temps gagné en termes de résolution d’incidents. Pourquoi plancher une journée entière sur un serveur en panne alors qu’il peut être redéployé et opérationnel en 15 minutes ? Cela représente un réel atout dans une stratégie de cloud. D’ailleurs, Microsoft l’a parfaitement compris, car DSC est utilisable depuis la plateforme de cloud Azure.

Historiquement, on utilisait les stratégies de groupes (GPO) pour mettre...

Versions et plateformes supportées par DSC

Historiquement, DSC est apparu avec la version 4.0 de PowerShell, sous Windows 8.1. La version du moteur DSC était alors 1.0. De plus, la version de DSC était liée à la version de PowerShell et suivait le même rythme de développement. On retrouve donc la version 1.1 du moteur DSC sur Window PowerShell V5.1, et la version 2.0 du moteur sur PowerShell 7.1. Récemment, les équipes DSC et PowerShell ont décidé de séparer la montée de version du moteur DSC de celle de PowerShell, et ce depuis PowerShell 7.2.

En quoi les versions 1.1 et 2.0 sont-elles si divergentes ? Pour le savoir il est possible de se référer à la documentation : https://learn.microsoft.com/en-us/powershell/dsc/overview?view=dsc-2.0#changes-from-dsc-11

Pour résumer :

Pour comprendre l’écart entre les versions 1.1 et 2.0 il faut comprendre le but de la version 2.0. À l’origine, elle a été créée pour répondre à un besoin Azure : Azure Machine Configuration (anciennement Guest Configuration). L’idée...

Vue d’ensemble de la solution

Pour mieux appréhender la solution qu’est DSC, nous allons rapidement présenter chaque partie jouant un rôle essentiel dans le fonctionnement global. DSC a la particularité d’avoir été conçu spécialement autour de PowerShell. Ainsi, de l’écriture des configurations au déploiement de celles-ci, tout est réalisé par des commandes PowerShell. Microsoft ne propose pas d’interface graphique pour administrer la solution. Toutefois, on peut compter sur PowerShell ISE et Visual Studio Code pour nous aider dans la conception des configurations.

La plupart des éléments présentés dans ce chapitre sont limités à la version 1.1 du moteur DSC.

Ressources DSC

Les ressources DSC contiennent les instructions de configuration d’un composant particulier. Le LCM utilise les ressources DSC pour configurer l’hôte sur lequel il se trouve en se basant sur un fichier MOF.

Il est primordial que les ressources dont a besoin un LCM soient disponibles localement dans le cas d’une configuration en mode PUSH, ou sur un PULL Server distant dans le cas du mode PULL.

Dans les sections qui suivent, nous allons voir comment trouver la bonne ressource et adapter sa syntaxe à notre besoin.

PS > Get-DscResource 
 
ImplementedAs   Name                      ModuleName 
-------------   ----                      ---------- 
Binary          File 
Binary          SignatureValidation 
PowerShell      PackageManagement         PackageManagement 
PowerShell      PackageManagementSource   PackageManagement 
PowerShell      PsModule                  PowerShellGet 
PowerShell      PsRepository              PowerShellGet 
PowerShell      Archive                   PSDesiredStateConfig... 
PowerShell      Environment               PSDesiredStateConfig... 
PowerShell      Group                     PSDesiredStateConfig... ...

Création d’une première configuration

Une configuration DSC se crée à l’aide du mot-clé configuration. Une configuration est très proche d’une fonction ou d’un workflow. Tous acceptent un nom et une définition de paramètres. De même que leur utilisation passe par l’appel de leur nom directement dans la console, comme une simple commande PowerShell.

1. Création rapide avec ISE

En début de chapitre, nous avons abordé de manière générique la syntaxe d’une configuration. Dans la section qui suit, nous allons rassembler tout ce que nous avons, configuration et ressources pour former une première configuration DSC. Puis nous approfondirons cette configuration en ajoutant de nouveaux éléments.

Pour commencer sereinement l’écriture d’une configuration, on utilise l’aide de PowerShell ISE et de ses snippets. Historiquement, on pouvait faire de même avec VSCode, mais les références à DSC dans les snippets proposées par PowerShell ne sont plus présentes. On voit là encore cette volonté de scission entre DSC et PowerShell.

 Ouvrez PowerShell ISE. Dans un nouveau fichier, faites un clic droit et sélectionnez Start Snippets (Démarrer les extraits en français). Dans la liste déroulante qui s’affiche, cliquez sur DSC configuration (simple) :

Utilisation du snippet DSC Configuration dans PowerShell ISE

Le résultat :

configuration Name 
{ 
    # Possibilité d'évaluation des expressions pour obtenir 
la liste des noeuds 
    # Exemple : $AllNodes.Where("Role -eq Web").NodeName 
    node ("Node1","Node2","Node3") 
    { 
        # Appel du fournisseur de ressources 
        # Exemple : WindowsFeature, File 
        WindowsFeature FriendlyName 
       { 
           Ensure = "Present" 
 ...

Configuration du LCM

Le LCM est le moteur en charge d’appliquer les configurations DSC à destination de son système hôte (nœud).

La configuration est décrite dans un fichier MOF généré lors de l’appel d’une configuration script.

PS > Get-DSCLocalConfigurationManager 
 
ActionAfterReboot              : ContinueConfiguration 
AgentId                        : 2B7CB1C9-70BD-11E8-80DB-00155D01 
                                 0108 
AllowModuleOverWrite           : False 
CertificateID                  : 
ConfigurationDownloadManagers  : {} 
ConfigurationID                : 
ConfigurationMode              : ApplyAndMonitor 
ConfigurationModeFrequencyMins : 15 
Credential                     : 
DebugMode                      : {NONE} 
DownloadManagerCustomData      : 
DownloadManagerName            : 
LCMCompatibleVersions          : {1.0, 2.0} 
LCMState                       : Idle 
LCMStateDetai                  : ...

Fichiers MOF

MOF (Managed Object Format) est un format de fichier défini par le DMTF. MOF s’appuie sur le format IDL (Interface Definition Language) pour structurer le fichier.

La syntaxe MOF est écrite de manière à être compréhensible à la fois par l’homme et la machine. Elle permet de définir des classes orientées objet ainsi que des instances.

/* 
@TargetNode='SRV2K22' 
@GeneratedBy=administrateur 
@GenerationDate=06/15/2018 18:56:57 
@GenerationHost=SRV2K22 
*/ 
 
instance of MSFT_RoleResource as $MSFT_RoleResource1ref 
{ 
ResourceID = "[WindowsFeature]WindowsBackup"; 
 Ensure = "Present"; 
 SourceInfo = "::5::9::WindowsFeature"; 
 Name = "Windows-Server-Backup"; 
 ModuleName = "PsDesiredStateConfiguration"; 
 
ModuleVersion = "1.0"; 
 
 ConfigurationName = "ConfigBackup"; 
 
}; 
instance of MSFT_FileDirectoryConfiguration as 
$MSFT_FileDirectoryConfiguration1ref 
{ 
ResourceID = "[File]BackupFolder"; 
 Type = "Directory"; 
 Ensure = "Present"; 
 DestinationPath = "C:\\Backup"; ...

Sécurité et contexte d’exécution (credentials)

Le LCM s’exécute avec le compte LocalSystem. Cela représente une forte contrainte lorsqu’une configuration nécessite de contacter une ressource réseau, comme un partage SMB. En effet, le nœud se voit refuser l’accès.

Pour pallier cette contrainte, plusieurs solutions sont possibles :

La première solution a un rayon d’action très limité. En effet, si l’on veut installer un contrôleur de domaine, des credentials de domaine sont nécessaires et la solution ne s’applique pas ici.

On peut alors opter pour la seconde solution. Seulement, étant donné que l’application d’une configuration passe par la génération d’un fichier MOF, ce dernier contient les informations d’identification, soit le nom du compte et le mot de passe. Deux choix s’offrent alors. Le premier consiste à inscrire le mot de passe en clair dans le fichier, avec tous les problèmes de sécurité que cela implique. Le second choix consiste à configurer des certificats pour crypter les mots de passe à l’intérieur du fichier MOF. La mise en place est toutefois beaucoup plus contraignante....

Sécurisation des credentials dans une configuration

Pour certaines ressources, il est nécessaire d’utiliser des credentials dans des configurations. Ce besoin peut se présenter si le nœud doit accéder à un partage réseau, ou encore si l’on doit le promouvoir contrôleur de domaine.

L’utilisation de credentials engendre un stockage du login et du mot de passe à l’intérieur du fichier MOF généré. Ce mot de passe peut se présenter de deux manières :

Bien évidemment, le premier cas est réservé aux environnements de test. La mise en place du chiffrement doit se faire impérativement dans les autres environnements, car on peut douter qu’un manager apprécie le stockage en clair du mot de passe de l’administrateur du domaine, sur un environnement de production. D’autant plus si on utilise un serveur PULL, centralisant l’ensemble des configurations en un seul point.

Configuration d’un PULL Server

Le mode PULL présente de gros avantages comparativement au mode PUSH. En effet, dans un environnement de grande ampleur, réaliser les configurations de serveur en mode PUSH présente rapidement des limites.

L’objectif du mode PULL est de centraliser les configurations de chaque nœud et de faire en sorte qu’ils procèdent eux-mêmes au téléchargement de nouvelles configurations, et surtout au téléchargement automatique des ressources DSC nécessaires à l’application des configurations.

Le PULL Server Web apporte également la possibilité de mettre en place des rapports pour suivre l’état de conformité de chaque nœud.

Principe avancé

Au début de DSC sous PowerShell version 4.0, il n’était pas possible d’appliquer plusieurs configurations sur un même hôte. On rencontrait alors de grandes difficultés pour mettre à jour une partie de la configuration, car les fichiers de configuration devenaient énormes. La solution de contournement mise en avant était la création de ressources dites composites. Ces dernières contiennent en réalité un sous-ensemble de ressources DSC préconfiguré dans une configuration. Il était alors possible de les appeler directement dans une configuration.

Depuis PowerShell versions 5.1, la contrainte de configuration unique a été levée. Il est maintenant possible de créer un ensemble de configurations avec des noms différents à destination d’un même hôte. Ces configurations sont appelées configurations partielles (ou partial configuration en anglais).

Ces deux solutions seront vues dans cette section. Dans l’ancienne version de cet ouvrage, il a été conseillé d’utiliser en priorité les configurations partielles. Il s’avère que les ressources composites sont plutôt à prioriser. Pourquoi ? Pour limiter les conflits entre configurations. Il est plus cohérent d’appliquer une configuration unique, validée par une équipe unique, plutôt qu’un ensemble de configurations disparates réparties entre plusieurs équipes qui ne communiquent pas forcément. Les risques de dérives seront bien moins présents et le contrôle de la configuration des nœuds sera plus efficient.

Écriture d’une ressource personnalisée

Même si aujourd’hui les ressources créées par la communauté et mises à disposition sur la PowerShell Gallery sont assez importantes, elles ne couvrent pas tous les besoins. Dans cette optique, Microsoft permet de créer des ressources DSC personnalisées.

La ressource Script permet d’offrir une méthode de traitement personnalisé sur un nœud (voir la section Ressources DSC - Ressources intégrées). Toutefois, celle-ci manque de flexibilité.

Pour cette raison, on peut opter pour l’une des deux méthodes décrites ci-après. La première est présente depuis la version 4.0 de Windows PowerShell. Elle utilise une structure de modules particulière, ainsi qu’un fichier de schéma MOF décrivant une ressource. La seconde méthode a été introduite avec Windows PowerShell version 5. Elle se base sur les classes PowerShell (voir le chapitre Classes). Avec l’arrivée des nouvelles versions du moteur DSC, il est préconisé de développer ses ressources en se basant sur des classes. La DSC Community migre petit à petit l’ensemble de ses ressources sur cette écriture. La raison est que l’écriture MOF est abandonnée au profit des classes.

$env:ModulePath 
  └─<ModuleName> 
    └─DSCResources 
      ├─<ResourceName1> 
        ├─<ResourceName1>.schema.mof 
        ├─<ResourceName1>.psm1 ...

DSC sous Linux

C’est ici que l’on voit que DSC a pris un réel essor. Avoir la possibilité de configurer des machines Linux de manière centralisée depuis une machine Windows est un réel pas en avant. Ainsi, dans cette section sera décrite la mise en œuvre d’une configuration DSC pour un système Linux.

Le système Linux utilisé ici est Debian. Le système générant la configuration et l’appliquant est Windows 10.

:~# sudo apt-get -y install omi  

:~# openssl version  
OpenSSL 1.1.1l  24 Aug 2021 

:~# https://github.com/microsoft/PowerShell-DSC-for- 
Linux/releases/download/v1.2.4-0/dsc-1.2.4-0.ssl_110.x64.deb 

:~# dpkg -i ./dsc-1.2.4-0.ssl_110.x64.deb 

Maintenance et dépannage

Invoke-CimMethod -ClassName MSFT_DSCLocalConfigurationManager ` 
    -Namespace root/Microsoft/Windows/DesiredStateConfiguration ` 
    -MethodName PerformRequiredConfigurationChecks ` 
    -Arguments @{Flags = [System.UInt32]1} 

PS C:\Scripts> Get-DscConfigurationStatus 
 
Status     StartDate                 Type            Mode  Reboot ...