Réponse rapide

Un lab vagrant multi machine utile repose sur plusieurs VM nommées, des IP fixes, des ports dédiés, un accès SSH reproductible et un objectif clair de validation. Le but n’est pas seulement de lancer plusieurs machines, mais de recréer un mini parc cohérent pour tester un rôle, une montée de version, une connectivité inter-services ou une checklist préproduction avant impact réel.

Pourquoi créer un lab Vagrant multi-VM avant de toucher à la vraie infrastructure

Quand une équipe doit valider une évolution système, un playbook Ansible ou une nouvelle combinaison de versions, le plus risqué reste souvent l’absence d’environnement intermédiaire crédible. Soit on teste sur un poste local trop simple, soit on improvise sur une VM de préprod mal tenue, soit on modifie la prod trop tôt.

Le mot-clé vagrant multi machine répond à ce problème concret. Avec plusieurs VM définies dans un même Vagrantfile, tu peux reproduire un petit parc de serveurs, rejouer les mêmes commandes et retrouver un environnement cohérent d’une session à l’autre.

Dans un contexte d’entreprise, ce type de lab permet de réduire le risque de dérive entre OS, de valider les prérequis et de raccourcir les allers-retours entre exploitation, automatisation et sécurité. C’est aussi un bon complément à un audit de gouvernance d’infrastructure quand il faut prouver comment les changements sont testés avant mise en production.

Ce que montre concrètement le repo GitLab vagrant-mon-infra

Le repo source utilisé ici est babidi34/vagrant-mon-infra. Le README pose les prérequis, et surtout le Vagrantfile définit déjà plusieurs machines avec leurs caractéristiques.

Comment structurer les VM dans un Vagrantfile multi-machine

L’intérêt d’un Vagrantfile multi-VM est de centraliser dans un seul fichier la définition des machines, des ressources et du réseau. Dans le repo, on retrouve une logique claire : nom de machine, box, CPU, mémoire, port forwardé et IP privée.

# Exemple simplifié inspiré du repo
Vagrant.configure("2") do |config|
  config.vm.define "debian13-test" do |node|
    node.vm.box = "debian/trixie64"
    node.vm.network "private_network", ip: "192.168.56.183"
    node.vm.network "forwarded_port", guest: 22, host: 2228, id: "ssh"
  end
end

Ce type de structure permet de savoir immédiatement quelle VM sert à quoi. C’est beaucoup plus fiable qu’un ensemble de machines lancées à la main avec des paramètres oubliés au fil du temps.

# Démarrer tout le lab
vagrant up

# Cibler une seule machine
vagrant up debian13-test

# Se connecter en SSH
vagrant ssh debian13-test

Si tu veux utiliser ce lab pour de l’automatisation, le plus important est la stabilité des noms et des IP. C’est ce qui rend les tests rejouables dans le temps.

# Exemple de validation Ansible après démarrage du lab
ansible -i inventory all -m ping
ansible-playbook -i inventory site.yml

Ce genre de validation s’intègre bien avec une démarche d’maintenance de serveurs Linux quand tu veux éviter les changements non testés sur des machines critiques.

Checklist de validation avant de toucher à la production

Erreurs fréquentes avec un lab Vagrant multi machine

FAQ