Automatisation avancée sous Windows avec PowerShell DSC et Ansible

Informatec Digital » Ressources » Automatisation avancée sous Windows avec PowerShell DSC et Ansible

Si vous travaillez avec une infrastructure Windows et que des termes comme PowerShell, DSC, Ansible et automatisation vous sont familiers , vous savez probablement déjà que leur combinaison efficace peut transformer radicalement la gestion de vos serveurs. Passer de clics manuels dans l'assistant Windows à une configuration entièrement déclarative et reproductible fait toute la différence entre une gestion constante des incidents et un environnement parfaitement maîtrisé.

Dans cet article, nous allons explorer plus en détail comment PowerShell Desired State Configuration (DSC) et Ansible sont complémentaires. Pour gérer Windows (et Linux) à grande échelle, quel rôle jouent des technologies comme WinRM, Azure Automation, Terraform ou cloud-init, et comment tirer parti des ressources DSC existantes d'Ansible grâce au module win_dscVous découvrirez des exemples pratiques, des cas d'utilisation concrets et des critères permettant de décider quand utiliser DSC natif, les modules Ansible ou d'autres approches d'automatisation.

Présentation : Automatisation Windows avec PowerShell, DSC et Ansible

PowerShell et Ansible partagent le même objectif : automatiser la configuration et l’administration de vos systèmes de manière reproductible. La différence réside dans leur approche. DSC est la plateforme de gestion de configuration intégrée à PowerShell, principalement axée sur Windows (bien qu’elle puisse fonctionner avec Linux via OMI), tandis qu’Ansible est un moteur d’automatisation polyvalent et multiplateforme conçu pour orchestrer des infrastructures hybrides et hétérogènes à partir d’un point unique.

Avec Red Hat Ansible Automation Platform, vous pouvez automatiser les serveurs Windows sans installer d'agents supplémentaires, en utilisant WinRM ou OpenSSH comme canaux de connexion et en exploitant les ressources DSC, les modules Ansible et les scripts PowerShell. Le tout est organisé via des playbooks YAML , où vous définissez l'état que chaque hôte doit atteindre, sous Windows comme sous Linux.

En revanche, PowerShell Desired State Configuration offre des centaines de ressources spécialisées pour configurer presque tous les composants Windows : services, fonctionnalités système, IIS, SQL Server, Active Directory, registre, fichiers, etc. Ces ressources encapsulent la logique de vérification et d’application de l’état souhaité ; il vous suffit donc de déclarer « comment vous voulez que la machine soit ».

L'essentiel est que, depuis Ansible, vous pouvez utiliser directement ces ressources DSC via le module. ansible.windows.win_dscEn combinant la puissance d'orchestration d'Ansible avec la profondeur de configuration spécifique à Windows offerte par DSC, vous obtenez ainsi : Le meilleur des deux mondes sans dupliquer les efforts.

WinRM et accès distant à Windows pour Ansible

Pour qu'Ansible puisse gérer des serveurs Windows, il est essentiel de comprendre le fonctionnement de WinRM (Windows Remote Management) . WinRM est la technologie intégrée de Microsoft pour l'administration à distance basée sur HTTP/HTTPS ; c'est le canal standard utilisé par Ansible pour exécuter des tâches sur les machines Windows.

La première étape consiste à configurer correctement WinRM sur les hôtes cibles et le nœud de contrôle où s'exécute Ansible. Cela implique d'ajuster l'authentification, le chiffrement, les permissions et souvent de gérer des fonctionnalités telles que la connexion non interactive, où les commandes sont exécutées sans session utilisateur active. Cet environnement de session non interactive complexifie des tâches comme les mises à jour Windows ou les scénarios d'authentification bidirectionnelle , nécessitant l'accès à une seconde ressource distante (par exemple, un partage sur un autre serveur).

L'avantage d'utiliser la plateforme d'automatisation Red Hat Ansible réside dans sa capacité à centraliser et sécuriser le codage des identifiants et des mécanismes d'authentification , simplifiant ainsi la gestion de ces cas complexes. De plus, la plateforme peut également utiliser OpenSSH pour accéder à Windows Server , une pratique de plus en plus courante avec les versions récentes de Windows.

En pratique, la combinaison de WinRM, de la gestion des identifiants d'Ansible et des fonctionnalités de DSC vous permet de créer des flux d'automatisation robustes qui s'exécutent sans surveillance, même dans des environnements soumis à des restrictions de sécurité élevées.

PowerShell DSC : Plateforme de configuration déclarative

PowerShell Desired State Configuration (DSC) est une plateforme de gestion de configuration déclarative intégrée à Windows. Avec DSC, vous définissez, par le code, la configuration d'une machine : les rôles et fonctionnalités à installer, les services à activer, les paramètres de registre à définir, les fichiers et répertoires à créer, etc.

Les configurations DSC décrivent l'état souhaité pour un ensemble de nœuds. Chaque machine gérée exécute un gestionnaire de configuration local (LCM) , qui lit ces configurations, vérifie l'état actuel et applique les modifications nécessaires. De plus, vous pouvez configurer un serveur de récupération qui centralise les configurations et à partir duquel les nœuds se mettent à jour et signalent leur conformité.

DSC ne se limite pas à Windows : grâce au serveur OMI (Open Management Infrastructure ), il est également compatible avec les machines Linux . Cependant, c’est dans les environnements Windows qu’il excelle véritablement, la communauté ayant développé une vaste collection de ressources spécialisées pour des tâches aussi variées que la configuration d’IIS, de SQL Server ou d’Active Directory.

L'un des principaux avantages de DSC est qu'il se concentre sur le résultat, et non sur les étapes . Vous déclarez l'état (par exemple : « cette fonctionnalité doit être présente, ce service doit être démarré, cette valeur de registre doit être configurée ») et le moteur se charge d'y parvenir, en vérifiant et en corrigeant tout écart éventuel au fil du temps.

Comment Ansible s'intègre à DSC : module win_dsc et orchestration

En théorie, DSC pourrait être utilisé seul, mais en pratique, il est bien plus utile combiné à Ansible comme couche d'orchestration . Ansible gère l'inventaire, l'exécution ordonnée des tâches, la coordination inter-systèmes et l'intégration aux pipelines CI/CD, tandis que DSC fournit les ressources spécifiques permettant de manipuler le fonctionnement interne de Windows.

Le module ansible.windows.win_dsc Il fait le lien entre les deux mondes. Ce module invoque un classe de ressources DSC sur l'hôte Windows cible. Dans le playbook, il vous suffit de définir :

• nom_ressource: le nom de la ressource DSC que vous souhaitez utiliser (par exemple, File, WindowsFeature, Service, Registry, xWebsite, Etc).
• Les paramètres restants, qui correspondent directement aux propriétés de la ressource DSC (par exemple, DestinationPath, Ensure, Name, State, Etc).

Lors de l'exécution de la tâche, Ansible traduit ces paramètres en une configuration DSC temporaire, l'applique à l'hôte et collecte le résultat (y compris les éventuelles modifications). Cela permet de réutiliser l'intégralité du catalogue de ressources DSC sans avoir à écrire de modules Ansible spécifiques pour chaque cas.

En interne, le flux d'exécution suit un schéma cohérent : Ansible envoie la tâche via WinRM, le système Windows génère une configuration DSC à partir des paramètres, puis le moteur DSC appelle une première fonction. Test-TargetResource pour vérifier l'état actuel, et s'il détecte des différences, il exécute Set-TargetResource Pour appliquer les modifications, Ansible reçoit un rapport indiquant si des modifications ont été apportées et les messages pertinents pour le débogage.

Ce couplage est particulièrement puissant lorsqu'on le combine Modules natifs Ansible pour Windows (Tel que win_file, win_service, win_regedit, win_psmoduleetc.) avec les ressources DSC pour les domaines où DSC offre des options plus précises ou une couverture fonctionnelle plus étendue.

Types de propriétés DSC et comment les mapper dans Ansible

Chaque ressource DSC définit un ensemble de propriétés avec un type bien spécifié (chaînes de caractères, booléens, tableaux, types PowerShell complexes, etc.). Lorsque vous travaillez avec Ansible, vous devez traduire ces propriétés en Syntaxe YAML Maintenir le type correct. Le module win_dsc Il effectue de nombreuses conversions automatiques, mais il est utile de connaître certains cas clés.

Pour les types simples comme o , le mappage est simple : chaînes de caractères entre guillemets et booléens en minuscules au format YAML (true, false), en évitant d'écrire $true o $false comme vous le feriez dans PowerShell. Pour les propriétés de type , la pratique courante consiste à utiliser un Format ISO 8601 (par exemple, "2019-02-22T13:57:31Z") et assurez-vous que la valeur est sérialisée sous forme de chaîne de caractères, en l'entourant de guillemets.

propriétés de type Il s'agit d'un cas particulier. Puisque ce type ne peut pas être directement sérialisé en JSON, Ansible utilise une convention : vous définissez deux paramètres séparés par un suffixe. _username y _password (par exemple, Credential_username y Credential_passwordLe module génère l'objet. PSCredential sur l'hôte distant en fonction de ces deux valeurs.

Pour les types Ces dictionnaires sont basés sur une classe de ressource personnalisée ; en YAML, ils sont représentés sous forme de paires clé-valeur. Veuillez consulter la documentation de la ressource (généralement dans le fichier correspondant). <nombre_recurso>.schema.mof) pour savoir quelles clés sont autorisées et de quel type elles sont. En pratique, elles sont définies comme dictionnaires imbriqués au sein du module win_dsc.

Enfin, les propriétés de type et les tableaux (], ]etc.) sont représentés sous forme de dictionnaires ou de listes YAML. Pour les tableaux, il est recommandé d'utiliser un liste YAML authentique et non une chaîne de caractères avec des valeurs séparées par des virgules, car cela évite l'analyse manuelle et réduit la probabilité d'erreurs subtiles.

Exemples pratiques d'utilisation de DSC depuis Ansible

Une fois que vous maîtrisez la structure de base du module win_dscVous pouvez combiner des ressources pour construire manuels de configuration très completsVoici quelques scénarios courants qui fonctionnent bien avec DSC :

• Gestion des fichiers et des répertoires avec la ressource File: création de structures de dossiers, déploiement de fichiers de configuration avec un contenu spécifique, vérification de l'existence ou de la suppression de certains éléments.
• Installation des rôles et fonctionnalités Windows avec WindowsFeatureIIS, .NET Framework, client Telnet, outils d'administration, etc.
• Contrôle du service avec la ressource Service: statut (démarré/arrêté), type de démarrage (automatique, manuel), compte de service, etc.
• paramètres du registre avec Registry: valeurs de sécurité, temps d'attente, paramètres de protocole, renforcement du système.
• Paramètres IIS avancés avec des modules tels que xWebAdministration et ressources xWebsite, xWebAppPool, etc.

Dans tous ces cas, Ansible décrit simplement les paramètres de la ressource DSC, tandis que Le moteur DSC est responsable de la vérification et de l'application l'état. De plus, à partir d'Ansible 2.8, le module win_dsc Il valide automatiquement les paramètres par rapport à la définition de la ressource : si vous utilisez un nom de propriété incorrect, si vous laissez un champ obligatoire vide ou si vous transmettez une valeur hors plage, la tâche échouera et un message d’erreur clair s’affichera.

Si vous exécutez Ansible avec un un niveau élevé de verbosité (par exemple, -vvv)Le résultat comprendra des informations détaillées dans invocation.module_args concernant les options utilisées et celles qui étaient disponibles, ce qui est très utile à la fois pour le débogage et pour découvrir quels champs vous pouvez configurer dans chaque ressource.

Notez également que vous pouvez utiliser le paramètre PsDscRunAsCredential Cela permet à la ressource DSC de s'exécuter sous un compte utilisateur différent de celui du système. Ceci est très utile pour accéder à la ruche d'enregistrement. HKEY_CURRENT_USER de l'utilisateur auquel Ansible s'est connecté, ou pour les scénarios où vous avez besoin d'un contexte de sécurité spécifique.

Galerie de ressources DSC personnalisées et PowerShell

Les ressources DSC intégrées à Windows couvrent de nombreux besoins, mais leur véritable potentiel réside dans l'utilisation des ressources publiées dans la galerie PowerShell ou des packages tiers. Il existe des modules pour tout : Active Directory, SQL Server, IIS avancé, stratégies de sécurité, et bien plus encore.

Vous pouvez découvrir les ressources disponibles avec l'applet de commande. Find-DscResource ou en parcourant directement la galerie PowerShell. Une fois que vous avez identifié le module qui vous intéresse (par exemple, xWebAdministration o SqlServerDsc), vous disposez de plusieurs façons de l'installer sur vos hôtes :

• Installation manuelle avec Install-Module depuis PowerShell sur le serveur cible.
• Utilisation du module Ansible win_psmodule pour automatiser l'installation depuis la galerie PowerShell.
• Téléchargez à l'avance et copiez à la main pour les serveurs qui n'ont pas d'accès à Internet, en enregistrant le module dans un répertoire inclus dans PSModulePath (par exemple, C:\Program Files\WindowsPowerShell\Modules).

Lorsqu'on travaille dans des environnements déconnectés, une stratégie courante consiste à utiliser un serveur ayant accès à Internet. enregistrer le module avec Save-Module dans un chemin local, puis copiez ce répertoire sur les machines de production. Ensuite, configurez. PSModulePath Il peut également être ajusté avec Ansible, par exemple avec le module win_pathafin que PowerShell puisse détecter ces ressources sans intervention manuelle.

Une fois installé, le module win_dsc peut invoquer n'importe quelle ressource de ces paquets simplement en indiquant le nom dans resource_nameCela ouvre la voie à la réutilisation de solutions éprouvées, telles que les modules Active Directory DSC, pour des tâches comme créer des utilisateurs, des unités d'organisation, des groupes ou configurer des stratégiesLe tout géré depuis vos scénarios.

De plus, un module PowerShell permet de générer automatiquement des modules Ansible à partir de ressources DSC . Le principe est d'analyser la ressource DSC, de créer un module Ansible qui mappe ses paramètres un par un, puis de l'utiliser comme un module standard. Ces générateurs peuvent télécharger des ressources depuis la galerie PowerShell et créer des dizaines de modules qui enrichissent l'écosystème d'automatisation Windows avec Ansible.

Au-delà de DSC et Ansible : d’autres outils d’automatisation dans Azure

Si votre infrastructure est déployée (ou le sera) sur Azure, il est judicieux de s'intéresser aux autres outils qui complètent PowerShell DSC et Ansible . L'objectif n'est pas d'en choisir un seul, mais de comprendre comment ils s'intègrent à la chaîne globale : création de l'infrastructure, configuration du système, déploiement des applications et exploitation continue.

Dans le domaine de l'infrastructure en tant que code (IaC), des solutions comme Terraform ou les langages natifs d'Azure (modèles ARM et Bicep) permettent de définir des réseaux, des machines virtuelles, du stockage et des services managés à l'aide de fichiers déclaratifs. Terraform utilise son propre langage HCL, tandis que Bicep simplifie la syntaxe des anciens modèles ARM. Toutes s'intègrent parfaitement aux pipelines CI/CD et peuvent être combinées avec Ansible pour configurer les machines virtuelles après leur création.

Pour la phase de configuration initiale des machines LinuxAzure prend en charge cloud-initqui exécute des scripts et configure les utilisateurs, les paquets ou les fichiers de configuration lors du premier démarrage. Les fichiers #cloud-config, généralement encodés en base64, sont indépendants de la distribution et dépendent du gestionnaire de paquets propre à chaque distribution, sans que vous ayez à vous en soucier.

Dans le domaine de l'automatisation opérationnelle , Azure Automation joue un rôle important. Il utilise des runbooks (généralement des scripts PowerShell ou Python) exécutables à la demande ou selon une planification, aussi bien sur les ressources Azure que dans les environnements locaux grâce à Hybrid Runbook Worker. De plus, il offre un service DSC managé permettant de publier des configurations et de contrôler leur conformité sur un ensemble de machines.

Enfin, les outils d'intégration continue/déploiement continu (CI/CD) et de gestion du cycle de vie des applications, tels qu'Azure DevOps, Jenkins, Chef, Puppet et Packer, complètent l'écosystème. Chacun d'eux couvre une partie du processus : de la compilation et des tests de code à la génération d'images machine personnalisées, en passant par la garantie de la conformité réglementaire grâce aux tests automatisés.

Gestion des mises à jour, des packages et des applications Windows

L'une des tâches les plus critiques pour toute équipe système est de maintenir Windows à jour avec ses correctifs et mises à jour . Microsoft propose Windows Update et, dans de nombreux environnements d'entreprise, Microsoft Configuration Manager (SCCM) pour gérer le déploiement. Cependant, lorsque des redémarrages fréquents, des fenêtres de maintenance courtes ou des exigences d'orchestration complexes entrent en jeu, ces mécanismes peuvent s'avérer insuffisants ou peu fiables.

La plateforme d'automatisation Ansible facilite l' exécution contrôlée des mises à jour , s'intègre à Windows Update et gère automatiquement les redémarrages nécessaires, de sorte qu'une seule tâche peut installer des dizaines ou des centaines de correctifs tout en conservant le contrôle sur l'état final des nœuds.

Concernant l'installation d'applications, Windows ne dispose pas d'un gestionnaire de paquets natif et unifié comme ceux présents dans les distributions Linux. Le Microsoft Store n'est pas conçu pour les déploiements massifs automatisés : il manque d'outils en ligne de commande performants et repose fortement sur l'interface graphique, ce qui complique son intégration dans les pipelines automatisés.

Pour pallier cette limitation, Ansible intègre des modules permettant la gestion basique des paquets sous Windows et, surtout, fonctionne parfaitement avec des solutions comme Chocolatey ou Winget sous Windows , offrant une approche idempotente similaire à celle d'un gestionnaire de paquets classique. En combinant Chocolatey, DSC et les playbooks Ansible, vous pouvez standardiser les catalogues de logiciels pour les serveurs ou les VDI avec un minimum d'intervention manuelle.

Si vous ajoutez à cela l'utilisation des ressources DSC pour appliquer les configurations de registre, les services et les stratégies liés à ces applications, vous obtenez une automatisation complète du cycle de vie des logiciels dans vos environnements Windows, de l'installation initiale au renforcement des configurations et aux mises à jour périodiques.

Formation, bonnes pratiques et adoption dans les équipes Windows

Dans de nombreuses équipes informatiques utilisant exclusivement Windows, l' administration repose encore sur l'utilisation de la console graphique et d'assistants. Il est courant de gérer des dizaines, voire des centaines, de machines virtuelles sur VMware ou Hyper-V, dont la création est réalisée manuellement. Le passage à l'automatisation intervient généralement lorsqu'un membre de l'équipe, lassé de la répétition des mêmes tâches, commence à écrire des scripts PowerShell.

Dans ce contexte, une question légitime se pose : « Dois-je continuer à utiliser PowerShell seul, passer à DSC, configurer Ansible… ou tout faire en même temps ? » La réponse la plus pragmatique consiste généralement à les combiner : tirer parti des connaissances existantes en PowerShell et DSC et, simultanément, introduire Ansible comme couche d’orchestration afin de gagner en standardisation et en capacités d’intégration avec d’autres plateformes.

Il existe des cours spécifiques pour les administrateurs Windows qui partent de zéro avec Ansible et se concentrent précisément sur ceci : comment configurer les systèmes Windows pour qu’ils soient gérés avec Ansible, comment écrire des playbooks efficaces, comment intégrer Ansible Tower ou AWX pour lancer des automatisations à partir d’une interface web centralisée et sécurisée, et comment réutiliser le code DSC de ces playbooks afin de ne pas perdre le travail déjà effectué.

En pratique, de nombreuses équipes adoptent une stratégie évolutive : en commençant par automatiser les tâches simples (services, rôles, installation de modules PowerShell), en poursuivant avec les ressources DSC pour les configurations répétitives (IIS, AD, SQL, politiques de sécurité), et en intégrant progressivement l’automatisation dans le pipeline de livraison des applications et les tâches opérationnelles récurrentes.

Il est également important de définir des règles de style, un système de contrôle du code source et des tests pour les playbooks et les configurations DSC, afin que l'automatisation devienne une véritable « infrastructure en tant que code » et non pas une poignée de scripts épars sans contrôle de version ni révisions.

En combinant PowerShell DSC, les modules Ansible, WinRM, Chocolatey et les outils Azure , on crée un écosystème robuste où la création de machines, leur configuration détaillée, le déploiement d'applications et la maintenance continue ne dépendent plus des sessions RDP manuelles. Il en résulte un environnement plus cohérent, auditable et reproductible, où les modifications sont automatiquement documentées dans le code et où les erreurs humaines sont considérablement réduites.