Quels outils pour gérer plusieurs serveurs Linux ?

Ce que vous allez mettre en place

Pas un outil unique, mais une courte stack, choisie en fonction du nombre réel de serveurs que vous avez. Ce nombre est le seul paramètre qui compte, et c’est celui que tous les comparatifs des « outils de gestion de serveurs Linux » ignorent. L’erreur classique consiste à adopter une solution prévue pour 200 serveurs avec quatre VPS, puis à passer un mois à alimenter l’outil au lieu de gérer les serveurs. La deuxième erreur classique est de continuer à se connecter manuellement en SSH à chacun de ses dix-huit serveurs et d’appliquer « la même » modification de dix-huit façons légèrement différentes.

Ce guide est donc organisé selon la taille de la flotte : de 2 à 5 serveurs, de 5 à 20, puis au-delà de 20, avec une couche transversale qui s’applique quelle que soit la taille et que personne ne documente : un inventaire, une bonne gestion des clés, un point d’accès unique et des sauvegardes que vous avez réellement restaurées. Pour chaque outil, vous trouverez trois éléments : ce qu’il remplace, le temps de mise en place en minutes et le piège qui pose réellement problème. J’exploite un hébergeur de VPS depuis quinze ans ; la liste ci-dessous correspond à ce qui tient lors d’une panne à 2 heures du matin, pas à ce qui donne une bonne démonstration.

Prérequis et points à connaître

Vous devez déjà disposer d’un accès SSH par clé fonctionnel vers chaque serveur. Si vous saisissez encore des mots de passe, corrigez d’abord ce point. Cela prend dix minutes, et tout ce qui suit suppose l’utilisation de clés. Vous devez également disposer d’un utilisateur sudo qui n’est pas root, ainsi que de serveurs exécutant une version récente. Les commandes de cette page supposent Ubuntu 24.04, mais rien ne dépend d’Ubuntu, à l’exception de apt.

Deux avertissements avant de commencer. Premièrement, la multiplication des outils devient elle-même un problème d’administration. Chaque agent installé est un daemon supplémentaire à mettre à jour sur chaque serveur. N’en ajoutez un que s’il « remplace un travail manuel effectué cette semaine », et non simplement parce qu’il « semble utile ». Deuxièmement, tous les outils présentés ici sont des logiciels libres. Leur coût réel réside dans le temps de configuration. C’est pourquoi chaque outil comporte une estimation en minutes. Si l’estimation indique un après-midi, prévoyez réellement un après-midi.

2 à 5 serveurs : ~/.ssh/config, l’outil le plus sous-estimé dont vous disposez déjà

Ce qu’il remplace : le fichier texte contenant les adresses IP, l’archéologie de l’historique shell (ssh 203.0 puis Ctrl-R en espérant trouver la bonne commande) et la saisie répétée de -p 2222 -i ~/.ssh/other_key. Coût de configuration : 15 minutes, une seule fois. Le piège : les sockets de multiplexage obsolètes, traitées plus bas.

À cette échelle, vous n’avez pas besoin de logiciel supplémentaire. Vous devez configurer le client dont vous disposez déjà comme il faut. ~/.ssh/config transforme chaque serveur en nom court et encode le routage pour que vous n’ayez plus à y penser :

Host *
    ServerAliveInterval 30
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h-%p
    ControlPersist 10m

Host bastion
    HostName 10.0.0.10
    User matt

Host web1
    HostName 10.8.0.11
    User matt
    ProxyJump bastion

Host db1
    HostName 10.8.0.12
    User matt
    Port 2222
    ProxyJump bastion

Trois paramètres suffisent. ProxyJump fait transiter les connexions par un bastion en un seul saut. Ainsi, ssh db1 depuis un café établit automatiquement un tunnel via bastion, sans agent forwarding, sans incantations ProxyCommand, et les serveurs privés n’ont jamais besoin d’exposer de ports SSH publics (voir la section transversale plus loin). ControlMaster auto avec ControlPersist multiplexe les connexions sur une seule session TCP. La deuxième connexion, puis toutes les suivantes, ssh, scp ou rsync vers le même hôte s’établissent donc instantanément au lieu de renégocier la connexion. La différence devient considérable avec Ansible. Comme scp, rsync et Ansible lisent tous ce même fichier, chaque nom défini ici fonctionne partout.

Le piège est que la connexion maître peut rester active alors qu’elle n’est plus utilisable, et les deux modes de défaillance se présentent différemment. Lorsque le serveur redémarre ou que le Wi-Fi se déconnecte, le processus maître conserve une session TCP interrompue qu’il n’a pas encore détectée. La prochaine ssh web1 reste alors silencieusement bloquée sur un socket qui ne mène nulle part. Par ailleurs, sshd limite à 10 le nombre de sessions par connexion (MaxSessions dans sshd_config). La onzième session multiplexée vers un hôte affiche :

mux_client_request_session: session request failed: Session open refused by peer

Les deux problèmes se résolvent de la même manière : ssh -O exit web1 arrête le processus maître, et la connexion suivante en crée un nouveau. Vous pouvez aussi voir occasionnellement ControlSocket /home/matt/.ssh/cm-matt@10.8.0.11-22 already exists, disabling multiplexing. Ce message est sans conséquence : deux sessions ont été lancées simultanément et la connexion fonctionne toujours, mais sans multiplexage.

Deux outils complémentaires sont utiles à cette échelle. tmux sur chaque serveur remplace nohup, évite de perdre le travail lorsque le Wi-Fi se déconnecte et permet de laisser une migration s’exécuter sans garder l’ordinateur portable ouvert. Coût de configuration : sudo apt install -y tmux, deux minutes, plus l’habitude d’utiliser tmux new -s work et tmux attach -t work. Le piège est l’imbrication : tmux dans tmux intercepte votre touche de préfixe. Exécutez-le donc sur le serveur ou sur l’ordinateur portable, mais pas sur les deux. Si vous exécutez des sessions d’agent de longue durée, ce point est deux fois plus important. Le principe est le même que pour exécuter Claude Code dans tmux sur un VPS : la session doit rester active après la fermeture de la connexion SSH.

Un fichier d’alias partagé évite de retaper vos douze commandes favorites sur chaque machine. Conservez un .bash_aliases dans un dépôt git et récupérez-le sur chaque serveur. Le piège est qu’il diverge dès que vous le modifiez directement sur un serveur au lieu de le modifier dans le dépôt. C’est aussi votre premier aperçu de la raison pour laquelle le niveau suivant existe.

5 à 20 serveurs : la configuration comme code, sinon la dérive gagne

Au-delà de cinq serveurs environ, « je vais simplement le faire sur chaque machine » cesse d’être une méthode et devient un mensonge que vous vous racontez. Les outils de ce niveau s’attaquent tous au même problème : la dérive de configuration.

Ansible remplace la boucle shell sur les noms d’hôtes, la page wiki intitulée « configuration d’un nouveau serveur » qui accuse trois étapes de retard et l’inquiétude de ne pas savoir si web3 a réellement reçu la correction. Coût de mise en place : 30 minutes pour obtenir un premier playbook fonctionnel, sudo apt install -y ansible sur votre ordinateur portable ou une machine d’administration (apt fournit une version plus ancienne d’Ansible, ce qui convient pour tout ce qui suit ; la méthode pipx du tutoriel installe des versions récentes), aucun agent sur les serveurs et une exécution complète via la configuration SSH que vous avez déjà créée. C’est la plus importante amélioration présentée sur cette page. Le parcours complet se trouve dans le tutoriel du premier playbook Ansible ; voici la structure de l’inventaire qui permet son fonctionnement :

[web]
web1 ansible_host=10.8.0.11
web2 ansible_host=10.8.0.12

[db]
db1 ansible_host=10.8.0.21 ansible_port=2222

[all:vars]
ansible_user=matt
ansible_ssh_common_args='-o ProxyJump=bastion'

Comme Ansible exécute le binaire OpenSSH, la ~/.ssh/config que vous avez écrite dans la section précédente s’applique déjà. Un inventaire contenant des noms simples comme web1 fonctionnerait sans aucune variable. Les variables ci-dessus rendent plutôt l’inventaire autonome. C’est utile le jour où vous l’exécutez depuis une machine qui n’est pas votre ordinateur portable.

Testez-le avec ansible all -i inventory.ini -m ping ; un résultat correct affiche "ping": "pong" pour chaque hôte, en vert. La première erreur que vous rencontrerez ressemblera à ceci :

web1 | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: matt@10.8.0.11: Permission denied (publickey).",
    "unreachable": true
}

Ce n’est pas un problème propre à Ansible. Un simple ssh matt@10.8.0.11 échoue de la même manière. Corrigez toujours SSH en premier ; Ansible ne peut être fiable que si la couche sous-jacente l’est aussi. L’autre point à connaître est le suivant : Ansible a besoin de Python sur votre machine et, pour presque tous les modules, y compris ping, sur le serveur également. Une image réellement minimale peut donc répondre /usr/bin/python3: not found. Exécutez une fois apt install python3 et le problème ne se représentera plus. Pour tout un parc d’images minimales, le module raw, l’un des rares qui ne nécessitent pas Python sur la machine distante, peut effectuer cette installation.

unattended-upgrades vous remplace pour l’application des correctifs de sécurité sur N serveurs. Ubuntu Server 24.04 l’installe par défaut et l’active normalement déjà pour les mises à jour de sécurité. Il faut donc ici le vérifier, et non l’installer :

cat /etc/apt/apt.conf.d/20auto-upgrades

Les deux lignes doivent se terminer par "1". Certaines images minimales et certaines images cloud le désactivent. sudo dpkg-reconfigure -plow unattended-upgrades réécrit ce fichier si c’est votre cas. Coût de mise en place : deux minutes de vérification par serveur, ou une tâche Ansible pour l’ensemble du parc. Le point à connaître : par défaut, l’outil ne redémarre jamais la machine. Les mises à jour de sécurité du noyau restent donc partiellement appliquées jusqu’au prochain redémarrage. Le guide dédié à unattended-upgrades explique les redémarrages automatiques, le choix des correctifs à appliquer et la lecture de ses journaux.

La supervision centralisée vous évite de l’apprendre par un client, ce qui constitue le système de supervision le plus coûteux jamais conçu. Deux outils, avec une indication rapide de leur usage : Uptime Kuma répond à la question « le service est-il disponible ? ». Il effectue des vérifications HTTP, TCP et ping, envoie des alertes vers de nombreux services et se déploie en dix minutes avec Docker. Zabbix répond à la question « le service est-il sur le point de tomber en panne ? ». Il suit les tendances du disque, de la mémoire et du CPU grâce à un agent installé sur chaque hôte, et sa mise en place prend honnêtement une après-midi. Commencez par Kuma. Ajoutez Zabbix lorsque les services « disponibles mais dégradés » commencent à vous coûter de l’argent. Le point à connaître pour les deux outils concerne leur emplacement. Il est suffisamment important pour faire l’objet de la section consacrée aux erreurs, plus bas.

Un panneau web, uniquement si nécessaire. Webmin vous évite de retenir où Ubuntu range les différents paramètres. Pour une équipe aux compétences variées ou un serveur auquel vous n’accédez que deux fois par an, il peut réellement être utile. Sa mise en place prend dix minutes. Le point à connaître est qu’il s’agit d’une application web avec des privilèges équivalents à root, à l’écoute sur le port 10000, et qu’Internet le recherche en permanence. Si vous l’utilisez, liez-le à localhost ou à une adresse VPN, jamais à 0.0.0.0 sur une interface publique. Si vous envisagez un panneau parce que SSH vous semble lent, relisez d’abord la section précédente : ~/.ssh/config associé à Ansible est plus rapide que n’importe quel panneau une fois configuré.

20+ serveurs : là où ce guide s’arrête réellement

Au-delà de 20 serveurs, vous gérez une flotte et la toolchain change de nature : Terraform ou OpenTofu pour rendre les serveurs eux-mêmes reproductibles, cloud-init ou des images de référence pour qu’une machine soit remplaçable plutôt que réparable, une configuration pull-based ou des pipelines CI qui exécutent Ansible, car le push depuis un laptop ne passe plus à l’échelle, et une véritable gestion des secrets. Ansible lui-même ne s’effondre pas à 20 serveurs ; de nombreuses entreprises l’utilisent avec des centaines de nœuds. En revanche, les pratiques qui l’entourent doivent être renforcées, et cela relève d’un autre type d’article que ceux publiés sur ce site. Si vous êtes à cette échelle, la section ci-dessous vous concerne toujours, car les principes de gestion de l’inventaire, des clés et des accès sont précisément les éléments que les outils de gestion de flotte supposent déjà en place.

La couche que personne ne documente

Quatre pratiques s’appliquent quelle que soit la taille du parc. Les négliger explique pourquoi le nombre de serveurs semble plus difficile à gérer qu’il ne l’est réellement.

Un fichier d’inventaire, même un fichier texte. Dès que vous avez trois serveurs, notez leur nom, leur IP, leur fournisseur, ce qui y tourne et leur raison d’être. Un servers.md dans un dépôt git convient ; l’inventaire Ansible présenté plus haut est préférable, car il constitue une documentation exécutable. Ce qu’il remplace : la question posée à 2 heures du matin : « Attendez, qu’est-ce que 10.0.0.40 ? » Coût de mise en place : dix minutes. Le piège : cela ne fonctionne que si la création d’un serveur et l’ajout de la ligne sont le même acte, jamais deux opérations distinctes.

Hygiène des clés : rotation dès maintenant, CA SSH quand cela devient nécessaire. Recensez les emplacements de vos clés (cat ~/.ssh/*.pub de votre côté, ~/.ssh/authorized_keys du côté de chaque serveur), supprimez les anciens ordinateurs portables et les anciens collaborateurs, puis renouvelez toute clé suffisamment ancienne pour que vous ne puissiez plus dire où elle a été utilisée. Une autorité de certification SSH, avec des certificats signés à courte durée de vie à la place de clés statiques, constitue la solution adaptée à grande échelle. Mais soyons honnêtes : sous dix serveurs, une gestion rigoureuse de authorized_keys avec Ansible vous apporte 90% du bénéfice pour 10% de la complexité administrative.

Un seul point d’accès, pas vingt. Chaque port SSH public augmente la surface d’attaque, multipliée par N. Le modèle qui passe à l’échelle consiste à utiliser un bastion, ou mieux, un VPN WireGuard sur un VPS que vous contrôlez, et à lier le SSH de tous les autres serveurs uniquement à leur adresse privée. Les lignes ProxyJump de la configuration ci-dessus partent déjà de ce principe. Tout ce qui doit rester public doit systématiquement être protégé par fail2ban. Coût de mise en place : une heure, une seule fois. Le piège : vérifiez que votre solution de secours (l’accès à la console du fournisseur) fonctionne avant de fermer le port 22 partout, pas après.

Des sauvegardes testées par une restauration. Une sauvegarde non testée n’est qu’une hypothèse. Quel que soit le mécanisme utilisé — snapshots du fournisseur, restic, rsync vers un second serveur — l’outil qui compte réellement est l’entrée du calendrier qui vous impose de restaurer un serveur sur un VPS vierge et de vérifier qu’il démarre et fournit bien ses services. Toutes les histoires de catastrophe liées aux sauvegardes que j’ai entendues en quinze ans d’hébergement contiennent la phrase « nous avions des sauvegardes ».

Les erreurs

À l’échelle de plusieurs serveurs, les problèmes ne viennent pas des outils, mais des habitudes. Quatre erreurs expliquent presque tous les incidents.

Serveurs flocons. Chaque machine a été configurée manuellement, présente de petites différences et ne peut être reconstruite par personne. Vous vous en rendez compte lors d’une panne de disque. La solution est peu spectaculaire : chaque modification passe par Ansible ou, au minimum, est ajoutée à la section de cette machine dans le document d’inventaire. Tout serveur que vous ne pourriez pas reconstruire à partir de vos notes cet après-midi constitue une dette technique avec une échéance que vous ne choisissez pas.

Règles de pare-feu « temporaires ». Vous ajoutez ufw allow 5432 pour diagnostiquer un problème, puis, dix-huit mois plus tard, Postgres est toujours exposé à Internet. Auditez chaque machine avec sudo ufw status numbered ou, en une seule commande, avec ansible all -i inventory.ini -a "ufw status numbered" --become, puis supprimez toute règle dont vous ne pouvez pas justifier l’utilité actuelle. Si une règle est réellement temporaire, la commande ufw delete correspondante est ajoutée dans la même fenêtre tmux avant de la fermer.

Supervision hébergée sur une machine supervisée. Si Uptime Kuma s’exécute sur le serveur qu’il surveille, l’alerte indiquant que « tout est hors service » l’est également. Vous avez créé une version plus petite et plus absurde de l’datacenter le moins efficace au monde. La supervision doit se trouver dans un domaine de panne différent : un VPS peu coûteux chez un autre fournisseur est la solution classique. À défaut, utilisez au minimum un contrôle externe gratuit qui surveille le système de supervision.

SSH root partout. Une seule clé root partagée sur l’ensemble du parc signifie qu’un ordinateur portable compromis donne accès à tout, sans piste d’audit permettant de savoir qui a fait quoi. Utilisez des comptes individuels, sudo et PermitRootLogin no dans /etc/ssh/sshd_config sur chaque hôte. Là encore, cela tient dans une tâche Ansible de trois lignes au lieu d’une soirée de saisie manuelle.

Lorsque le parc dépasse quelques machines, votre premier playbook Ansible automatise les tâches répétitives.

FAQ

Quel est le meilleur outil gratuit pour gérer plusieurs serveurs Linux ?

Pour 2 à 5 serveurs, un ~/.ssh/config bien écrit et tmux sont plus efficaces que n’importe quel outil que vous pourriez installer. À partir d’environ cinq serveurs, Ansible est la réponse standard : sans agent, gratuit, il fonctionne via SSH, que vous avez déjà, et transforme la configuration des serveurs en fichiers versionnés dans git. Ajoutez Uptime Kuma pour les alertes de disponibilité ; tous les outils cités dans ce guide sont des logiciels libres.

Puis-je gérer plusieurs serveurs Linux sans Ansible ?

Oui. En dessous d’environ cinq serveurs, une bonne configuration SSH, un fichier d’alias partagé et de la rigueur suffisent, et beaucoup d’administrateurs fonctionnent ainsi pendant des années. Au-delà, l’alternative à Ansible n’est pas « rien », mais la dérive de configuration non documentée : dix-huit serveurs configurés manuellement de manière légèrement différente. Si Ansible vous semble trop lourd, commencez par un playbook qui ne gère que authorized_keys et unattended-upgrades ; cela suffit à rentabiliser le temps d’apprentissage.

Comment exécuter la même commande simultanément sur plusieurs serveurs Linux ?

ansible all -i inventory.ini -a "uptime" est la solution propre et ne nécessite aucun playbook, seulement le fichier d’inventaire. Pour travailler interactivement côte à côte, tmux peut diffuser les frappes sur chaque panneau avec setw synchronize-panes on. Considérez toutefois cette fonction comme un gadget : diffuser des commandes interactives sur des serveurs de production est le meilleur moyen qu’une faute de frappe provoque une panne multipliée par le nombre de serveurs.

Ai-je besoin d’un panneau de contrôle comme Webmin pour gérer des serveurs Linux ?

Non. Tout ce qu’un panneau peut faire, SSH et Ansible le font de manière plus reproductible. Webmin se justifie lorsque des personnes de niveaux différents administrent les mêmes serveurs, ou lorsque vous intervenez assez rarement sur un serveur pour que retrouver les chemins de configuration prenne un temps réel. Si vous en utilisez un, traitez-le comme l’application web avec des privilèges équivalents à root qu’il est : liez-le à localhost ou à une adresse VPN, jamais à une interface publique.

Combien de serveurs Linux une seule personne peut-elle gérer de manière réaliste ?

Avec une administration manuelle, la qualité commence à se dégrader avant dix serveurs. Avec la configuration as code, l’application automatisée des correctifs et la supervision centralisée, une personne rigoureuse peut gérer 20 à 50 serveurs à temps partiel. La contrainte devient alors la fréquence des incidents inhabituels, et non la maintenance courante. Le nombre important n’est pas le nombre de serveurs par administrateur, mais le nombre de serveurs configurés comme des cas particuliers par administrateur : maintenez-le proche de zéro et la limite reste élevée.