Gérer plusieurs serveurs Linux : quels outils choisir ?

Ce que vous allez mettre en place

Il ne s’agit pas d’un outil unique, mais d’une courte stack choisie selon le nombre réel de serveurs que vous gérez. Ce nombre est le seul paramètre qui compte, et c’est précisément celui qu’ignorent les comparatifs d’outils d’administration de serveurs Linux. L’erreur classique consiste à adopter une solution prévue pour 200 serveurs afin d’en gérer quatre VPS, puis à passer un mois à alimenter l’outil au lieu d’administrer les serveurs. L’autre erreur classique consiste, avec dix-huit serveurs, à continuer de se connecter en SSH à chacun d’eux manuellement et à 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. Il couvre également la couche transversale qui s’applique à toutes les tailles et que personne ne documente : un inventaire, une bonne gestion des clés, un point d’entrée 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ôte VPS depuis quinze ans. La liste ci-dessous correspond à ce qui tient face à une panne à 2 heures du matin, pas à ce qui donne une bonne démonstration.

Prérequis et limites à connaître

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

Deux avertissements importants avant de présenter les outils. Premièrement, la multiplication des outils devient elle-même un problème d’administration. Chaque agent installé ajoute un daemon à mettre à jour sur chaque serveur. Le critère d’ajout devrait donc être « cet outil remplace une tâche manuelle effectuée cette semaine », et non « cet outil semble utile ». Deuxièmement, tous les outils présentés ici sont des logiciels libres. Leur coût réel est 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 est 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 dans l’historique du 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 d’un logiciel supplémentaire. Vous devez configurer le client dont vous disposez déjà comme il se doit. ~/.ssh/config transforme chaque serveur en un nom d’un seul mot et encode le routage afin 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é passe de manière transparente par bastion, sans agent forwarding ni incantations ProxyCommand. Les serveurs privés n’ont même pas besoin d’exposer de ports SSH publics (voir la section transversale). Avec ControlMaster auto et ControlPersist, les connexions sont multiplexées sur une seule session TCP. Le deuxième ssh, puis tous les suivants, scp ou rsync vers le même hôte se connectent 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 que vous y définissez fonctionne partout.

Le piège est que la connexion maître peut rester active alors qu’elle n’est plus utilisable. Les deux modes de défaillance sont différents. Lorsque le serveur redémarre ou que votre Wi-Fi se déconnecte, le processus maître conserve une session TCP morte qu’il n’a pas encore détectée. Le ssh web1 suivant reste alors bloqué silencieusement sur une 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

La solution est la même dans les deux cas : ssh -O exit web1 arrête le processus maître, puis la connexion suivante en démarre un nouveau. Vous pouvez aussi voir occasionnellement ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing. Ce message est sans conséquence : deux sessions ont été ouvertes en concurrence et la connexion fonctionne malgré tout, simplement 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 vous évite de vous dire : « Je ne peux pas fermer mon ordinateur portable, une migration est en cours. » 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 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 encore plus important. Le principe est le même que pour exécuter Claude Code dans tmux sur un VPS : la session doit rester active au-delà de la connexion SSH.

Un fichier d’alias partagé vous é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 première indication de l’intérêt du niveau suivant.

5 à 20 serveurs : la configuration comme code, sinon la dérive l’emporte

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 a trois étapes de retard et l’inquiétude de ne pas savoir si web3 a réellement reçu le correctif. 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 vous fournit une version plus ancienne d’Ansible, ce qui convient pour tout ce qui suit ; la méthode pipx du tutoriel installe les versions actuelles), aucun agent sur les serveurs, et tout fonctionne avec la configuration SSH que vous avez déjà préparée. C’est la plus importante amélioration présentée sur cette page, et la procédure complète se trouve dans le tutoriel du premier playbook Ansible ; voici la structure de l’inventaire qui permet de l’utiliser :

[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 appelle le binaire OpenSSH, la ~/.ssh/config que vous avez écrite dans la section précédente s’applique déjà. Un inventaire contenant de simples noms comme web1 fonctionnerait donc sans aucune variable. Les variables ci-dessus rendent toutefois l’inventaire autonome, ce qui devient 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 : `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. Le seul autre point à connaître est qu’Ansible a besoin de Python aux deux extrémités. Une image réellement minimale peut donc répondre /usr/bin/python3: not found, puis apt install python3` une seule fois, et le problème ne se reproduira plus.

unattended-upgrades vous remplace pour appliquer les correctifs de sécurité aux 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 vérifier son état, pas l’installer :

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

Les deux lignes doivent se terminer par "1". Certaines images minimales ou cloud le désactivent, et sudo dpkg-reconfigure -plow unattended-upgrades réécrit ce fichier si nécessaire. Coût de mise en place : deux minutes de vérification par serveur, ou une tâche Ansible pour tous les serveurs. Le point à connaître est qu’il ne redémarre jamais le serveur par défaut. Les mises à jour de sécurité du kernel restent donc partiellement appliquées jusqu’au prochain redémarrage. Le guide dédié à unattended-upgrades explique les redémarrages automatiques, le choix des mises à jour à 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, une ligne chacun pour préciser quand les utiliser : Uptime Kuma répond à la question « le service est-il disponible ? » avec des checks HTTP, TCP et ping, des alertes vers n’importe quelle destination et une installation Docker en dix minutes ; Zabbix répond à la question « est-il sur le point de tomber en panne ? » grâce aux tendances du disque, de la mémoire et du CPU, via un agent sur chaque hôte, mais demande 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. Pour les deux outils, le point critique concerne leur emplacement. Il est suffisamment important pour introduire la section suivante consacrée aux erreurs.

Un panneau web, uniquement si nécessaire. Webmin vous évite de retenir où Ubuntu stocke ses fichiers. Pour une équipe aux compétences variées ou un serveur auquel vous ne touchez que deux fois par an, il est réellement utile ; sa mise en place prend dix minutes. Le problème est qu’il s’agit d’une application web avec des privilèges équivalents à ceux de root, en écoute sur le port 10000, et qu’Internet la scanne constamment. Si vous l’utilisez, liez-le à localhost ou à l’adresse d’un VPN, jamais à 0.0.0.0 sur une interface publique. Et si vous cherchez 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 : où ce guide s’arrête honnêtement

Au-delà de 20 serveurs, vous gérez un parc et la toolchain change de nature : Terraform ou OpenTofu pour rendre les serveurs eux-mêmes reproductibles, cloud-init ou des golden images pour qu’une machine soit remplaçable plutôt que réparable, une configuration pull-based ou des pipelines CI qui exécutent votre Ansible, car le push depuis un laptop ne passe plus à l’échelle, ainsi qu’une véritable gestion des secrets. Ansible lui-même ne s’effondre pas à 20 serveurs ; de nombreuses entreprises l’utilisent sur des centaines de nœuds. En revanche, les pratiques qui l’entourent doivent être renforcées, et cela relève d’un autre article que ceux publiés sur ce site. Si vous avez atteint cette échelle, la section ci-dessous vous concerne toujours, car l’inventaire, les clés et la discipline d’accès sont précisément les éléments que les outils de gestion de parc 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 simple fichier texte. Dès que vous avez trois serveurs, notez leur nom, leur adresse IP, leur fournisseur, ce qui y fonctionne et la raison de leur existence. 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. Il remplace la question posée à 2 heures du matin : « Attendez, qu’est-ce que 10.0.0.40 ? » 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 une seule et même action, jamais deux actions distinctes.

Hygiène des clés : rotation dès maintenant, CA SSH lorsque 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 effectuez une rotation de toute clé assez 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, en toute honnêteté, en dessous de 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, puis à faire écouter le service SSH de tous les autres serveurs uniquement sur leur adresse privée. Les lignes ProxyJump de la configuration ci-dessus partent déjà de ce principe. Tout service qui doit rester public doit systématiquement être protégé par fail2ban. 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 qui n’a jamais été testée est une hypothèse. Quel que soit le mécanisme utilisé — snapshots du fournisseur, restic, rsync vers un second serveur — l’outil réellement important est l’événement planifié dans le calendrier, au cours duquel vous restaurez un serveur sur un VPS neuf et vérifiez qu’il démarre et fournit 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 viennent rarement des outils. Ils viennent des habitudes. Quatre erreurs expliquent presque tous les cas.

Serveurs « flocons de neige ». Chaque machine a été configurée manuellement, diffère légèrement des autres et personne ne peut la reconstruire. Vous le découvrez lors d’une panne de disque. La solution est peu intéressante, mais efficace : chaque modification passe par Ansible ou, au minimum, est ajoutée à la section de ce serveur dans le document d’inventaire. Tout serveur que vous ne pourriez pas reconstruire à partir de vos notes cet après-midi est une dette technique dont l’échéance ne dépend pas de vous.

Règles de pare-feu « temporaires ». ufw allow 5432 pour résoudre un problème, puis, dix-huit mois plus tard, Postgres est toujours exposé sur 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 doit être ajoutée dans la même fenêtre tmux avant que vous la fermiez.

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 indisponible » l’est aussi. Vous avez construit une version réduite et encore moins efficace du centre de données le moins efficace au monde. La supervision doit se trouver dans un autre domaine de panne : un VPS peu coûteux chez un autre fournisseur est la solution classique. À défaut, utilisez un contrôle externe gratuit qui surveille le système de supervision.

SSH root partout. Une seule clé root partagée sur toute la flotte signifie qu’un seul ordinateur portable compromis donne accès à tout, sans laisser de trace 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 plutôt que dans une soirée de saisie manuelle.

Lorsque la flotte dépasse quelques serveurs, 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 avec tmux est plus efficace que n’importe quel outil que vous pourriez installer. À partir d’environ cinq serveurs, Ansible est la réponse standard : il ne nécessite aucun agent, il est gratuit, il utilise SSH, que vous avez déjà, et il 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 discipline suffisent. Beaucoup d’administrateurs fonctionnent ainsi pendant des années. Au-delà, l’alternative à Ansible n’est pas « rien », mais une dérive de configuration non documentée : dix-huit serveurs configurés manuellement, chacun avec de légères différences. Si Ansible vous semble trop lourd, commencez par un playbook qui gère uniquement authorized_keys et unattended-upgrades ; cela suffit à rentabiliser le temps d’apprentissage.

Comment exécuter simultanément la même commande 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 de manière interactive côte à côte, tmux peut diffuser les frappes sur tous les panneaux avec setw synchronize-panes on. Considérez toutefois cette fonction comme un gadget : diffuser des commandes interactives vers des serveurs de production transforme une simple faute de frappe en panne multipliée par N.

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 est utile 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 réellement du temps. Si vous en utilisez un, traitez-le comme l’application web équivalente à 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 raisonnablement ?

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