DSC est la solution DevOps de Microsoft disponible à partir de la version 4 de Powershell pour Windows et de la 6 core pour Linux.
La mode, DevOps oblige, est aux systèmes de gestion de configuration. Puppet, Chef et autres Ansible permettent de configurer un ensemble de machines de manière idempotente et en un temps record. Rappelons que l’idempotence est, en l’occurrence, 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 vérifier si toutes les machines ont la même configuration et, si ce n’est pas le cas, de la réappliquer sur les machines concernées.
Microsoft a créé à cette fin DSC (Desired State Configuration). DSC permet d’éviter les “ dérives ” de configuration et, si le cas se présente, il est normalement capable de remédier immédiatement à la situation.
L’autre avantage sur la gestion de configuration est le temps gagné en terme de résolution d’incidents. À quoi bon se décarcasser une journée entière sur un serveur en panne alors qu’il peut être redéployé, et à nouveau opérationnel, en moins de 30 minutes ? Cela représente un réel atout dans une stratégie de Cloud.
Microsoft l’a d’ailleurs rendu utilisable depuis sa plate-forme de Cloud Azure. Jusqu’alors, il était possible d’utiliser les GPO (stratégies de groupes) pour faire descendre des configurations sur un domaine ou une forêt ou une arborescence AD (Active Directory, le Ldap de Microsoft), mais pas de manière aussi souple, et cela ne pouvait fonctionner sur des machines hors domaine Active Directory. Le problème ne se pose plus avec DSC qui prend en charge tous les cas de figure, celui-ci compris.
Powershell DSC et le DevOps
DSC est une fonctionnalité disponible sous Windows Server et aussi sous Linux permettant de gérer la configuration de ses serveurs par l’intermédiaire de PowerShell. DSC se traduit presque littéralement par État de configuration souhaité car il applique sur vos machines la configuration que vous souhaitez à votre place. La prise en charge des systèmes Linux et l’ouverture sur l’Open Source de PowerShell avec la version Core (6.2 pour la dernière release, 7 en beta) qui va de pair avec la version core de .Net devrait fortement profiter à l’évolution de DSC. Il est possible depuis déjà quelque temps de configurer des machines Linux depuis une machine Windows. Il faut maintenant rendre cela faisable d’un serveur Linux. PowerShell DSC est clairement dans la philosophie DevOps. Les scripts de configuration DSC sont capables de faire évoluer les configurations au fil du temps. La gestion des configurations touche aussi bien à la configuration du système qu’à celle d’une application. L’objectif de PowerShell DSC est de faciliter le scripting avec des fichiers de configuration et une syntaxe relativement simple. Ce qui est particulier avec PowerShell DSC, c’est que vous lui dites par exemple « Assures-toi que le rôle DNS est installé sur ces dix serveurs » et il vérifiera et l’installera si besoin, alors qu’autrement il faudrait écrire du code plus lourd – et plus long – à coups de if-else. À partir d’un fichier de configuration, PowerShell DSC va générer un fichier compilé propre à chaque serveur ciblé pour ensuite appliquer la dite configuration à l’ensemble des serveurs ciblés à configurer, les fameux nœuds ou nodes. À partir de la version 5 de PowerShell, il est possible d’utiliser des classes, écrites en Powershell, à la place des fichiers compilés.
Voilà à quoi ressemble une configuration DSC : un bloc Configuration, un ou plusieurs blocs nodes et idem pour les ressources.
Mode Push et mode Pull
PowerShell DSC propose deux modes de fonctionnement différents : push, le mode par défaut, qui consiste à pousser les configurations sur les nœuds distants, et le mode pull qui demande aux nœuds de venir récupérer les configurations sur un serveur prévu à cet effet. En mode push, aucune mise en place particulière n’est nécessaire puisque c’est vous qui pilotez l’envoi des configurations sur les nodes. En mode pull, les nœuds viennent récupérer leur configuration sur le serveur à intervalle régulier – toutes les 15 minutes, par défaut. Le mode push est à privilégier pour des configurations one shot, et le mode pull est lui plus intéressant pour gérer votre infrastructure sur la durée. PowerShell DSC n’est pas seulement capable de configurer des nœuds sous Windows mais aussi sur son Cloud Azure, ou encore sous Linux, avec un peu de Python, néanmoins.
Principe de fonctionnement
Une configuration PowerShell DSC commence toujours par l’écriture d’un fichier de configuration au format ps1. Ce fichier contient la déclaration de la configuration et la ou les cibles (nodes). La compilation de cette configuration produit des fichiers MOF, un par serveur (node) cible. Ce fichier MOF prendra, en mode push, le nom du nœud ciblé. En mode pull, il prend pour nom un GUID associé au serveur. La dernière étape consiste à appliquer la configuration sur les nœuds distants. Soit en la poussant, en mode push, soit en laissant le nœud cible venir la chercher en mode pull. Sur le nœud distant, le composant en charge d’appliquer la configuration est le LCM, pour Local Configuration Manager. Il s’agit en fait d’un moteur DSC en local sur chaque nœud cible. C’est lui qui doit être paramétré pour passer notamment du mode push au mode pull, ou même inversement. Le LCM peut être configuré via PowerShell DSC. Il existe même une ressource dédiée à sa configuration en PowerShell 5 ou version supérieure. PowerShell DSC permet donc, comme Ansible, Puppet et autres Chef, de simplifier la configuration de son infrastructure, d’éviter les dérives de configuration, de déployer des configurations en continu et d’éviter au maximum les erreurs humaines. DSC est officiellement pris en charge pour les versions suivantes des distributions Linux : CentOS 5 à 8, Debian 6 à 11, Oracle Linux 5 à 8, Red Hat Enterprise Linux Server 5 à 8, SUSE Linux Enterprise Server 10 à 15 et Ubuntu Server 12.04 LTS à 20.04 LTS. L’installation de DSC pour Linux nécessite au préalable celle d’OMI (Open Management Infrastructure). Le serveur CIM d’OMI peut être téléchargé sur le site de l’Open Group à l’adresse https://github.com/Microsoft/omi. Vous devrez installer le package approprié à votre distribution Linux (.rpm ou .deb) et à la version d’OpenSSL (ssl_098 ou ssl_100). DSC pour Linux est disponible en téléchargement à cette adresse : https://github.com/Microsoft/ PowerShell-DSC-for-Linux/releases/tag/ v1.1.1-294
De nombreuses ressources prédéfinies pour Windows et Linux sont mises à disposition par Microsoft.
Création d’un document MOF de configuration pour Linux
Le mot clef Configuration permet de créer une configuration pour les ordinateurs Linux, tout comme pour les ordinateurs Windows. Si vous souhaitez créer un document de configuration pour une machine Linux en PowerShell, commencez par importer le module nx. Ce module contient le schéma des ressources DSC intégrées pour Linux. Il doit être installé sur votre ordinateur local et importé dans la configuration. Installez pour cela le module nx, copiez le répertoire du module nx vers $env:USERPROFILEDocumentsWindowsPowerShell Modules ou $PSHOMEModules. Le module nx est inclus dans le package d’installation (MSI) de DSC pour Linux. Pour importer le module nx dans votre configuration, le plus simple est d’utiliser la commande Import-DSCResource :
Pour tout savoir sur Powershell DSC, rendez-vous sur le site de Microsoft à l’adresse https://docs.microsoft.com/fr-fr/powershell/scripting/dsc/overview/overview?view=powershell-6
Transmission de la configuration en mode Push à l’ordinateur Linux
Vous pouvez effectuer une transmission Push des documents de configuration (fichiers MOF) vers l’ordinateur Linux grâce à l’applet de commande Start-DscConfiguration. Pour utiliser cette applet de commande avec les applets de commande Get-DscConfiguration ou Test-DscConfiguration à distance sur un ordinateur Linux, vous devez utiliser une session CIMSession. C’est l’applet de commande New-CimSession permet de créer une session CIMSession sur l’ordinateur Linux. Voici un exemple de code, tiré du site de Microsoft, permettant de créer une session CIMSession pour DSC sous Linux :
En mode Push, les informations d’identification de l’utilisateur doivent correspondre à l’utilisateur racine sur l’ordinateur Linux. Seules les connexions SSL/TLS sont prises en charge pour DSC pour Linux. L’applet de commande New-CimSession doit être utilisée avec le paramètre – UseSSL défini à la valeur $true. Le certificat SSL utilisé par OMI (pour DSC) est spécifié dans le fichier /opt/omi/ etc/omiserver.conf avec les propriétés pemfile et keyfile. Si ce certificat n’est pas approuvé par l’ordinateur Windows sur lequel l’applet de commande NewCimSession est exécutée, vous pouvez éventuellement choisir d’ignorer la validation des certificats en spécifiant les options CIMSession suivantes :
Pour transmettre en mode Push la configuration DSC vers le nœud Linux, exécutez la commande suivante :
Ressources DSC
Les ressources DSC fournissent les éléments de base d’une configuration. Une ressource expose les propriétés qui peuvent être configurées (le schéma) et contient les fonctions de scripts PowerShell dont le gestionnaire de configuration local se sert pour l’exécution. Une ressource peut modéliser un élément générique comme un fichier ou spécifique comme un paramètre de serveur IIS. Les groupes de ce type de ressources sont combinés dans un module DSC qui organise tous les fichiers nécessaires dans une structure portable incluant les métadonnées qui permettent d’identifier la façon dont sont utilisées les ressources. Chaque ressource comporte un schéma qui détermine la syntaxe nécessaire pour utiliser la ressource dans une configuration. Le schéma d’une ressource peut être défini de la manière suivante :
Un fichier Schema.Mof. La plupart des ressources définissent leur schéma dans un fichier Schema.MOF (Managed Object Format).
Un fichier <Nom de la ressource>. schema.psm1. Les ressources composites définissent leur schéma dans un fichier '.schema.psm1' à l’aide d’un bloc de paramètres.
Un fichier <Nom de la ressource>.psm1. Les ressources DSC basées sur une classe définissent leur schéma dans la définition de la classe. Les éléments descriptifs de la ressource sont déclarés en tant que propriétés d’instance de la classe. Vous pouvez récupérer la syntaxe d’une ressource DSC grâce à l’applet de commande Get-DSCResource (avec le paramètre –Syntax). Vous pouvez aussi utiliser la cmdlet GetCommand avec le même paramètre (-Syntax). Cela aura pour effet d’afficher le modèle utilisé pour le bloc de ressources correspondant à la ressource spécifiée :
Le résultat obtenu devrait être similaire à ce qui suit. Comme dans la syntaxe de l’applet de commande, les clefs affichées entre crochets sont facultatives. Les types spécifient le type de données attendu par chaque clef :
Le bloc de ressources Service d’une configuration peut par exemple garantir que le service Spooler est en cours d’exécution. Avant d’utiliser une ressource dans une configuration, il faut l’importer à l’aide de la commande Import-DSCResource.
Les configurations peuvent contenir plusieurs instances du même type de ressource, mais chaque instance doit avoir un nom unique. Dans l’exemple suivant, un second bloc de ressources Service est ajouté pour configurer le service DHCP.
Configuration du LCM
Le Gestionnaire de configuration local (LCM pour Local Configurztion Manager) est le moteur de la fonctionnalité DSC. Le LCM s’exécute sur chaque nœud cible afin d’analyser et d’appliquer les configurations transmises au nœud. Il a également en charge plusieurs autres opérations liées à DSC dont notamment la détermination du mode d’actualisation (push ou pull), la spécification de la fréquence à laquelle un nœud extrait et applique les configurations, l’association du nœud à un service d’extraction et la spécification des configurations partielles. Un type spécial de configuration vous permet de configurer le LCM pour définir chacun de ces comportements.
Création et application d’une configuration du LCM
Pour configurer le LCM, vous devez créer et exécuter un type spécial de configuration appliquant ses paramètres. La spécification d’une configuration du LCM se fait via l’attribut DscLocalConfigurationManager. L’exemple ci-dessous montre une configuration simple définissant le LCM en mode par envoi.
Le processus d’application des paramètres au Gestionnaire de configuration local est similaire à l’application d’une configuration DSC. Vous devez créer une configuration du LCM, la compiler dans un fichier MOF, puis l’appliquer au nœud. À la différence des configurations DSC, vous n’appliquez pas de configuration du gestionnaire de configuration local en appelant l’applet de commande StartDscConfiguration. Au lieu de cela, vous appelez DscLocalConfigurationManager en spécifiant le chemin du fichier MOF de configuration du LCM comme paramètre. Après avoir appliqué la configuration du LCM, vous pouvez afficher ses propriétés en appelant l’applet de commande Get-DscLocalConfigurationManager. Une configuration du LCM peut contenir des blocs correspondants seulement à un ensemble limité de ressources.
Vous pouvez spécifier des dépendances entre nodes grâce à des ressources spéciales du type WaitForXXX.
Paramètres de base du LCM
À la différence de la spécification de points de terminaison (de chemins) et de configurations partielles du service d’extraction, toutes les propriétés du Gestionnaire de configuration local sont configurées dans un bloc de paramètres (Settings). Le Gestionnaire de configuration local démarre le cycle ConfigurationModeFrequencyMins d’après les critères suivants :
• une nouvelle métaconfiguration est appliquée à l’aide de Set-DscLocalConfigurationManager
• l’ordinateur est redémarré Pour toute condition où le processus du minuteur plante, le problème est détecté dans les 30 secondes et le cycle est redémarré. Une opération simultanée peut retarder le démarrage du cycle. Si la durée de cette opération dépasse la fréquence du cycle configurée, le minuteur suivant ne démarrera pas.
Même si Microsoft a encore du travail à accomplir, DSC se pose clairement comme un concurrent d’Ansible de Red Hat.
Les prérequis à PowerShell DSC
Même s’il est disponible depuis la version 4, DSC est nettement plus abouti en version 5 ou supérieure. Si vous devez mettre à jour votre version de PowerShell, il vous faudra télécharger le WMF (Windows Management Framework). Le WMF contient des mises à jour pour les éléments suivants :
• Windows PowerShell,
• Windows PowerShell Desired State Configuration (DSC),
• Windows Remote Management (WinRM),
• Windows Management Instrumentation (WMI)
Vous pouvez installer WMF 5.1 sous Windows Server 2008 R2 SP1 ou version supérieure et sous Windows 7 SP1 à Windows 10 pour la partie client. En plus du WMF, vous devrez peut-être mettre à jour votre version du .Net. Côté réseau, vous devrez aussi autoriser la gestion à distance sur vos nœuds via WinRM (Windows Remote Management), le protocole de communication à distance de Powershell (le SSH de Microsoft). Les programmes et commandes de configuration permettant de le faire sont, au choix, le programme externe winrm avec l’option quickconfig (winrm quickconfig dans un cmd ou une console powershell) et les commandelettes Enable-PSRemoting ou Set-WSManQuickConfig. PowerShell DSC s’appuie sur le CIM (Common Information Model) implémenté au travers de WMI (Windows Management).
Service d’extraction
La configuration du LCM permet de définir les types de services d’extraction suivants :
• Serveur de configuration : un référentiel pour les configurations DSC. Les serveurs de configuration sont définis à l’aide des blocs ConfigurationRepositoryWeb pour les serveurs web et ConfigurationRepositoryShare (pour les serveurs SMB).
• Serveur de ressources : c’est le référentiel pour les ressources DSC, packagées comme modules PowerShell. Les serveurs de ressources sont définis à l’aide des blocs ResourceRepositoryWeb pour les serveurs web et ResourceRepositoryShare pour les serveurs SMB.
• Serveur de rapports : c’est le service vers lequel DSC envoie les données de rapports. Les serveurs de rapports sont eux définis à l’aide des blocs ReportServerWeb. Un serveur de rapports doit être un service web.
Utilisation de configurations locales
DSC pour Linux fournit des scripts, écrits en Python et non en Powershell, et ce afin d’être interprétés plus aisément, qui peuvent être utilisés avec une configuration de l’ordinateur Linux local. Ces scripts se trouvent dans le répertoire /opt/microsoft/dsc/Scripts et contiennent les éléments suivants :
• GetDscConfiguration.py qui retourne la configuration actuellement appliquée à l’ordinateur, tout comme l’applet de commande PowerShell Get-DscConfiguration.
• GetDscLocalConfigurationManager.py retourne la métaconfiguration actuellement appliquée à l’ordinateur. Sa cousine Powershell est la commande Get-DscLocalConfigurationManager.
• InstallModule.py installe un module de ressources DSC personnalisé. Doit spécifier le chemin d’un fichier .zip contenant la bibliothèque d’objets partagés et les fichiers MOF de schéma du module.
• RemoveModule.py permet de supprimer un module de ressources DSC personnalisé.
• StartDscLocalConfigurationManager.py applique un fichier MOF de configuration sur l’ordinateur. Elle est similaire à sa presque homonyme applet de commande Powershell Start-DscLocalConfiguration.
• SetDscLocalConfigurationManager.py applique un fichier MOF de métaconfiguration sur l’ordinateur.