Utiliser Vagrant avec KVM (plugin vagrant-libvirt) pour créer, démarrer, éteindre et remettre à zéro les 2 VM Debian du TP déploiement, puis refaire la démo du script en quelques commandes.
1. Le labo en un coup d’œil
flowchart LR
PC["💻 Mon PC (Pop!_OS)<br/>~/labo-tp-deploiement<br/>Vagrantfile + deploiement.sh"]
PC -- "vagrant up / halt / snapshot" --> LV["libvirt / KVM<br/>(visible dans virt-manager)"]
LV --> WEB["tp-web<br/>192.168.56.10"]
LV --> BDD["tp-bdd<br/>192.168.56.11"]
PC -- "ssh vagrant@IP (le script)" --> WEB
PC -- "ssh vagrant@IP (le script)" --> BDD
VM
IP fixe
Rôles du TP
RAM
Utilisateur
tp-web
192.168.56.10
web + wordpress (+ firewall)
1 Go
vagrant (sudo sans mot de passe)
tp-bdd
192.168.56.11
bdd (+ firewall)
1 Go
vagrant (sudo sans mot de passe)
Chaque VM a 2 cartes réseau :
Carte
Réseau libvirt
Plage
Sert à
eth0
vagrant-libvirt (créé par Vagrant, NAT)
192.168.121.0/24
internet (apt, wget) et vagrant ssh
eth1
tp-deploiement (isolé)
192.168.56.0/24
nos IP fixes, utilisées par le script
Mot
Sens
Vagrant
outil qui crée des VM à partir d’un fichier texte, le Vagrantfile
Box
image de VM toute prête, ici debian/bookworm64 (Debian 12 officielle)
Provider
l’hyperviseur que Vagrant pilote : ici libvirt (= KVM), au lieu de VirtualBox
Provisioning
ce que Vagrant fait dans la VM après l’avoir créée. Ici : seulement copier notre clé SSH
Snapshot
photo d’une VM à un instant donné, pour y revenir plus tard
2. Installation (une seule fois, déjà faite sur mon PC)
Ubuntu 24.04 (et donc Pop!_OS 24.04) n'a plus Vagrant dans ses dépôts (changement de licence de HashiCorp en 2023). On l'installe depuis le dépôt officiel HashiCorp.
# 0. donner son mot de passe a sudo AVANT (sinon la question est cachee par wget, voir partie 7)sudo -v# 1. la cle qui prouve que les paquets viennent bien de HashiCorpwget -qO - https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg# 2. le depot HashiCorp pour Ubuntu 24.04 (noble)echo "deb [arch=amd64 signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com noble main" | sudo tee /etc/apt/sources.list.d/hashicorp.list# 3. vagrant + libvirt-dev (necessaire pour compiler le plugin)sudo apt update && sudo apt install -y vagrant libvirt-dev# 4. le plugin KVM (SANS sudo : il s'installe dans ~/.vagrant.d)vagrant plugin install vagrant-libvirt# 5. verificationvagrant --version # Vagrant 2.4.9vagrant plugin list # vagrant-libvirt (0.12.2, global)
Prérequis déjà en place sur le PC : KVM (/dev/kvm), libvirt, virt-manager, être dans le groupe libvirt, et une clé SSH ~/.ssh/id_ed25519 (sinon : ssh-keygen -t ed25519).
3. Le Vagrantfile du labo
Fichier : ~/labo-tp-deploiement/Vagrantfile. Copie dans le vault : scripts/virtualisation/Vagrantfile-tp-deploiement.
# notre cle ssh publique, copiee dans les VM pour faire "ssh vagrant@IP" sans mot de passeCLE_PUBLIQUE = File.read(File.expand_path("~/.ssh/id_ed25519.pub")).stripVagrant.configure("2") do |config| config.vm.box = "debian/bookworm64" # pas de dossier partage /vagrant (inutile pour le TP) config.vm.synced_folder ".", "/vagrant", disabled: true config.vm.provider "libvirt" do |libvirt| # connexion systeme : les VM apparaissent dans virt-manager libvirt.uri = "qemu:///system" # nom des VM dans virt-manager : tp-web et tp-bdd (sans prefixe) libvirt.default_prefix = "" libvirt.memory = 1024 libvirt.cpus = 1 end # on ajoute notre cle dans /home/vagrant/.ssh/authorized_keys (si elle n'y est pas deja) config.vm.provision "shell", privileged: false, inline: <<-SHELL grep -qF "#{CLE_PUBLIQUE}" ~/.ssh/authorized_keys || echo "#{CLE_PUBLIQUE}" >> ~/.ssh/authorized_keys SHELL # VM 1 : web + wordpress config.vm.define "tp-web" do |web| web.vm.hostname = "tp-web" web.vm.network "private_network", ip: "192.168.56.10", libvirt__network_name: "tp-deploiement", libvirt__forward_mode: "none" end # VM 2 : bdd config.vm.define "tp-bdd" do |bdd| bdd.vm.hostname = "tp-bdd" bdd.vm.network "private_network", ip: "192.168.56.11", libvirt__network_name: "tp-deploiement", libvirt__forward_mode: "none" endend
Ligne
Ce qu’elle fait
File.read(...id_ed25519.pub)
lit notre clé SSH publique sur le PC (la privée ne quitte jamais le PC)
config.vm.box
l’image de départ, téléchargée une seule fois (~300 Mo)
synced_folder ... disabled: true
pas de dossier partagé /vagrant (avec libvirt il faudrait NFS + sudo)
libvirt.uri = "qemu:///system"
VM « système » → visibles dans virt-manager (connexion QEMU/KVM)
default_prefix = ""
noms courts tp-web / tp-bdd au lieu de labo-tp-deploiement_tp-web
provision "shell", privileged: false
script lancé en tant que vagrant (pas root) : ajoute notre clé si elle n’y est pas déjà (grep -q ... ||)
config.vm.define "tp-web"
une VM : nom, hostname, IP
private_network, ip:
2e carte avec IP fixe, sur le réseau tp-deploiement
libvirt__forward_mode: "none"
réseau isolé : les VM et le PC se voient, mais pas de sortie internet par là (internet passe par eth0)
Rien d'autre dans le provisioning
Pas d’apache, pas de mariadb, pas d’iptables : les VM doivent rester vides, c’est le script du TP qui installe tout.
4. Les commandes du quotidien
Toujours dans le dossier du labo
Vagrant cherche le Vagrantfile dans le dossier courant : commencer par cd ~/labo-tp-deploiement.
Commande
Effet
vagrant status
état des 2 VM (running, shutoff, not created)
vagrant up
démarre les 2 VM (les crée si elles n’existent pas)
vagrant up tp-web
seulement tp-web
vagrant halt
éteint proprement les 2 VM
vagrant ssh tp-web
terminal sur tp-web (exit pour sortir)
vagrant ssh tp-bdd -c "hostname"
lance une seule commande sur tp-bdd
vagrant snapshot list
liste des snapshots
vagrant snapshot save tp-web nom
crée un snapshot de tp-web
vagrant snapshot restore propre
remet les 2 VM au snapshot propre (elles restent éteintes)
vagrant snapshot restore tp-web propre
seulement tp-web
vagrant destroy -f
supprime les VM (disques compris)
# exemple : verifier que tout repondcd ~/labo-tp-deploiementvagrant statusping -c 2 192.168.56.10ssh vagrant@192.168.56.10 "sudo whoami" # doit afficher root sans rien demander
5. Remettre les VM à zéro (snapshot propre)
Le snapshot propre = les 2 VM juste après leur création : Debian neuve + notre clé SSH, rien d’installé.
cd ~/labo-tp-deploiementvagrant snapshot restore propre # disques remis a zero, VM eteintesvagrant up # on les redemarre (~1 min)
Pourquoi le snapshot a été pris VM éteintes
Un snapshot pris VM allumées garde aussi la mémoire, donc l’heure. Restaurées des jours plus tard, les VM se croient dans le passé, et apt update refuse les listes de paquets « datées du futur ». Pris VM éteintes, il ne garde que le disque : au vagrant up, la VM démarre et reprend l’heure du PC. C’est pour ça qu’il faut un vagrant up après chaque restore.
Pour refaire le snapshot (seulement si on veut changer l’état « propre ») :
vagrant haltvagrant snapshot delete tp-web propre && vagrant snapshot save tp-web proprevagrant snapshot delete tp-bdd propre && vagrant snapshot save tp-bdd proprevagrant up
6. Voir les VM dans virt-manager
Ouvrir Gestionnaire de machines virtuelles (virt-manager).
Connexion QEMU/KVM → tp-web et tp-bdd apparaissent (état En cours d’exécution ou Éteinte).
Clic droit → Ouvrir : l’écran de la VM. Onglet ℹ️ : les 2 cartes réseau, la RAM, le disque.
virsh -c qemu:///system list --all # les VMvirsh -c qemu:///system net-list --all # les reseaux : vagrant-libvirt et tp-deploiementvirsh -c qemu:///system snapshot-list tp-web
Pas de connexion par mot de passe
Le compte vagrant des box Debian n’a pas de mot de passe (connexion par clé uniquement) : la console de virt-manager affiche l’écran, mais on ne peut pas s’y connecter. Plan B si le SSH est bloqué : le snapshot (partie 5).
7. Faire la démo du TP
Ordre complet (tuto détaillé : TP deploiement - tuto) :
cd ~/labo-tp-deploiementvagrant status # 1. VM running ? sinon :vagrant up./deploiement.sh 192.168.56.11 bdd # 2. Entree a la question (= vagrant)./deploiement.sh 192.168.56.10 wordpress # 3. installe aussi apache + php./deploiement.sh 192.168.56.11 firewall # 4. firewall TOUJOURS en dernier./deploiement.sh 192.168.56.10 firewallcurl -sL http://192.168.56.10 | grep title # 5. page d'installation de wordpressvagrant snapshot restore propre # 6. apres la demo : remise a zerovagrant up
Démo automatique dans une fenêtre de terminal (remise à zéro, les 4 étapes, les vérifications, puis les 11 tests) : bash tests/demo_terminal.sh dans ~/labo-tp-deploiement (~10 min).
8. Recréer le labo de zéro (autre PC, ou après un destroy)
mkdir ~/labo-tp-deploiement && cd ~/labo-tp-deploiementcp "$HOME/obsidian/truc non trier/scripts/virtualisation/Vagrantfile-tp-deploiement" Vagrantfile# + copier deploiement.sh dans ce dossier, puis : chmod u+x deploiement.shvagrant up --provider=libvirt # cree les 2 VM (~3 min la 1re fois)ssh-keygen -R 192.168.56.10; ssh-keygen -R 192.168.56.11 # oublie les anciennes empreintesssh-keyscan 192.168.56.10 192.168.56.11 >> ~/.ssh/known_hostsvagrant halt # snapshot VM eteintesvagrant snapshot save tp-web proprevagrant snapshot save tp-bdd proprevagrant up
ssh-keyscan ajoute l’empreinte des VM dans known_hosts : ssh ne posera plus la question « Are you sure you want to continue connecting ».
Exercices corrigés
Exercice 1. Tu as cassé tp-bdd en testant, mais tp-web est bonne. Remets seulement tp-bdd à zéro.
Correction
cd ~/labo-tp-deploiementvagrant snapshot restore tp-bdd proprevagrant up tp-bdd
Exercice 2. Après le rôle firewall, ssh vagrant@192.168.56.10 ne répond plus. Que fais-tu ?
Correction
On ne bricole pas : on restaure le snapshot.
vagrant snapshot restore tp-web proprevagrant up tp-web
Puis on relance les rôles dans l’ordre (web/wordpress avant firewall).
Exercice 3. Après un vagrant destroy -f puis vagrant up, ssh affiche WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!. Pourquoi, et comment corriger ?
Correction
Les VM recréées ont de nouvelles clés SSH : l’empreinte enregistrée dans ~/.ssh/known_hosts ne correspond plus. Ce n’est pas une attaque, c’est normal ici :