Configuration d'un laboratoire Linux local avec exemples pratiques : guide d'implémentation pratique

Un laboratoire Linux local est un espace contrôlé sur votre poste de travail où vous pouvez essayer des idées, tester des modifications et diagnostiquer des problèmes sans risquer d'affecter des environnements partagés. Vous pouvez le remettre à un état connu en quelques minutes, observer le comportement réel du système et pratiquer des flux de travail reproductibles qui se transposent en production. Ce guide se concentre sur une configuration sûre et vérifiable utilisant des machines virtuelles Linux, des commandes concrètes, des sorties attendues et des chemins de restauration fiables. Vous allez construire une petite topologie à deux VM (client et serveur) adaptée aux tests de services, aux vérifications réseau et aux expérimentations pratiques.

Ce que vous allez construire

• Hôte : Linux avec KVM/libvirt
• VM 1 (lab-srv) : 2 vCPU, 2 Go RAM, 20 Go disque exécutant Nginx comme service HTTP de test
• VM 2 (lab-cli) : 1 vCPU, 1 Go RAM, 10 Go disque pour les tests côté client (curl, ping, traceroute)
• Réseau : réseau NAT par défaut de libvirt (accès Internet via l'hôte), réseau host-only optionnel plus tard
• Sécurité : snapshots sur les deux VM pour permettre un retour arrière rapide

Pourquoi commencer petit

Un laboratoire au périmètre restreint est mesurable, rapide à valider et facile à réinitialiser en cas de casse. Cela accélère l'apprentissage et réduit le temps passé à corriger les erreurs.

Inventaire des versions et de l'environnement

Avant de construire le laboratoire, notez ce dont vous partez et définissez un périmètre restreint et inspectable. Le premier pilote doit être étroit et mesurable : par exemple, démarrer une VM serveur exécutant Nginx et une VM cliente capable de l'interroger via un réseau privé.

Enregistrer l'OS hôte et les versions (exécuter sur l'hôte)

cat /etc/os-release
uname -r
lscpu | grep -E 'Virtualization|Model name'
systemd --version | head -1
bash --version | head -1
virsh --version
qemu-system-x86_64 --version | head -1

Vérifier le matériel et les ressources (exécuter sur l'hôte)

lsmod | grep -E 'kvm_(intel|amd)'
free -h
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
ip addr
ip route

Définir la topologie initiale

• Un réseau NAT via libvirt (par défaut) pour que les VM puissent récupérer des paquets depuis Internet via l'hôte
• Deux VM pour garder les domaines de défaillance simples
• Snapshots immédiatement après l'installation de base et après l'installation du service

Exemple d'inventaire

Chemin de configuration sécurisé

Les objectifs de conception :

• Isoler les expériences de l'hôte
• Maintenir le périmètre réseau étroit
• Permettre un retour arrière rapide avec les snapshots

Les étapes ci-dessous supposent un hôte de type Debian/Ubuntu. Lorsque c'est utile, les alternatives Fedora/RHEL sont indiquées.

1. Installer KVM et libvirt (exécuter sur l'hôte)

# Debian/Ubuntu
sudo apt update
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients virt-manager

# Fedora/RHEL
sudo dnf install -y @virtualization virt-install virt-manager
sudo systemctl enable --now libvirtd

Ajoutez votre utilisateur au groupe libvirt et réévaluez votre session :

sudo usermod -aG libvirt $USER
newgrp libvirt

2. Vérifier la virtualisation sur l'hôte

# Doit retourner une sortie non vide si supporté
lsmod | grep -E 'kvm_(intel|amd)'

# Le réseau par défaut de libvirt doit être présent
virsh net-list --all
virsh net-start default || true
virsh net-autostart default

Attendu : le réseau par défaut apparaît comme actif. Sinon, consultez la section Modes de défaillance plus loin.

3. Créer les disques des VM (exécuter sur l'hôte)

# Ajustez les chemins et les tailles selon vos besoins
sudo qemu-img create -f qcow2 /var/lib/libvirt/images/lab-srv.qcow2 20G
sudo qemu-img create -f qcow2 /var/lib/libvirt/images/lab-cli.qcow2 10G

4. Installer lab-srv à partir d'une ISO

# Remplacez le chemin de l'ISO et la variante d'OS selon le cas
sudo virt-install \
  --name lab-srv \
  --memory 2048 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/lab-srv.qcow2,format=qcow2,bus=virtio \
  --cdrom /var/lib/libvirt/boot/ubuntu-22.04-live-server-amd64.iso \
  --network network=default,model=virtio \
  --os-variant ubuntu22.04 \
  --graphics vnc \
  --noautoconsole

Terminez l'installation dans la console (virt-manager peut s'attacher à la VM si nécessaire) et définissez :

• Nom d'hôte : lab-srv
• Utilisateur : labops (créé), avec sudo
• Réseau : DHCP via le NAT par défaut

5. Installer lab-cli de manière similaire

sudo virt-install \
  --name lab-cli \
  --memory 1024 \
  --vcpus 1 \
  --disk path=/var/lib/libvirt/images/lab-cli.qcow2,format=qcow2,bus=virtio \
  --cdrom /var/lib/libvirt/boot/ubuntu-22.04-live-server-amd64.iso \
  --network network=default,model=virtio \
  --os-variant ubuntu22.04 \
  --graphics vnc \
  --noautoconsole

Définissez le nom d'hôte lab-cli, l'utilisateur labops, réseau DHCP.

6. Post-installation de base sur chaque VM (exécuter à l'intérieur de chaque VM)

# Mettre à jour les paquets
sudo apt update && sudo apt -y upgrade  # Debian/Ubuntu
# ou
sudo dnf -y update  # Fedora/RHEL

# Confirmer le nom d'hôte et le réseau
hostnamectl
ip addr

Optionnellement, ajoutez des noms prévisibles dans /etc/hosts sur les deux VM pour la résolution de noms. Remplacez les IP par celles réelles de vos VM :

sudo sh -c 'echo "192.168.122.101 lab-srv" >> /etc/hosts'
sudo sh -c 'echo "192.168.122.102 lab-cli" >> /etc/hosts'

(Vous pouvez aussi vous contenter des adresses IP ; ceci est pour la commodité.)

7. Snapshots de référence (exécuter sur l'hôte)

virsh shutdown lab-srv && virsh shutdown lab-cli
# Attendre que les deux soient arrêtés
virsh dominfo lab-srv | grep State
virsh dominfo lab-cli | grep State

# Créer les snapshots nommés baseline
virsh snapshot-create-as lab-srv baseline "Post-OS baseline" --disk-only --atomic
virsh snapshot-create-as lab-cli baseline "Post-OS baseline" --disk-only --atomic

# Redémarrer les deux VM
virsh start lab-srv
virsh start lab-cli

Note : si votre pool de stockage n'autorise pas les snapshots disque uniquement, omettez --disk-only. Assurez-vous que vos images qcow2 supportent les snapshots.

8. Installer un service de test simple sur lab-srv (à l'intérieur de lab-srv)

# Installer Nginx
sudo apt -y install nginx  # Debian/Ubuntu
# ou
sudo dnf -y install nginx  # Fedora/RHEL

# Démarrer et activer
sudo systemctl enable --now nginx

# Vérifier le statut
systemctl is-active nginx && systemctl is-enabled nginx

Si vous utilisez un pare-feu sur la VM :

# Exemple UFW (Ubuntu)
sudo ufw allow 80/tcp
sudo ufw reload

# Exemple firewalld (Fedora/RHEL)
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload

9. Deuxième snapshot après l'installation du service (exécuter sur l'hôte)

virsh shutdown lab-srv
virsh snapshot-create-as lab-srv svc-nginx "Nginx installé et en cours d'exécution" --disk-only --atomic
virsh start lab-srv

Vérification et diagnostics

La vérification signifie des preuves observables : l'hyperviseur tourne, les VM démarrent, elles communiquent sur le réseau prévu et le service répond avec le contenu attendu. Utilisez ces contrôles et comparez aux résultats attendus.

1. Contrôles au niveau hôte (exécuter sur l'hôte)

# Réseaux libvirt actifs
virsh net-list
# VM en cours d'exécution
virsh list --all

Attendu : le réseau par défaut est actif ; lab-srv et lab-cli sont en cours d'exécution.

2. Trouver les adresses IP des VM

À l'intérieur de chaque VM, exécutez :

ip -4 addr show dev eth0 | awk '/inet /{print $2}'

Attendu : adresses dans la plage 192.168.122.0/24 (libvirt par défaut) sauf modification.

3. Connectivité de base (à l'intérieur de lab-cli)

# Remplacez par l'IP de lab-srv
LAB_SRV_IP=192.168.122.101
ping -c 3 $LAB_SRV_IP

Attendu : perte de paquets nulle ou faible.

4. Vérification du service HTTP (à l'intérieur de lab-cli)

# Si curl manque : sudo apt -y install curl || sudo dnf -y install curl
curl -s -o /dev/null -w "%{http_code}\n" http://$LAB_SRV_IP/

Attendu : 200

Récupérez et affichez quelques octets pour prouver le contenu :

curl -s http://$LAB_SRV_IP/ | head -n 5

Attendu : HTML contenant une référence à nginx ou votre page index personnalisée.

5. Service et journaux (à l'intérieur de lab-srv)

systemctl status nginx --no-pager
journalctl -u nginx --since "-5m" --no-pager

Attendu : actif (running), réponses 200 récentes dans les journaux si la journalisation est activée.

6. Heure et entropie (dans les deux VM)

timedatectl | sed -n '1,4p'

Attendu : "System clock synchronized: yes\). Sinon, activez systemd-timesyncd ou chrony selon la distribution.

Tableau de référence rapide

Modes de défaillance et récupération

Lorsqu'un problème survient, identifiez rapidement le symptôme, confirmez avec une commande ciblée et réparez ou restaurez.

Commandes et patterns de récupération

Reconstruire ou redémarrer le réseau par défaut libvirt (exécuter sur l'hôte)

virsh net-destroy default || true
virsh net-undefine default || true
# Recréer le réseau par défaut à partir du modèle
sudo cp /usr/share/libvirt/networks/default.xml /tmp/default.xml
sudo virsh net-define /tmp/default.xml
virsh net-start default
virsh net-autostart default

Restauration par snapshot (exécuter sur l'hôte)

# Toujours arrêter d'abord
virsh shutdown lab-srv && virsh shutdown lab-cli

# Revenir au baseline
virsh snapshot-revert lab-srv baseline --running
virsh snapshot-revert lab-cli baseline --running

Si vous souhaitez conserver l'état cassé pour analyse ultérieure, créez un snapshot avant de restaurer :

virsh snapshot-create-as lab-srv pre-revert "État avant restauration"

Réinitialisation du service (à l'intérieur de lab-srv)

# Restaurer la config d'origine si vous avez cassé nginx.conf
sudo cp /etc/nginx/nginx.conf.default /etc/nginx/nginx.conf 2>/dev/null || true
sudo nginx -t
sudo systemctl restart nginx

Si la distribution ne fournit pas de fichier .default, réinstallez le paquet :

# Debian/Ubuntu
sudo apt -y install --reinstall nginx
# Fedora/RHEL
sudo dnf -y reinstall nginx

Corrections de synchronisation horaire (dans n'importe quelle VM)

# Debian/Ubuntu
sudo systemctl enable --now systemd-timesyncd
# Fedora/RHEL
sudo dnf -y install chrony
sudo systemctl enable --now chronyd

Récupération d'espace disque (hôte)

# Lister les snapshots
virsh snapshot-list lab-srv
# Supprimer les snapshots inutiles par nom
virsh snapshot-delete lab-srv svc-nginx

# Confirmer l'utilisation disque
sudo du -sh /var/lib/libvirt/images

Liste de contrôle opérationnelle

Utilisez cette liste à chaque exécution d'expérience.

Avant de commencer

• Confirmer les ressources hôte : au moins 3 Go RAM libre et 30 Go disque libre
• Démarrer libvirt et le réseau par défaut : systemctl status libvirtd; virsh net-list
• Démarrer les VM : virsh start lab-srv; virsh start lab-cli
• Confirmer la synchronisation horaire : timedatectl affiche synchronized: yes
• Vérifier la connectivité de base : ping et curl depuis lab-cli vers lab-srv

Créer un point de sécurité

• Arrêter proprement les VM du laboratoire
• Créer ou mettre à jour un snapshot avec un libellé descriptif
• Redémarrer les VM

Exécuter vos modifications

• Appliquer un seul changement à la fois (configuration, paquet, paramètre noyau)
• Consigner ce que vous avez changé et les commandes exécutées
• Vérifier avec des contrôles observables et enregistrer des exemples de sorties

Si quelque chose casse

• Vérifier le statut et les journaux du service concerné
• Utiliser le tableau des défaillances pour identifier la cause probable
• Si la réparation prend plus de quelques minutes, revenir au dernier snapshot

À la fin

• Décider : conserver le nouvel état (prendre un snapshot) ou revenir au baseline
• Nettoyer les fichiers temporaires et les snapshots inutilisés
• Noter ce qui a fonctionné, ce qui a échoué et pourquoi

Maintenance hebdomadaire

• Mettre à jour les paquets sur les deux VM et tester que les services redémarrent
• Créer un nouveau snapshot baseline après les mises à jour
• Purger les snapshots obsolètes pour maîtriser l'espace disque
• Vérifier que vos images ISO et définitions de VM restent accessibles

Tableau de contrôle rapide

Conclusion

Avec un petit laboratoire Linux à deux VM et une restauration fiable, vous pouvez explorer en toute sécurité des modifications de configuration, répéter des mises à niveau et diagnostiquer des incidents sans dommages collatéraux. L'approche présentée maintient le périmètre étroit, met l'accent sur des résultats observables et préserve toujours un chemin de retour. Prochaines étapes immédiates :

• Modéliser vos commandes de création de VM pour pouvoir lancer de nouveaux laboratoires rapidement
• Ajouter un second réseau (host-only) afin de tester le routage et le filtrage entre segments
• Créer un script Bash réutilisable pour automatiser le démarrage, les snapshots, la restauration et les vérifications
• Étendre progressivement le laboratoire (par exemple, ajouter une VM bastion SSH ou une VM base de données) uniquement lorsque votre flux de travail actuel est reproductible et rapide

En gardant vos expériences mesurables et faciles à inspecter localement, vous itérerez plus vite, réduirez le travail redondant et développerez une confiance opérationnelle qui se transpose aux environnements plus vastes.