La mise en service d’une infrastructure informatique est généralement soumise à un ensemble de validations avant d’entrer en phase de production. Il en résulte le plus souvent un niveau de qualité très satisfaisant lors de la remise des clés, mais qui va bien souvent se détériorer au fil du temps si on ne prend pas les mesures de contrôle qui s’imposent et qui visent à éviter toute dérive de configuration.

Comment s’assurer que le respect des exigences que l’on a eu lors des phases de conception et de mise en œuvre soit maintenu dans le temps de façon automatisée ? C’est l’objet de ce billet de blog ou je vous présente une PowerShell DSC (Desired State Configuration), fonctionnalité assez méconnue de la plateforme Windows bien qu’apparue avec PowerShell 4.0 lors de la sortie Windows Server 2012 R2.

PowerShell DSC et la syntaxe déclarative.

La particularité de PowerShell DSC tient dans le fait qu’il utilise une syntaxe déclarative à contrario de la syntaxe impérative utilisée en PowerShell classique (cf https://en.wikipedia.org/wiki/Declarative_programming )

La syntaxe déclarative va nous permettre de nous contenter d’effectuer des déclarations d’intentions là ou une syntaxe impérative aurait nécessité, outre la déclaration d’intentions, d’inclure tous des procédures de contrôle inhérents au caractère aléatoire de l’environnement d’exécution.

La syntaxe déclarative va nous permettre de déclarer quelque chose comme : « Je veux que le rôle IIS soit installé » et nous affranchir de toute contrainte de vérification préalable en termes de prérequis, de contrôle d’état et autres tests qu’il conviendrait d’effectuer sur une syntaxe impérative.

L’objectif de la syntaxe déclarative est clairement de s’affranchir de tout contrôle dans les scripts, ces derniers occupant souvent un pourcentage non négligeable du code que nous générons habituellement (j’ai entendu parler de 80 % mais cela dépend bien entendu de la rigueur des contrôles que l’on apporte à son code).

Quoi qu’il en soit, PowerShell DSC utilise une syntaxe déclarative et nous allons faire avec.

A titre de comparaison, et pour obtenir un résultat similaire, voici ce qu’il faut écrire en PowerShell (syntaxe impérative) :

Et voici ce qu’il faut écrire avec PowerShell DSC :

La tournure est certes inhabituelle si vous êtes habitués au PowerShell, mais elle reste très simple et ne contient que des déclarations, aucun contrôle n’apparait dans le code ci-dessus.

Windows Remote Management et Common Information Model

PowerShell DSC repose sur l’utilisation de composants issus de standards DMTF :

• WinRM (Windows Remote Management) qui est l’implémentation du standard WS-Management sur la plateforme Windows.
• CIM (Common Information Model) implémenté sur les plateformes Windows au travers du service WMI

Il est donc nécessaire avant tout de s’assurer du fonctionnement de ces composants. WMI étant nativement intégré à la plateforme Windows, nous ne nous intéresserons qu’au composant WinRM, nécessaire à l’exécution de code PowerShell à distance, et qui pourra facilement être configuré par la commande Set-WSManQuickConfig

PowerShell DSC – Mode Push et Mode Pull

PowerShell DSC supporte deux modes de fonctionnement distincts : Push et Pull.

Le mode Push est le plus simple à mettre en œuvre mais c’est également le moins intéressant. Son principe consiste à pousser des configurations DSC sur des machines cibles.

Le mode Pull est plus intéressant car il permet un fonctionnement sous forme de service continu. Il peut être implémenté sous la forme d’un serveur SMB ou d’un service Web (http / https).

Les termes à retenir sont les suivants :

Dans les deux cas la logique DSC est identique et se résume à 3 étapes :

• La constitution du code déclaratif
• La compilation de ce code
• L’application des configurations déclarées sur les nœuds visés

Il est important d’avoir ce schéma à l’esprit lorsque l’on envisage un projet DSC. Les trois étapes sont présentes sur les deux types de déploiement (push / pull). Seules les méthodes de distribution diffèrent :

Le code déclaratif, qui est comparable à une fonction PowerShell, détient les configurations applicables aux nœuds sous la forme d’appel à des « ressources ». Dans l’exemple ci-dessus, nous faisons appel deux fois à la ressource « WindowsFeature » pour installer les composants « Web-Server » et « Web-Asp-Net45 » auxquels nous avons attribué un alias utilisé uniquement dans notre code déclaratif (IIS et ASP).

Le code déclaratif est compilé dans des fichiers « MOF » accessibles au serveur DSC (mode push) ou / et aux nœuds ciblés (mode pull via SMB, http ou https). Il s’agit une fois de plus d’un standard DMTF applicable tout type de plateforme.

Les fichiers MOF sont traités par les nœuds ciblés, à l’initiative du serveur Push si l’on est en mode) ou à leur propre initiative si l’on est en mode Pull. Notons que la philosophie du mode Pull est très proche de ce qui se fait sur les GPO dans un environnement Active Directory : ce sont les clients qui viennent chercher le paramétrage qui leur est mis à disposition.

Mise en œuvre d’un environnement de test

Pour tester la fonctionnalité PowerShell DSC, nous allons mettre en place un environnement de test (Push et Pull) sur le Cloud AZURE

Notre environnement sera constitué de :

Sur chaque ordinateur, nous allons configurer WinRM de sorte qu’il soit en écoute sur le protocole HTTPS. Il nous fera pour cela :

Disposer d’un certificat de type « Computer » placé dans le magasin de certificats local et reconnu par l’ensemble des machines impliquées:

Invoquer la commande Set-WSManQuickConfig –Force –UseSSL  pour paramétrer WinRM (ou le paramétrer par GPO) :

Une fois ces prérequis en place, nous devrons ajouter la fonctionnalité PowerShell DSC sur l’ordinateur qui sera utilisé comme serveur DSC. Dans notre cas, le serveur HC-SRV-WEB01 sera utilisé à cet effet, autant pour le mode « pull » que le mode « push »:

Configuration en mode Push

Une fois la fonctionnalité installée, nous pouvons effectuer notre première configuration en mode « Push ». Nous écrivons notre script DSC en utilisant la syntaxe déclarative pour « pousser » le rôle « FileServer » sur le serveur HC-SRV-FILES. Le code se présente de la sorte :

Nous retrouvons dans ce script la logique précédemment décrite (déclaration – compilation – nœuds) qui sera exécutée depuis notre serveur DSC.

Lors de l’exécution de ce script, comme nous avons invoqué la commande Start-DSCConfiguration en mode verbeux (-verbose), nous obtenons à la console de nombreux détails lors du traitement de cette opération :

Le traitement ayant été exécuté sans erreur, nous nous rendons à présent sur le serveur ciblé pour nous assurer que le rôle a bien été installé :

Wow ! Le mode Push est opérationnel ! Et en plus c’est vraiment simple à mettre en œuvre, il suffit de configurer WinRM !!

Dès lors que le rôle est installé, la réexécution du script ne traite rien de plus et l’opération est par conséquent beaucoup plus rapide :

Bien entendu, si le rôle est supprimé du serveur ciblé et que l’on rejoue le script, il sera à nouveau installé.

Voilà qui conclut notre test du mode Push, qui peut se résumer à ce diagramme très simple à reproduire:

Configuration en mode Pull

Tout ceci est bien beau, mais si l’on souhaite mettre en place un mécanisme récurrent de conformité (s’assurer qu’une configuration est bien en place et qu’il n’y a pas de dérive), le mode Push va nous contraindre à exécuter régulièrement notre déclaration DSC, ce qui n’est pas très optimal.

C’est là qu’intervient le mode « Pull » qui va nous permettre d’atteindre cet objectif en distribuant nos paramètres DSC de façon récurrente par le biais d’un service Web. La mise en œuvre est un peu plus complexe, mais le résultat en vaut la peine.

La mise en place du mode Pull sur le protocole http / https nécessite la présence d’un site Web et des services associés qui devront être configurés pour accepter les demandes DSC et fournir les configurations correspondantes.

La mise en place de ce site peut être faite manuellement ou ….. par PowerShell DSC bien sûr !

Comme c’est cette seconde option qui nous intéresse, nous allons devoir entrer un peu plus dans les détails :

PowerShell DSC accepte de traiter des déclarations pour autant que ces dernières correspondent à des ordres qu’il puisse comprendre. Dans l’exemple que nous avons traité en mode Push, nous avons utilisé la déclaration « WindowsFeature » pour installer la fonctionnalité « FS-FileServer ».

L’appel à cette configuration a abouti parce que PowerShell 4 inclut nativement la ressource WindowsFeature. Pour nous en assurer il suffit de le vérifier sur l’un de nos nœuds :

La ressource WindowsFeature est bien présente, amenée par le module « PSDesiredStateConfiguration », les déclarations qui y font appel sont donc bien exécutées.

Configuration du serveur Pull

Pour paramétrer le serveur Pull en DSC, nous utiliserons la ressource xDscWebService qui n’est pas présente par défaut. Il va donc falloir installer le module PowerShell xPSDesiredStateConfiguration qui détient cette ressource (il y a bien un « x »)

Rien de bien compliqué, mais pour l’acquisition du module, il va falloir se rendre sur PowerShell Gallery, et ce sera bien plus simple en PowerShell 5.0 que nous allons installer sur notre serveur DSC pour l’occasion.

Une fois PowerShell 5.0 en place, une invite nous permettra de récupérer directement des modules de la PowerShell Gallery grâce à la cmdlet Install-PSModule. Nous allons installer le module qui nous manque:

Une fois le module installé, nous pouvons vérifier la présence de la ressource permettant de configurer notre serveur Pull:

Cette ressource étant à présent disponible, il ne nous reste plus qu’à configurer notre serveur Web en y ajoutant le paramétrage DSC:

• Déclaration des ressources WindowsFeature (installation de PowerShell DSC, Serveur Web et Gestionnaire IIS)
• Déclaration des ressources xDscWebService (configuration du serveur Pull et du serveur de conformité que nous verrons plus tard)

Ce qui nous donne les déclarations suivantes, dans lesquelles nous faisons référence entre autres à l’empreinte du certificat SSL utilisé:

Il reste alors à compiler puis exécuter ces déclarations :

Une fois la déclaration exécutée, le site Web de notre serveur Pull est opérationnel :

Nous pouvons effectuer un test de base sur le service web du serveur Pull en l’invoquant via https depuis un navigateur :

Notre serveur Pull est opérationnel !

Configuration des clients Pull

La configuration des clients Pull se fait au travers du composant « LCM » (Local Configuration Manager » qui est le moteur DSC présent sur les plateformes exécutant PowerShell 4.0 . Par défaut, LCM utilise le mode Push, c’est-à-dire qu’il attend qu’on lui pousse une configuration par WinRM ou que la cmdlet Start-DSCConfiguration soit exécutée localement avec les paramètres adéquats.

Nous pouvons vérifier le statut de LCM avec la cmdlet Get-DSLLocalConfigurationManager. Dans le cas présent, nous sommes sur la valeur par défaut, en mode Push comme cela nous est indiqué par la propriété RefreshMode :

Nous allons donc configurer notre LCM avec :

• Un ID unique à notre client (que nous aurons généré préalablement en PowerShell via la commande [GUID]::NewGuid()
• Un mode de fonctionnement « Pull »
• En gestionnaire de téléchargement Web utilisant le protocole HTTPS

La déclaration DSC correspondant à cette configuration se présente sous cette forme :

Après avoir exécuté cette déclaration, notre client DSC est opérationnel :

Mise à disposition des déclarations en mode Pull

En mode Pull, seul le mode de distribution des déclarations diffère de ce que nous avons vu en mode Push. Les déclarations seront donc stockées dans un fichier « MOF » qui sera mis à disposition des clients Pull sur le mode de transport choisi (HTTPS dans notre cas).

En revanche, le nom du fichier MOF ne sera plus le nom du nœud auquel il s’adresse, mais le nom de son ID tel que nous l’avons configuré précédemment :

Les fichiers MOF devront être placés dans le dossier de configuration de notre serveur Pull, celui que nous avons précédemment configuré :

Un fichier de CheckSum devra accompagner chaque fichier MOF. Ce fichier sera utilisé par les clients pour comparer les configurations publiées à celles qu’ils ont précédemment appliquées. Les configurations ne seront téléchargées que si les versions sont différentes.

Nous pouvons effectuer toutes ces opérations dans un même script déclaratif :

• La déclaration
• La compilation
• La génération d’un fichier de Checksum

Le script ci-dessous mettra à disposition une déclaration installant la fonctionnalité « Telnet-Client » sur les nœuds qui se reconnaitront dans l’ID spécifié

L’exécution de ce script génère le fichier MOF ainsi que le fichier Checksum correspondant

A ce stade, tout est prêt, la configuration sera appliquée dans les 15 minutes qui suivent, et si l’on n’a pas la patience d’attendre, il suffit de lancer la tache planifiée « Consistency » pour forcer les choses :

La fonctionnalité Telnet-Client est bien présente, et revient automatiquement si on la supprime :

Voilà ce qui conclut notre test de la fonctionnalité PowerShell DSC tel qu’elle est implémentée sur PowerShell 4.0. Je garde sous le coude un article complet sur le fonctionnement du mode Pull qui a subi quelques améliorations avec le PowerShell 5.0.

Bons déploiements !