PowerShell DSC, c’est quoi ?

I. DSC comme Desired State Configuration

PowerShell DSC pour « Desired State Configuration » est une fonctionnalité disponible sous Windows Server et aussi sur Linux, ayant pour objectif de gérer la configuration de ses serveurs par l’intermédiaire de PowerShell. Ainsi, on pourrait traduire « DSC » par « Etat de configuration désiré », car ce que vous souhaitez appliquer comme configuration, DSC va le faire à votre place. Sympa, non ?

Avec PowerShell DSC, on rentre clairement dans la philosophie DevOps puisque par l’intermédiaire de ces scripts de configuration DSC on pourra faire évoluer les configurations au fil du temps. La gestion des configurations concerne aussi bien la configuration du système que celle d’une application.

L’objectif de PowerShell DSC c’est de vous simplifier le scripting, en s’appuyant sur des fichiers de configuration avec une syntaxe simplifiée, bien qu’il soit nécessaire de bien la comprendre pour pouvoir réaliser ses propres fichiers de configuration, mais vous verrez que l’aide intégrée est précieuse. Là où PowerShell DSC vous simplifie la vie, c’est que vous lui dites « Tu t’assures que le rôle DHCP est installé sur ces 3 serveurs » et lui installera le rôle si besoin, alors que si l’on réalise ceci en script on partirait dans des conditions, du genre « Si le rôle DHCP n’est pas installé, tu l’installes, sinon tu écris dans la console que le rôle est déjà installé », voyez déjà le if-else arriver...

Avec PowerShell DSC on peut envisager un code sans contrôle avec uniquement une syntaxe déclarative.

Réaliser manuellement une configuration sur un seul serveur, ce n’est pas gênant, mais devoir réaliser la même configuration sur plusieurs serveurs, d’une part c’est barbant, et d’autre part ce n’est pas très efficace. C’est là que PowerShell DSC intervient. En effet, à partir d’un fichier de configuration, on va générer un fichier compilé propre à chaque serveur ciblé pour ensuite appliquer la configuration sur les serveurs ciblés, appelés nœuds. Il est à noter que depuis la version 5 de PowerShell, l’utilisation des fichiers compilés n’est plus obligatoire si l’on effectue les configurations à partir de classes.

Il ne faut plus agir comme un robot et réaliser des tâches identiques en boucle, aujourd’hui il y a des outils de gestion de configuration très puissants, PowerShell DSC est de ceux-là, comme je pourrais citer Chef, Puppet ou Ansible qui sont les 3 plus utilisés.

II. Les prérequis à PowerShell DSC

Arrivé avec PowerShell 4.0, vous ne retrouverez pas PowerShell DSC sur tous vos serveurs, quoi que vos infrastructures doivent tendre actuellement à migrer vers des OS plus récents, mais ça c’est un autre sujet...

Les serveurs que vous souhaitez gérer avec PowerShell doivent être équipé du « Windows Management Framework » appelé « WMF ». Au passage, ceci permettra de mettre à jour PowerShell sur vos serveurs, ce qui est plutôt une bonne nouvelle. Voici ce que contient en partie WMF :

- Windows PowerShell,
- Windows PowerShell Desired State Configuration (DSC),
- Windows Remote Management (WinRM),
- Windows Management Instrumentation (WMI)

Vous pouvez installer WMF 4.0 sur Windows Server 2008 R2 SP1, Windows Server 2012 et éventuellement Windows 7 SP1.

Cependant, WMF 5.0, dernière version en date et recommandée. Vous pouvez l’installer sur Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, ainsi que sur les systèmes d’exploitation client : Windows 7, Windows 8 et 8.1, ainsi que Windows 10.

Il est à noter que le WMF est disponible en téléchargement sous la forme d’une mise à jour Windows, qui nécessite cependant un redémarrage.

En plus de nécessité le WMF, vous devez autoriser la gestion à distance sur vos nœuds, ceci concerne WinRM. Par exemple, sous Windows Server 2008 R2, il faudra le configurer (winrm quickconfig – ou – Set-WSManQuickConfig) alors que sous Windows Server 2012 R2, il sera déjà actif (ou, au pire, un clic dans le gestionnaire de serveurs permet de l’activer). Enfin, pour information, PowerShell DSC s’appuie sur le CIM (Common Information Model) qui est implémenté au travers de WMI.

Pour conclure sur les prérequis, je dirais qu’une bonne connaissance de Windows Server, de PowerShell et de PowerShell ISE est forcément un plus pour débuter avec PowerShell DSC.

III. Mode Push et mode Pull

PowerShell DSC propose deux modes de fonctionnement différents : push, qui est le mode par défaut et qui consiste à pousser les configurations sur les nœuds distants, et le mode pull qui consiste à demander aux nœuds de venir tirer les configurations sur un serveur pull prévu à cet effet.

Lorsque vous conserver l’utilisation du mode push, vous n’avez aucune mise en place particulière à réaliser, c’est vous qui pilotez l’envoi des configurations sur vos nœuds. Ceci n’est pas automatique, contrairement au mode pull où les nœuds vont venir à intervalle régulier (toutes les 15 minutes par défaut) récupérer leurs configs sur le serveur.

En résumé, vous devez privilégier le mode push pour des configurations one shot, alors le mode pull permettra de gérer votre infrastructure sur la durée.

Nous verrons dans un tutoriel dédié la mise en place d’un serveur en mode Pull, qui sera à terme surement votre mode de fonctionnement préféré mais qui nécessite plus de travail de mise en œuvre.

IV. Gérer Windows, mais pas seulement...

Je tiens à préciser que PowerShell DSC n’est pas seulement capable de configurer des nœuds sous Windows. En effet, il existe des modules pour gérer son Cloud Azure, mais aussi la possibilité de gérer la configuration de serveurs Linux, qui vous demandera de faire appel à vos connaissances en Python à cette occasion.

V. Principe de fonctionnement

Bien qu’il y ait deux modes de fonctionnement, ces modes ont bien sûr des points communs. Tout d’abord, une configuration PowerShell DSC commence toujours par l’écriture d’un fichier de configuration (au format ps1). Dans ce fichier de configuration, on déclare la configuration et on cible un ou plusieurs nœuds.

Ensuite, on va compiler cette configuration pour en ressortir des fichiers MOF, nous obtiendrons un fichier MOF par serveur ciblé par la configuration. Le fichier MOF prend pour nom le nom du nœud ciblé en mode push, en mode pull c’est un peu différent il prend pour nom un GUID associé au serveur, mais nous verrons cela plus tard.

La dernière étape consiste à appliquer la configuration sur les nœuds distants, donc soit on pousse la conf en mode push, soit le nœud cible vient la chercher en mode pull.

Voici un schéma réalisé par mes soins quant au principe de fonctionnement de PowerShell DSC :

Sur le nœud distant, le composant qui est en charge d’appliquer la configuration est le « LCM » pour « Local Configuration Manager ». Il s’agit d’un moteur DSC en local sur chaque nœud cible, c’est lui que l’on configure par exemple pour passer du mode push au mode pull, ou inversement.

D’ailleurs, le LCM peut-être configuré via PowerShell DSC puisqu’il existe une ressource dédié à sa configuration (minimum PowerShell 5.0).

Pour conclure...

PowerShell DSC est un merveilleux outil pour simplifier la configuration de son infrastructure, éviter les dérives de configuration, déployer des configurations en continu mais aussi éviter les erreurs humaines. La communauté derrière cet outil est importante, on trouve des modules dédiés à de nombreux produits : Azure, Exchange, DHCP, Hyper-V, DNS, Active Directory, MDT, SNMP...

La réflexion que l’on peut avoir aussi, c’est d’affirmer que c’est moins coûteux de réinstaller un serveur que de le dépanner pendant des heures, puisqu’avec un outil comme PowerShell DSC, le déploiement pourra être totalement utilisé. Par exemple, un serveur IIS au sein d’une ferme de serveurs pourrait être redéployé.

Cette introduction touche à sa fin, elle constituera un point d’entrée principal pour comprendre ce qu’est PowerShell DSC dans les grandes lignes, avant de rentrer dans le vif du sujet au travers des autres chapitres de ce cours PowerShell DSC.

Ressource : PowerShell DSC sous Linux