Installation d’un poste Windows avec WSL, Hyper-V et Ansible

Configuration d’un environnement DevOps performant sur Windows 11

Ce document présente un guide détaillé pour la configuration d’un environnement de développement et d’opérations (DevOps) performant sur un ordinateur Windows 11 doté de spécifications avancées :

• Windows 11 Pro
• 64 Go de RAM
• un processeur Intel Core i9-13950HX
• Nvidia RTX 4000
• un SSD de 2 To.

Ce matériel haut de gamme est particulièrement adapté à l’exécution de plusieurs environnements virtualisés.

L’objectif est d’exploiter le Sous-système Windows pour Linux (WSL) avec la distribution Debian, la fonctionnalité Hyper-V pour la création de machines virtuelles, l’éditeur de code Visual Studio Code pour le développement, et l’outil d’automatisation Ansible pour le provisionnement et la gestion de ces machines virtuelles. Ce guide fournira une approche pas à pas pour installer et configurer chaque composant, en mettant l’accent sur leur intégration pour un flux de travail DevOps efficace.

Les principaux éléments abordés seront l’installation et la configuration de WSL avec Debian, l’activation et la gestion d’Hyper-V, l’intégration de Visual Studio Code avec l’extension Remote - WSL, et l’installation et la configuration d’Ansible au sein de l’environnement WSL Debian.

Préparation de la base : Installation et configuration de WSL avec Debian

Le Sous-système Windows pour Linux (WSL) permet d’exécuter un environnement GNU/Linux directement sur Windows, sans la surcharge d’une machine virtuelle traditionnelle. [1] Ceci est particulièrement avantageux pour les développeurs qui préfèrent un environnement de ligne de commande Linux pour certaines tâches tout en continuant à travailler sous Windows. Avant de commencer, il est nécessaire de s’assurer que le système répond aux prérequis : Windows 10 version 2004 ou supérieure (Build 19041 et supérieur) ou Windows 11, avec toutes les mises à jour installées.[2,3] Il est recommandé de toujours maintenir le système d’exploitation à jour pour garantir la compatibilité et la sécurité.

La méthode la plus efficace pour installer WSL sur Windows 11 est d’utiliser la commande

wsl --install

dans PowerShell ou l’invite de commandes exécutée en tant qu’administrateur. Cette commande unique active les fonctionnalités nécessaires pour exécuter WSL et installe par défaut la distribution Ubuntu. Pour vérifier si WSL est déjà installé ou pour lister les distributions Linux disponibles en ligne, les commandes

wsl --list --online

ou

wsl -l -o

peuvent être utilisées.[3, 4] Une autre méthode, plus manuelle, consiste à activer les fonctionnalités optionnelles “Sous-système Windows pour Linux” et “Plateforme de machine virtuelle” via PowerShell en utilisant les commandes:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Quelle que soit la méthode initiale, un redémarrage de la machine est généralement requis après l’installation de WSL.[2,5]

Bien qu’Ubuntu soit installé par défaut avec la commande

wsl --install

, nous allons installer une distribution Debian. Par conséquent, il est nécessaire de spécifier la distribution Debian lors de l’installation. La commande à utiliser dans PowerShell est [3, 6]

wsl --install -d Debian

Il est important d’exécuter PowerShell en tant qu’administrateur pour cette commande afin d’assurer les permissions nécessaires. Debian peut également être installé à partir du Microsoft Store.[2, 7, 8] Cette alternative offre une interface graphique pour ceux qui la préfèrent, en recherchant “Debian” dans le Store et en cliquant sur “Obtenir”. Pour profiter pleinement des capacités de WSL, notamment pour la prise en charge des applications graphiques et de systemd, il est crucial de définir WSL 2 comme version par défaut en utilisant la commande

wsl --set-default-version 2

dans PowerShell.[5, 7] La première fois que Debian est lancé, il sera demandé de créer un nouveau nom d’utilisateur et un mot de passe Unix.[6, 9, 10] Une fois Debian installé, il est recommandé de mettre à jour les listes de paquets et de mettre à niveau les paquets existants à l’aide des commandes :

sudo apt update
sudo apt full-upgrade -y

dans le terminal Debian. Cela garantit que le système dispose des dernières versions logicielles et des correctifs de sécurité. Pour activer systemd dans WSL 2, il faut ajouter les lignes suivantes au fichier /etc/wsl.conf :

[boot]
systemd=true

puis redémarrer WSL en utilisant les commandes :[1, 7, 10]

wsl --shutdown -d Debian
wsl -d Debian

L’activation de systemd est importante pour la compatibilité avec de nombreux paquets Debian et pour la prise en charge des applications graphiques, car il s’agit du système d’initialisation standard pour les distributions Linux modernes. Des outils supplémentaires tels que openssh-client et bash-completion peuvent également être installés pour améliorer l’expérience utilisateur.[10]

Déverrouillage de la virtualisation : Activation et configuration d’Hyper-V

Hyper-V est un hyperviseur natif sur Windows qui permet la création et la gestion de machines virtuelles[4] Il offre la possibilité d’exécuter plusieurs systèmes d’exploitation simultanément sur le même matériel physique. Avant d’activer Hyper-V, il est important de vérifier que le système répond aux exigences : processeur 64 bits avec traduction d’adresses de second niveau (SLAT), prise en charge par le CPU du mode d’extension du moniteur de machine virtuelle (VT-c sur les CPU Intel), et un minimum de 4 Go de mémoire vive.[12] Il est à noter qu’Hyper-V ne peut pas être installé sur les éditions Windows 10/11 Home.

Il existe trois méthodes principales pour activer Hyper-V :

1. Utilisation de PowerShell : Ouvrir PowerShell en tant qu’administrateur et exécuter la commande :

   Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
   

   Cette commande active toutes les fonctionnalités d’Hyper-V.
2. Utilisation de CMD/PowerShell avec DISM : Ouvrir CMD ou PowerShell en tant qu’administrateur et exécuter la commande :

   DISM /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V
   

   DISM est un autre outil en ligne de commande pour la gestion des fonctionnalités Windows.
3. Via le menu Paramètres : Aller dans Programmes -> Programmes et fonctionnalités -> Activer ou désactiver des fonctionnalités Windows -> Cocher Hyper-V -> OK.[12] Cette méthode offre une interface graphique pour activer la fonctionnalité.

Pour que les machines virtuelles Hyper-V puissent communiquer entre elles, avec le système hôte et avec les réseaux externes, il est nécessaire de créer et de gérer des commutateurs virtuels.[13, 14] Un commutateur virtuel agit comme un commutateur réseau logique au sein de l’environnement Hyper-V. Il existe trois types de commutateurs virtuels :

• Externe : Se connecte à une carte réseau physique, permettant aux machines virtuelles de communiquer avec le réseau externe et l’hôte.[14, 15] Ce type de commutateur sera probablement nécessaire pour qu’Ansible puisse gérer les machines virtuelles et pour que celles-ci puissent accéder à des ressources externes.
• Interne : Permet la communication entre les machines virtuelles sur l’hôte et l’hôte lui-même.[14, 15] Cela peut être utile pour créer des réseaux isolés à des fins de test.
• Privé : Permet la communication uniquement entre les machines virtuelles sur le même hôte.[14, 15, 16] Cela offre l’environnement réseau le plus isolé.

Pour créer un commutateur virtuel externe à l’aide du Gestionnaire Hyper-V [12, 14, 16, 17, 18], il faut ouvrir le Gestionnaire Hyper-V (le rechercher dans le menu Démarrer), puis dans le volet Actions (à droite), sélectionner Gestionnaire de commutateurs virtuels. Choisir Externe, puis Créer un commutateur virtuel. Entrer un nom pour le commutateur, sélectionner la carte réseau physique souhaitée dans le menu déroulant pour que les machines virtuelles puissent communiquer avec le monde extérieur, et cliquer sur OK. Un avertissement concernant une éventuelle interruption de la connectivité réseau de l’hôte peut apparaître ; il faut confirmer l’opération. Il est également possible d’autoriser le système d’exploitation de gestion (l’hôte Windows) à partager la carte réseau sélectionnée pour un commutateur externe en cochant l’option “Autoriser le système d’exploitation de gestion à partager cette carte réseau” dans les propriétés du commutateur virtuel au sein du Gestionnaire Hyper-V.[14] Cela permet à l’hôte de communiquer sur le même commutateur virtuel que les machines virtuelles. La commande PowerShell suivante peut également être utilisée pour créer un commutateur virtuel externe, en remplaçant les espaces réservés par le nom souhaité pour le commutateur et le nom de la carte réseau physique (obtenu à l’aide de Get-NetAdapter) :

New-VMSwitch -Name "<nom-du-commutateur>" -NetAdapterName "<nom-de-la-carte-réseau>"

[14] Pour les commutateurs internes ou privés, les commandes sont :

New-VMSwitch -Name "<nom-du-commutateur>" -SwitchType Internal
New-VMSwitch -Name "<nom-du-commutateur>" -SwitchType Private

L’utilisation d’Ansible dans WSL pour tester des playbooks sur des machines virtuelles Hyper-V indique fortement la nécessité d’un commutateur virtuel externe pour faciliter la communication entre ces environnements et potentiellement le réseau au sens large. Ansible, fonctionnant dans WSL, aura besoin d’un chemin réseau pour atteindre les machines virtuelles, et celles-ci pourraient avoir besoin d’un accès à Internet pour que les playbooks puissent provisionner des logiciels. La compréhension des différents types de commutateurs virtuels permet d’adapter la configuration réseau à ses besoins spécifiques, en créant potentiellement des environnements de test isolés si nécessaire.[14, 15] Bien qu’un commutateur externe soit probablement le besoin principal pour qu’Ansible puisse gérer les machines virtuelles, l’utilisateur pourrait vouloir créer des réseaux internes pour des scénarios de test spécifiques où l’isolement est important.

Pont entre les environnements : Configuration réseau

Par défaut, WSL 2 utilise une architecture basée sur la traduction d’adresses réseau (NAT).[19] Cela signifie que l’instance WSL 2 partage l’adresse IP de l’hôte Windows et utilise le transfert de port pour exposer les services fonctionnant dans WSL. Le NAT permet à WSL de partager l’adresse IP de l’hôte et d’accéder au réseau via l’interface réseau de l’hôte.[19, 20] Cependant, l’accès aux services fonctionnant dans WSL depuis d’autres machines du réseau nécessite généralement des règles de transfert de port spécifiques. Un mode de réseau plus récent, appelé “Mirrored”, est disponible sur Windows 11 22H2 et versions ultérieures. Il peut être activé en définissant networkingMode=mirrored sous la section [wsl2] dans le fichier .wslconfig.[19] Le fichier .wslconfig se trouve généralement dans le répertoire de profil de l’utilisateur (%UserProfile%).

Le mode Mirrored offre plusieurs avantages :[19]

• prise en charge d’IPv6
• connexion aux serveurs Windows via localhost (127.0.0.1)
• compatibilité VPN améliorée
• prise en charge du multicast
• connectivité LAN directe.

Ce mode vise à fournir une intégration réseau plus transparente entre Windows et WSL, en “mirorant” les interfaces réseau présentes dans Windows vers Linux [21], donnant ainsi à l’instance WSL sa propre adresse IP sur le même réseau que l’hôte Windows.

Avec le NAT, WSL obtient généralement une adresse IP distincte sur un réseau virtuel, et la communication avec l’hôte fonctionne souvent via localhost.[19] Pour accéder à WSL depuis l’hôte, il faut utiliser localhost et le port sur lequel le service écoute. Pour accéder à l’hôte depuis WSL, l’adresse IP LAN de l’hôte est généralement nécessaire. L’adresse IP de l’instance WSL peut être trouvée depuis l’hôte Windows à l’aide de la commande :

wsl -d <NomDeLaDistribution> hostname -i

Il peut être utile pour le dépannage ou pour des configurations réseau spécifiques. Les applications réseau Linux peuvent être accessibles depuis Windows en utilisant localhost. Par exemple, un serveur web fonctionnant sur le port 3000 dans WSL est généralement accessible à l’adresse http://localhost:3000 dans un navigateur Windows. Pour accéder aux serveurs Windows depuis Linux en mode NAT, l’adresse IP LAN de l’hôte est nécessaire (obtenue via ip route show | grep -i default | awk '{ print $3}' dans WSL) et l’application Windows pourrait devoir se lier à 0.0.0.0 pour accepter les connexions depuis le LAN.[19] Avec le réseau en mode Mirrored, l’hôte Windows et WSL peuvent souvent se connecter en utilisant localhost, ce qui simplifie la communication entre les deux environnements. Pour les machines virtuelles Hyper-V avec un commutateur virtuel externe, elles obtiendront des adresses IP du même réseau que l’hôte via DHCP de la part du routeur réseau. La communication entre l’hôte et les machines virtuelles sur le même réseau externe devrait être simple en utilisant leurs adresses IP respectives. La communication entre WSL (quel que soit le mode) et les machines virtuelles Hyper-V sur le réseau externe se fera probablement en utilisant les adresses IP respectives de chaque environnement. L’utilisateur devra s’assurer que l’instance WSL et les machines virtuelles Hyper-V se trouvent sur le même réseau ou que le routage est configuré de manière appropriée.

Le Pare-feu Windows et potentiellement le pare-feu Hyper-V peuvent affecter la communication réseau entre ces environnements.[19] Les pare-feu sont essentiels pour la sécurité mais doivent être configurés pour autoriser le trafic légitime. Sur Windows 11 22H2 et versions ultérieures avec WSL 2.0.9+, le pare-feu Hyper-V est activé par défaut [19], ce qui ajoute une couche de sécurité supplémentaire aux machines virtuelles. Des exemples de commandes PowerShell pour configurer le pare-feu Hyper-V afin d’autoriser les connexions entrantes sont les suivants [19, 21, 22, 23] :

Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow

(Cette commande autorise toutes les connexions entrantes vers les machines virtuelles Hyper-V, ce qui peut être approprié pour un environnement de test mais doit être utilisé avec prudence en production).

New-NetFirewallHyperVRule -Name "MonServeurWeb" -DisplayName "Mon Serveur Web" -Direction Inbound -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -Protocol TCP -LocalPorts 80

(remplacer 80 par le port pertinent pour Ansible/WinRM). Cette commande crée une règle spécifique pour autoriser le trafic TCP entrant sur le port 80. L’identifiant VMCreatorId est un identifiant spécifique pour les machines virtuelles Hyper-V.

Il est également conseillé de vérifier les règles du Pare-feu Windows, en particulier en cas de problèmes de connectivité entre WSL et les machines virtuelles Hyper-V ou l’hôte lui-même. Il faut s’assurer que des règles sont en place pour autoriser le trafic sur les ports utilisés par Ansible (probablement via WinRM).

Configuration de l’accès SSH pour la gestion Ansible

Bien qu’WinRM soit la méthode de connexion privilégiée pour Ansible sur Windows, il est également possible d’utiliser SSH, en particulier pour les versions récentes de Windows Server et Windows 11. [51] Le support officiel d’Ansible pour la connexion SSH aux nœuds Windows a été ajouté dans la version 2.18.[51]

Cette section explique comment configurer l’accès SSH pour gérer votre machine Windows 11 avec Ansible. Pour utiliser SSH, le serveur SSH doit être installé et activé sur la machine Windows 11. Microsoft fournit une implémentation OpenSSH incluse dans Windows Server depuis la version 2019 et disponible en tant que fonctionnalité optionnelle sur Windows 11.[51]

Configuration par clé SSH

L’authentification par clé SSH est une méthode sécurisée pour se connecter à des serveurs sans utiliser de mot de passe. Elle repose sur la création d’une paire de clés : une clé privée, que vous conservez en sécurité, et une clé publique, que vous placez sur le serveur auquel vous souhaitez accéder. Génération de la paire de clés : Sur votre machine Linux (WSL Debian), utilisez la commande ssh-keygen pour générer une nouvelle paire de clés SSH. Vous serez invité à choisir un emplacement pour enregistrer la clé et à saisir une phrase secrète (facultatif, mais recommandé pour plus de sécurité).

ssh-keygen -t rsa -b 4096

Par défaut, la clé privée (id_rsa) et la clé publique (id_rsa.pub) sont créées dans le répertoire ~/.ssh/. Ajout de la clé publique au serveur Windows : La clé publique doit être ajoutée au fichier authorized_keys sur la machine Windows 11. Ce fichier se trouve généralement dans le répertoire .ssh du profil de l’utilisateur Windows (par exemple, C:\Users<VotreNomUtilisateur>.ssh\authorized_keys). Si le répertoire .ssh et le fichier authorized_keys n’existent pas, vous devrez peut-être les créer. Le contenu de votre fichier id_rsa.pub (depuis WSL) doit être copié et ajouté à une nouvelle ligne dans le fichier authorized_keys sur Windows. Configuration d’Ansible pour utiliser la clé privée : Dans votre fichier d’inventaire Ansible, pour l’hôte Windows, spécifiez le chemin d’accès à la clé privée en utilisant la variable ansible_ssh_private_key_file.

[windows]
my_vm ansible_host=<Adresse_IP_de_la_VM> ansible_user=<nom_utilisateur_windows> ansible_connection=ssh ansible_shell_type=powershell ansible_ssh_private_key_file=/home/<nom_utilisateur_wsl>/.ssh/id_rsa

Remplacez <Adresse_IP_de_la_VM>, <nom_utilisateur_windows> et /home/<nom_utilisateur_wsl>/.ssh/id_rsa par les valeurs appropriées.

Configuration par mot de passe

L’authentification par mot de passe est une méthode plus simple mais moins sécurisée que l’authentification par clé.

Activation de l’authentification par mot de passe sur le serveur SSH Windows : Par défaut, l’authentification par mot de passe peut être désactivée pour des raisons de sécurité. Vous devrez peut-être modifier la configuration du serveur SSH sur Windows (fichier sshd_config) pour vous assurer que l’option PasswordAuthentication est définie sur yes. Configuration d’Ansible pour utiliser le mot de passe : Dans votre fichier d’inventaire Ansible, pour l’hôte Windows, spécifiez le mot de passe en utilisant la variable ansible_password.

[windows]
my_vm ansible_host=<Adresse_IP_de_la_VM> ansible_user=<nom_utilisateur_windows> ansible_password=<mot_de_passe_windows> ansible_connection=ssh ansible_shell_type=powershell

Alternativement, vous pouvez fournir le mot de passe lors de l’exécution du playbook en utilisant l’option -k ou --ask-pass. Installation de sshpass (si nécessaire) : Pour utiliser l’authentification par mot de passe avec Ansible, le paquet sshpass doit être installé sur la machine de contrôle Ansible (votre instance Debian WSL).

sudo apt update
sudo apt install sshpass -y

Configuration Ansible commune pour SSH :

Quel que soit le mode d’authentification choisi, assurez-vous que les variables suivantes sont définies pour votre hôte Windows dans l’inventaire Ansible [51]:

ansible_connection=ssh
ansible_shell_type=powershell (recommandé) ou ansible_shell_type=cmd

Développement intégré : Configuration de Visual Studio Code avec Remote - WSL

Visual Studio Code est un éditeur de code populaire et extensible qui sera utilisé pour développer et gérer l’environnement DevOps.[27, 28, 29] Son ensemble de fonctionnalités étendu et son écosystème de plugins en font un outil bien adapté aux tâches DevOps. La page de téléchargement officielle est accessible via le lien suivant : https://code.visualstudio.com/download.[28, 30] Il est conseillé de télécharger la version appropriée à l’architecture du système (probablement 64 bits). Pour une expérience de mise à jour en arrière-plan plus fluide, il est recommandé d’utiliser le programme d’installation utilisateur Windows.[27] Ce dernier ne nécessite pas de privilèges d’administrateur et les mises à jour se font en arrière-plan. Il est également conseillé de cocher l’option “Ajouter au PATH” lors de l’installation pour permettre l’utilisation de la commande code depuis le terminal.[27, 31] Cela permet d’ouvrir VS Code depuis n’importe quelle invite de commandes ou fenêtre PowerShell, y compris dans le terminal WSL. L’option d’installation système peut être envisagée si VS Code doit être accessible à tous les utilisateurs du système.[27, 30] Il est à noter l’avertissement dans [30] concernant les problèmes potentiels de permissions utilisateur pour les projets de science des données si l’installateur système n’est pas utilisé avec les privilèges d’administrateur, bien que cela ne soit pas directement pertinent pour le scénario DevOps de l’utilisateur, il est bon de le mentionner. Des méthodes d’installation alternatives, comme l’utilisation d’un fichier ZIP pour les installations portables, sont également disponibles.[27]

Pour une intégration transparente entre VS Code et l’environnement Debian WSL, l’extension “Remote - WSL” de Microsoft est essentielle.[31, 32, 33] Cette extension permet à VS Code de se connecter au Sous-système Windows pour Linux et de travailler avec les fichiers et les processus qui y sont exécutés, offrant ainsi une expérience de développement unifiée. L’installation se fait de la manière suivante : ouvrir VS Code -> Vue Extensions (Ctrl+Shift+X ou cliquer sur l’icône Extensions dans la barre d’activité à gauche) -> Rechercher “Remote - WSL” -> Cliquer sur Installer.[32] L’extension sera alors installée dans VS Code. Il existe également le pack d’extensions “Remote Development” qui inclut Remote - WSL ainsi que des extensions pour SSH et Dev Containers.[31, 32] L’installation de ce pack fournit un ensemble complet d’outils pour divers scénarios de développement à distance.

Une fois l’extension Remote - WSL installée, plusieurs méthodes permettent de se connecter à WSL depuis VS Code :

• Ouvrir un terminal WSL (par exemple, en utilisant le lanceur Debian), naviguer vers un dossier de projet et taper code..[31, 32, 33] C’est un moyen rapide d’ouvrir le répertoire courant dans VS Code dans le contexte WSL.
• Utiliser la palette de commandes de VS Code (Ctrl+Shift+P) et sélectionner “WSL: Connect to WSL” pour se connecter à la distribution WSL par défaut ou “WSL: Connect to WSL using Distro…” pour sélectionner une distribution spécifique (Debian dans ce cas).[31, 32] Cela offre un moyen direct d’initier une connexion WSL depuis VS Code.
• Utiliser la commande “WSL: Reopen Folder in WSL” si un dossier est déjà ouvert dans une fenêtre VS Code locale.[32] Ceci est utile pour changer rapidement le contexte d’un projet ouvert vers WSL.

Une fois connecté, le terminal de VS Code (Terminal > Nouveau Terminal ou Ctrl+`) s’exécutera automatiquement dans l’environnement WSL plutôt que localement sur Windows.[32, 33] Cela garantit que les commandes exécutées dans le terminal sont lancées dans l’environnement Linux Debian. Les extensions pour le développement au sein de WSL (comme les extensions spécifiques aux langages Python ou Node.js) seront installées dans l’environnement WSL, tandis que les extensions liées à l’interface utilisateur (comme les thèmes ou les snippets) seront installées localement sur Windows.[31, 32, 33] VS Code gère l’installation des extensions en fonction du contexte. Il est également possible de parcourir les fichiers du système de fichiers WSL depuis la vue Explorateur de VS Code (Ctrl+Shift+E), qui affichera les chemins de fichiers Linux (par exemple, /home/<nom_utilisateur>/).[8, 32, 33] Cela permet une navigation et une gestion faciles des fichiers dans l’environnement Debian. L’extension Remote - WSL offre une expérience transparente, donnant l’impression de travailler directement dans un environnement Linux tout en bénéficiant de la puissance et de la familiarité de VS Code.[31, 33] Cette intégration transparente améliore la productivité et réduit les frictions liées au travail sur différents systèmes d’exploitation. L’architecture client-serveur de l’extension Remote - WSL garantit que les outils et les débogueurs spécifiques au langage s’exécutent dans l’environnement approprié (WSL), ce qui conduit à une expérience de développement plus fiable.[31, 33] En exécutant les outils de développement spécifiques à Linux directement dans WSL, on évite les problèmes de compatibilité potentiels qui pourraient survenir si ces outils étaient exécutés sur Windows.

Centrale d’automatisation : Installation et configuration d’Ansible dans WSL

Ansible est un puissant moteur d’automatisation qui sera utilisé pour provisionner et gérer les machines virtuelles Hyper-V.[11, 35] Ansible permet l’infrastructure en tant que code et la gestion de configuration automatisée. Le nœud de contrôle d’Ansible (où Ansible s’exécute) peut être presque n’importe quelle machine de type UNIX avec Python installé, y compris les distributions WSL comme Debian.[35] L’environnement Debian WSL de l’utilisateur servira de nœud de contrôle Ansible. Il est recommandé de s’assurer que Python 3 et pip sont installés sur le système Debian au sein de WSL. Cela peut généralement être fait avec la commande :

sudo apt update && sudo apt install python3 python3-pip wget gpg

[36, 37] Python est une dépendance essentielle pour Ansible. Il est également mentionné la nécessité de software-properties-common pour ajouter des PPA (si la méthode PPA est utilisée) et potentiellement d’autres dépendances comme libffi-dev et libssl-dev qui pourraient être requises par certains modules Ansible ou pour des fonctionnalités spécifiques.[11,36, 37] L’architecture sans agent d’Ansible signifie qu’aucun logiciel spécial n’a besoin d’être installé sur les nœuds cibles (les machines virtuelles Hyper-V dans ce cas), ce qui simplifie le processus de gestion.[35] Ansible communique avec les machines cibles via des protocoles standard comme SSH ou WinRM. Bien qu’Ansible puisse être installé à l’aide de pip, la méthode recommandée pour Debian est souvent l’utilisation du gestionnaire de paquets APT pour une meilleure intégration avec le système d’exploitation.[11,35, 37] L’installation via APT garantit qu’Ansible et ses dépendances sont gérés par le système de gestion de paquets Debian, ce qui peut simplifier les mises à jour et prévenir les conflits.

Les étapes pour installer Ansible à l’aide du gestionnaire de paquets APT sont les suivantes [34]:
L’installation pour une version différente de Debian peut être réalisée en changeant la variable UBUNTU_CODENAME. La liste se trouve sur le site [34]

$ UBUNTU_CODENAME=jammy
$ wget -O- "https://keyserver.ubuntu.com/pks/lookup?fingerprint=on&op=get&search=0x6125E2A8C77F2818FB7BD15B93C4A3FD7BB9C367" | sudo gpg --dearmour -o /usr/share/keyrings/ansible-archive-keyring.gpg
$ echo "deb [signed-by=/usr/share/keyrings/ansible-archive-keyring.gpg] http://ppa.launchpad.net/ansible/ansible/ubuntu $UBUNTU_CODENAME main" | sudo tee /etc/apt/sources.list.d/ansible.list
$ sudo apt update && sudo apt install ansible
``
Certaines sources recommandent d'installer `ansible-core` puis éventuellement `ansible` pour un paquet plus complet.[[35]] `ansible-core` contient l'exécution minimale et les modules intégrés, tandis que le paquet `ansible` inclut une sélection plus large de collections Ansible gérées par la communauté. Pour la plupart des utilisateurs, l'installation du paquet `ansible` complet est recommandée. L'utilisation du Ansible officiel garantit que l'utilisateur obtient la dernière version stable d'Ansible et peut facilement recevoir des mises à jour via le système de gestion de paquets Debian standard.[[11], [37], [38]] Cela permet de maintenir l'installation d'Ansible à jour avec les nouvelles fonctionnalités et les corrections de bugs.

L'installation d'Ansible peut être vérifiée en exécutant la commande :

```bash
ansible --version

dans le terminal Debian.[11, 35, 36, 37, 38] La sortie affichera la version d’Ansible installée, l’emplacement du fichier de configuration, les chemins de recherche des modules configurés, l’emplacement du module Python Ansible et l’emplacement des collections Ansible. Le fichier de configuration d’Ansible (ansible.cfg) peut être utilisé pour personnaliser le comportement d’Ansible, et les fichiers d’inventaire définissent les hôtes cibles.[36] Ces éléments seront abordés plus en détail dans le contexte de la gestion d’Hyper-V. Une sortie réussie de ansible --version confirme qu’Ansible est correctement installé et prêt à être utilisé pour les tâches d’automatisation.[11, 35, 36, 37, 38] C’est une étape cruciale pour s’assurer que le processus d’installation s’est déroulé avec succès avant de passer à une configuration plus avancée et à l’utilisation.

Orchestration des machines virtuelles : Configuration d’Ansible pour gérer Hyper-V

Ansible utilise principalement le protocole WinRM (Windows Remote Management) pour communiquer avec les hôtes Windows, y compris les serveurs et les machines virtuelles Hyper-V.[39, 40, 41, 42, 43] WinRM est la méthode standard pour gérer à distance les systèmes Windows. Il s’agit d’un protocole de gestion basé sur SOAP via HTTP/HTTPS, inclus dans tous les systèmes d’exploitation Windows récents.[42] Il permet d’exécuter des commandes et de gérer les systèmes Windows à distance. Ansible utilise le plugin de connexion winrm pour interagir avec les hôtes Windows.[40, 41, 42, 43] Ce plugin doit être configuré dans l’inventaire Ansible pour les hôtes Windows. La librairie Python pywinrm doit être installée sur le nœud de contrôle Ansible (l’instance Debian WSL) pour utiliser le plugin de connexion winrm.[36, 42] Cette librairie fournit les liaisons Python nécessaires pour qu’Ansible communique avec les systèmes Windows via WinRM. Elle peut être installée à l’aide de la commande :

pip3 install --user pywinrm

L’option --user l’installe pour l’utilisateur courant, évitant ainsi les problèmes potentiels de permissions.

Pour gérer les machines virtuelles Hyper-V avec Ansible depuis un nœud de contrôle Linux (WSL), il est nécessaire d’activer et de configurer WinRM sur l’hôte Windows et sur les machines virtuelles elles-mêmes.[39, 42] C’est une exigence fondamentale pour qu’Ansible puisse gérer les machines virtuelles basées sur Windows. La librairie pywinrm agit comme un pont, permettant à Ansible (écrit en Python) d’interagir avec le service WinRM fonctionnant sur les machines Windows.

Les étapes pour activer et configurer WinRM sur la machine hôte Windows 11 sont les suivantes :

1. Ouvrir PowerShell en tant qu’administrateur. L’exécution en tant qu’administrateur est nécessaire pour effectuer des modifications au niveau du système.
2. Exécuter la commande suivante pour configurer rapidement WinRM avec les paramètres par défaut :

   winrm quickconfig
   

   [44, 45] Cette commande démarre le service WinRM, configure le type de démarrage du service sur automatique, crée un écouteur pour accepter les requêtes sur toutes les adresses IP et configure le pare-feu pour autoriser le trafic WinRM sur le port HTTP par défaut (5985).
3. Alternativement, utiliser la commande suivante dans PowerShell en tant qu’administrateur, ce qui effectue des actions similaires et crée également des règles de pare-feu pour la gestion à distance de PowerShell :

   Enable-PSRemoting -Force
   

   [39, 44] L’option -Force supprime les invites de confirmation.
4. Vérifier la configuration WinRM à l’aide de la commande :

   winrm get winrm/config
   

   44 Cette commande affiche les paramètres de configuration WinRM actuels.
5. Pour une communication plus sécurisée, HTTPS peut être configuré pour WinRM, ce qui nécessite un certificat d’authentification du serveur.[46] Pour cette configuration de base, HTTP sur le port 5985 est généralement suffisant.[42, 47] La configuration de HTTPS pour WinRM implique des étapes supplémentaires liées à la gestion des certificats.
6. En cas de problèmes de pare-feu, créer manuellement des règles de trafic entrant dans le Pare-feu Windows Defender pour les ports 5985 (HTTP) et 5986 (HTTPS).[39, 47] Cela garantit que le trafic réseau sur ces ports est autorisé à travers le pare-feu.

L’activation de WinRM sur l’hôte Windows est la première étape critique pour permettre à Ansible fonctionnant dans WSL de gérer les machines virtuelles Hyper-V.[39, 42, 44] Le service WinRM doit être en cours d’exécution et configuré pour accepter les connexions à distance afin qu’Ansible puisse communiquer avec l’environnement Windows. La commande winrm quickconfig offre un moyen pratique d’effectuer la configuration WinRM de base, mais la compréhension des paramètres sous-jacents (démarrage du service, écouteur, règles de pare-feu) est importante pour le dépannage et les configurations plus avancées.[44, 45] Bien que quickconfig soit utile pour la configuration initiale, les utilisateurs doivent être conscients de ce qu’il fait afin de pouvoir ajuster les paramètres si nécessaire, comme la configuration de HTTPS ou la restriction de l’écouteur à des adresses IP spécifiques.

Ansible utilise un fichier d’inventaire pour définir les hôtes qu’il va gérer.[11, 36] Le fichier d’inventaire répertorie les nœuds gérés et peut également contenir des variables spécifiques à ces nœuds. Pour créer un fichier d’inventaire (par exemple, hosts.ini) dans le répertoire du projet Ansible ou dans un emplacement par défaut comme ~/.ansible-hosts [36], il faut créer un fichier texte. Le fichier d’inventaire peut être au format INI ou YAML. Un exemple d’entrée d’inventaire pour une machine virtuelle Hyper-V, incluant son nom d’hôte ou son adresse IP et les paramètres de connexion, est le suivant :

[windows]
my_vm ansible_host=<Adresse_IP_de_la_VM> ansible_user=<nom_utilisateur> ansible_password=<mot_de_passe> ansible_connection=winrm

Il faut remplacer <Adresse_IP_de_la_VM>, <nom_utilisateur> et <mot_de_passe> par les valeurs réelles de la machine virtuelle Hyper-V. L’adresse IP sera attribuée à la machine virtuelle par le réseau du commutateur virtuel externe. Le nom d’utilisateur et le mot de passe doivent correspondre à un compte utilisateur sur la machine virtuelle avec des privilèges suffisants pour effectuer les tâches de gestion souhaitées. Le paramètre ansible_connection=winrm indique à Ansible d’utiliser le plugin de connexion WinRM.[40, 41, 42, 43] D’autres variables Ansible pertinentes peuvent être définies dans l’inventaire ou le playbook, telles que ansible_winrm_transport (par exemple, ntlm ou kerberos), ansible_winrm_port (la valeur par défaut est 5985 pour HTTP) et ansible_winrm_scheme (par exemple, http ou https).[39, 41, 42, 43] Le choix du transport dépend de la méthode d’authentification configurée pour WinRM sur les machines virtuelles. L’inventaire Ansible agit comme le carnet d’adresses central du processus d’automatisation, indiquant à Ansible quelles machines gérer et comment s’y connecter.[11, 36] Un inventaire correctement configuré est essentiel pour qu’Ansible puisse cibler les bonnes machines virtuelles Hyper-V. Les paramètres de connexion winrm dans l’inventaire sont cruciaux pour qu’Ansible utilise le protocole WinRM pour communiquer avec les machines virtuelles Hyper-V basées sur Windows.[40, 41, 42, 43] Ces paramètres fournissent les informations nécessaires à Ansible pour établir une connexion à distance avec les hôtes Windows.

Les playbooks Ansible sont des fichiers YAML contenant une série de tâches à exécuter sur les hôtes cibles.[11, 39] Les playbooks sont le principal moyen de définir les flux de travail d’automatisation dans Ansible. Un exemple simple de playbook Ansible pour exécuter une commande sur une machine virtuelle Hyper-V est le suivant :

---
- name: Tester la connexion à la VM Windows
  hosts: windows
  tasks:
    - name: Obtenir les informations du système d'exploitation
      win_shell: Get-ComputerInfo | Select-Object -Property OsName, OsVersion, WindowsProductName
      register: os_info

    - name: Afficher les informations du système d'exploitation
      debug:
        var: os_info.stdout_lines

La structure de base du playbook est la suivante : --- indique le début d’un document YAML, name fournit une description pour le play, hosts spécifie le groupe cible de l’inventaire (dans ce cas, windows), et tasks répertorie les actions à effectuer sur les hôtes du play. L’utilisation de modules Ansible spécifiques à Windows, comme win_shell, permet d’exécuter des commandes PowerShell sur la machine virtuelle Windows.[39, 48] Ansible fournit une large gamme de modules pour gérer divers aspects des systèmes Windows. Le module win_shell permet d’exécuter des commandes PowerShell arbitraires. Le mot-clé register capture la sortie de la commande dans une variable (os_info). Le playbook peut être exécuté à l’aide de la commande ansible-playbook :

ansible-playbook -i hosts.ini mon_playbook.yml

(remplacer hosts.ini par le chemin d’accès à votre fichier d’inventaire et mon_playbook.yml par le nom de votre fichier de playbook). L’architecture modulaire d’Ansible permet de gérer différents types de systèmes (comme Windows via WinRM) à l’aide de modules spécifiques conçus pour ces plateformes.[40, 41, 42, 43] Cette flexibilité est un atout majeur d’Ansible, lui permettant de gérer des environnements hétérogènes. Il est conseillé de commencer par des playbooks simples pour tester la connectivité et l’exécution de commandes de base avant de tenter des tâches de provisionnement plus complexes.36 Cette approche itérative permet d’identifier et de résoudre rapidement tout problème de configuration.

Bonnes pratiques et considérations avancées

Il est conseillé de surveiller l’utilisation des ressources (CPU, RAM, disque) sur l’hôte Windows lors de l’exécution de WSL et des machines virtuelles Hyper-V. Le Gestionnaire des tâches de Windows peut être utilisé à cette fin. Il est possible de configurer les limites de ressources pour WSL dans le fichier .wslconfig (par exemple, memory=8GB, processors=4). Cela permet à l’utilisateur de contrôler la quantité de mémoire et le nombre de cœurs de CPU que WSL peut utiliser. L’allocation de mémoire et de CPU pour les machines virtuelles Hyper-V peut être ajustée dans le Gestionnaire Hyper-V en modifiant les paramètres de chaque machine virtuelle. Il est recommandé d’allouer les ressources en fonction de la charge de travail prévue des machines virtuelles et des capacités du système hôte. Le matériel haut de gamme de l’utilisateur offre une grande flexibilité à cet égard.

Pour la sécurité de l’environnement DevOps, il est recommandé d’utiliser des mots de passe forts et uniques pour les machines virtuelles Hyper-V et la connexion WinRM. Il faut éviter d’utiliser des mots de passe par défaut ou faciles à deviner. L’utilisation de HTTPS pour la communication WinRM est à envisager pour une sécurité renforcée, en particulier si des données sensibles sont transférées entre Ansible et les machines virtuelles. Cela implique la configuration de certificats pour WinRM. Il est également important de revoir et de restreindre les règles de pare-feu sur l’hôte et les machines virtuelles pour n’autoriser que le trafic nécessaire. Il faut éviter d’autoriser toutes les connexions entrantes sauf si cela est absolument nécessaire pour les tests, et même dans ce cas, limiter la portée si possible. Enfin, il est crucial de maintenir l’hôte Windows, l’environnement WSL et les machines virtuelles Hyper-V à jour avec les derniers correctifs de sécurité. La mise à jour régulière des logiciels est essentielle pour atténuer les vulnérabilités de sécurité.

En cas de problèmes courants, tels que le blocage des connexions par le pare-feu (s’assurer que les ports 5985 et 5986 sont ouverts), une configuration WinRM incorrecte (vérifier que le service est en cours d’exécution et que l’écouteur est configuré) ou des problèmes d’authentification (vérifier les noms d’utilisateur et les mots de passe dans l’inventaire), il est conseillé de consulter les journaux d’événements sur l’hôte Windows et la sortie d’Ansible pour les messages d’erreur. Ces journaux peuvent fournir des indices précieux pour le diagnostic des problèmes. Pour des scénarios plus avancés, il est possible d’explorer l’utilisation de modules Ansible spécifiquement conçus pour la gestion d’Hyper-V (s’ils existent dans les collections de la communauté ou nécessitent des scripts personnalisés). Bien qu’Ansible core ne dispose pas de modules Hyper-V dédiés, les collections de la communauté ou les modules personnalisés pourraient offrir un contrôle plus granulaire. L’utilisation de Vagrant en conjonction avec WSL et Hyper-V peut également être envisagée pour une gestion plus complexe des environnements virtuels.[46,47] Vagrant peut simplifier la création et la gestion d’environnements de machines virtuelles basés sur des fichiers de configuration. Il est à noter que cela pourrait introduire des couches de complexité supplémentaires et pourrait ne pas être nécessaire pour les besoins initiaux de l’utilisateur.

Conclusion

Ce rapport a fourni un guide détaillé pour la configuration d’un environnement DevOps performant sur un ordinateur Windows 11, en tirant parti de WSL avec Debian, d’Hyper-V, de Visual Studio Code et d’Ansible. Les étapes décriDebiantes comprennent l’installation et la configuration de chaque composant, en mettant l’accent sur leur intégration pour un flux de travail DevOps efficace. La configuration d’un tel environnement offre de nombreux avantages pour le développement et les tests locaux, fournissant une plateforme puissante et flexible pour les tâches DevOps sur une machine Windows 11. Il est encouragé d’explorer davantage les modules Ansible et les fonctionnalités Hyper-V pour améliorer le flux de travail DevOps et adapter l’environnement aux besoins spécifiques de l’utilisateur.