Gérer plusieurs serveurs Linux : les bons outils

Ce que vous construisez

Pas un seul outil, mais une petite pile d'outils, choisie selon le nombre de serveurs que vous avez réellement. Ce nombre est la seule donnée qui compte, et c'est celle que chaque comparatif d'« outils de gestion de serveurs Linux » ignore. L'erreur classique consiste à adopter une réponse pensée pour 200 serveurs alors que vous en avez quatre, et à passer un mois à nourrir l'outil au lieu des serveurs. La deuxième erreur classique, c'est la personne qui, avec dix-huit serveurs, se connecte encore en SSH à chacun à la main et applique « le même » changement de dix-huit façons légèrement différentes.

Ce guide est donc organisé par taille de parc : 2 à 5 serveurs, 5 à 20, et au-delà de 20. S'y ajoute la couche transversale qui s'applique à toutes les tailles et que personne ne note jamais : un inventaire, une bonne hygiène des clés, une seule porte d'entrée, et des sauvegardes que vous avez réellement restaurées. Pour chaque outil, vous obtenez trois choses : ce qu'il remplace, le temps d'installation en minutes, et le seul piège qui fait vraiment mal. J'exploite un hébergeur VPS depuis quinze ans ; la liste ci-dessous est ce qui survit à une panne à 2 h du matin, pas ce qui fait joli en démonstration.

Prérequis et pièges honnêtes

Il vous faut un SSH par clé qui fonctionne déjà vers chaque serveur (si vous tapez encore des mots de passe, corrigez cela d'abord : c'est dix minutes et tout ce qui suit suppose des clés), un utilisateur sudo qui n'est pas root, et des serveurs qui font tourner quelque chose de récent. Les commandes ici supposent Ubuntu 24.04, mais rien n'est spécifique à Ubuntu sauf apt.

Deux avertissements honnêtes avant les outils. Premièrement, la prolifération d'outils est elle-même un problème de gestion : chaque agent que vous installez est un démon de plus à mettre à jour sur chaque machine, donc le critère pour en ajouter un devrait être « ceci remplace un travail manuel que j'ai fait cette semaine », pas « ceci a l'air utile ». Deuxièmement, tout ici est un logiciel libre et le vrai coût est le temps d'installation, c'est pourquoi chaque outil porte une estimation en minutes : là où l'estimation dit une après-midi, croyez-la.

2 à 5 serveurs : ~/.ssh/config est l'outil le plus sous-estimé que vous avez déjà

Ce qu'il remplace : le fichier texte d'adresses IP, l'archéologie de l'historique du shell (ssh 203.0 puis Ctrl-R en priant), et taper -p 2222 -i ~/.ssh/other_key pour toujours. Temps d'installation : 15 minutes, une seule fois. Le piège : des sockets de multiplexage périmés, traités plus bas.

À cette taille, vous n'avez pas besoin de logiciel ; vous avez besoin du client que vous avez déjà, configuré sérieusement. ~/.ssh/config transforme chaque serveur en un nom d'un seul mot et encode le routage pour que vous n'y pensiez plus jamais :

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 réglages font le travail. ProxyJump route les connexions à travers un bastion en un seul saut, si bien que ssh db1 depuis un café passe de façon transparente par bastion : pas de transfert d'agent, pas d'incantations ProxyCommand, et les serveurs privés n'ont jamais besoin de ports SSH publics du tout (plus de détails dans la section transversale). ControlMaster auto avec ControlPersist multiplexe les connexions sur une seule session TCP, si bien que le deuxième ssh, scp ou rsync vers le même hôte, et tous les suivants, se connectent instantanément au lieu de renégocier : une différence qui devient spectaculaire quand Ansible entre en scène. Et comme scp, rsync et Ansible lisent tous ce même fichier, chaque nom que vous définissez ici fonctionne partout.

Le piège : la connexion maître peut survivre à son utilité, et les deux modes de défaillance se ressemblent peu. Quand le serveur redémarre ou que votre Wi-Fi tombe, le processus maître se retrouve à tenir une session TCP morte qu'il n'a pas encore remarquée, et le prochain ssh web1 se bloque silencieusement sur un socket qui ne mène nulle part. Par ailleurs, sshd limite les sessions par connexion à 10 (MaxSessions dans sshd_config), donc la onzième session multiplexée vers un même hôte affiche :

mux_client_request_session: session request failed: Session open refused

Les deux ont le même remède : ssh -O exit web1 tue le maître, et la connexion suivante en démarre un neuf. Vous verrez peut-être aussi de temps en temps ControlSocket ~/.ssh/cm-matt@web1-22 already exists, disabling multiplexing : celui-là est inoffensif, deux sessions se sont télescopées et la connexion fonctionne toujours, simplement sans multiplexage.

Deux compagnons à cette taille. tmux sur chaque serveur remplace nohup, le travail perdu quand le Wi-Fi tombe, et « je ne peux pas fermer mon portable, une migration est en cours ». Temps d'installation : sudo apt install -y tmux, deux minutes, plus la mémoire musculaire de tmux new -s work et tmux attach -t work. Le piège, c'est l'imbrication : tmux dans tmux avale votre touche de préfixe, alors lancez-le sur le serveur ou sur le portable, pas sur les deux. Si vous faites tourner des sessions d'agent de longue durée, cela compte doublement : c'est le même schéma que faire tourner Claude Code dans tmux sur un VPS, où la session doit survivre à la connexion SSH.

Un fichier d'alias partagé remplace le fait de retaper vos douze commandes fétiches sur chaque machine. Gardez un .bash_aliases dans un dépôt git et récupérez-le sur chaque serveur. Le piège : il se met à diverger dès l'instant où vous le modifiez directement sur un serveur au lieu du dépôt, ce qui vous donne aussi un premier avant-goût de la raison d'être du palier suivant.

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

Quelque part au-delà de cinq serveurs, « je vais juste le faire sur chaque machine » cesse d'être une méthode et devient un mensonge que vous vous racontez. Les outils de ce palier attaquent tous le même ennemi : la dérive.

Ansible remplace la boucle shell sur les noms d'hôtes, la page wiki intitulée « installation d'un nouveau serveur » qui a trois étapes de retard, et l'angoisse de ne pas savoir si web3 a vraiment reçu le correctif. Temps d'installation : 30 minutes pour un premier playbook qui fonctionne, sudo apt install -y ansible sur votre portable ou une machine de gestion (apt vous donne une version plus ancienne d'Ansible, ce qui convient à tout ce qui est ici ; la voie pipx du tutoriel vous donne les versions actuelles), aucun agent sur les serveurs, tout tournant par-dessus la configuration SSH que vous avez déjà construite. C'est la plus grosse amélioration à elle seule de cette page, et le guide complet se trouve dans le tutoriel du premier playbook Ansible ; voici la forme de l'inventaire qui le fait fonctionner :

[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 délègue au binaire OpenSSH, le ~/.ssh/config que vous avez écrit dans la section précédente s'applique déjà : un inventaire de noms nus comme web1 fonctionnerait sans aucune variable. Les variables ci-dessus rendent plutôt l'inventaire autonome, ce qui paie le jour où vous le lancez depuis une machine qui n'est pas votre 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 défaillance que vous rencontrerez ressemble à 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 Ansible : un simple ssh matt@10.8.0.11 échoue de la même manière. Corrigez d'abord le SSH, toujours ; Ansible n'est jamais en meilleure santé que la couche en dessous. Le seul piège au-delà de ça : Ansible a besoin de Python aux deux bouts, donc une image vraiment minimale peut répondre /usr/bin/python3: not found, un seul apt install python3 et il ne vous embête plus jamais.

unattended-upgrades vous remplace en tant que personne qui applique les correctifs de sécurité à N serveurs. Ubuntu Server 24.04 d'origine le livre préinstallé et normalement déjà activé pour les mises à jour de sécurité, donc le travail ici est de vérifier, pas d'installer :

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

Les deux lignes doivent se terminer par "1". Certaines images minimales et cloud le livrent désactivé, et sudo dpkg-reconfigure -plow unattended-upgrades réécrit ce fichier si c'était le cas de la vôtre. Temps d'installation : deux minutes de vérification par serveur, ou une seule tâche Ansible pour tous. Le piège : par défaut il ne redémarre jamais, donc les mises à jour de sécurité du noyau restent à moitié appliquées jusqu'à ce que vous le fassiez : le guide dédié à unattended-upgrades couvre les redémarrages automatiques, le choix de ce qui est corrigé, et la lecture de ses journaux.

La supervision centralisée remplace le fait de l'apprendre par un client, ce qui est le système de supervision le plus coûteux jamais conçu. Deux outils, une ligne chacun sur le moment : Uptime Kuma répond à « est-ce en ligne ? », des vérifications HTTP, TCP et ping avec des alertes vers n'importe quoi, et prend dix minutes dans Docker ; Zabbix répond à « est-ce sur le point de s'écrouler ? », des tendances de disque, de mémoire et de CPU via un agent sur chaque hôte, et prend honnêtement une après-midi. Commencez par Kuma ; ajoutez Zabbix quand « en ligne mais dégradé » commence à vous coûter de l'argent. Le piège des deux, c'est le placement, et c'est assez important pour ouvrir la section des erreurs ci-dessous.

Un panneau web, seulement s'il le faut vraiment. Webmin remplace le fait de se souvenir où Ubuntu range les choses, et pour une équipe aux compétences variées ou un serveur que vous touchez deux fois par an, il est légitimement utile ; l'installation prend dix minutes. Le piège, c'est qu'il s'agit d'une application web équivalente à root qui écoute sur le port 10000, et internet la scanne en permanence. Si vous l'utilisez, liez-le à localhost ou à une adresse de VPN, jamais à 0.0.0.0 sur une interface publique. Et si vous vous tournez vers un panneau parce que le SSH vous paraît lent, relisez d'abord la section précédente ; ~/.ssh/config plus Ansible est plus rapide que n'importe quel panneau une fois configuré.

Plus de 20 serveurs : là où ce guide s'arrête honnêtement

Au-delà de vingt serveurs, vous exploitez un parc, et la chaîne d'outils change de forme : Terraform ou OpenTofu pour que les serveurs eux-mêmes soient reproductibles, cloud-init ou des images de référence pour qu'une machine soit jetable plutôt que réparable, une configuration en mode pull ou des pipelines CI qui lancent votre Ansible parce que pousser depuis un portable cesse de passer à l'échelle, et une vraie gestion des secrets. Ansible lui-même ne s'effondre pas à vingt, beaucoup d'entreprises l'utilisent contre des centaines de nœuds, mais les pratiques autour de lui doivent se durcir, et c'est un autre article que celui que ce site écrit. Si vous êtes à cette échelle, la section ci-dessous est quand même pour vous, parce que l'inventaire, les clés et la discipline d'accès sont exactement les choses que l'outillage de parc suppose que vous avez déjà.

La couche que personne ne note

Quatre pratiques s'appliquent à toute taille de parc, et les négliger explique pourquoi le nombre de serveurs pèse plus lourd qu'il ne le devrait.

Un fichier d'inventaire, même un simple fichier texte. Dès l'instant où vous avez trois serveurs, notez : le nom, l'IP, le fournisseur, ce qui tourne dessus, et pourquoi il existe. Un servers.md dans un dépôt git convient ; l'inventaire Ansible ci-dessus est meilleur parce que c'est de la documentation exécutable. Ce qu'il remplace : la question à 2 h du matin « attends, c'est quoi 10.0.0.40 ? ». Temps d'installation : dix minutes. Le piège : cela ne fonctionne que si créer un serveur et ajouter la ligne sont un seul et même geste, jamais deux.

Hygiène des clés : rotation maintenant, une autorité de certification (AC) SSH quand ça fait mal. Recensez où vivent vos clés (cat ~/.ssh/*.pub de votre côté, ~/.ssh/authorized_keys du côté de chaque serveur), retirez les ex-portables et les ex-collègues, et faites tourner tout ce qui est assez vieux pour que vous ne puissiez pas dire où il est passé. Une AC SSH, des certificats signés à courte durée de vie au lieu de clés statiques, est la réponse mature, mais le conseil honnête est qu'en dessous de dix serveurs, une gestion disciplinée des authorized_keys via Ansible vous apporte 90 % du bénéfice pour 10 % du cérémonial.

Une seule porte d'entrée, pas vingt. Chaque port SSH public est une surface d'attaque multipliée par N. Le schéma qui passe à l'échelle : un seul hôte bastion, ou mieux, un VPN WireGuard sur un VPS que vous contrôlez, et le SSH de tous les autres serveurs lié à leur seule adresse privée. Les lignes ProxyJump dans la configuration ci-dessus supposent déjà cette forme. Tout ce qui doit rester public reçoit fail2ban par principe. Temps d'installation : 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 en restaurant. Une sauvegarde non testée est une hypothèse. Quel que soit le mécanisme que vous utilisez, instantanés du fournisseur, restic, rsync vers une deuxième machine, l'outil qui compte vraiment est l'entrée d'agenda où vous restaurez un serveur sur un VPS tout neuf et confirmez qu'il démarre et qu'il sert. Chaque histoire d'horreur de sauvegarde que j'ai entendue en quinze ans d'hébergement contient la phrase « on avait des sauvegardes ».

Les erreurs

Les modes de défaillance à l'échelle de plusieurs serveurs ne sont pas des défaillances d'outils ; ce sont des habitudes. Quatre d'entre elles expliquent presque tout.

Les serveurs uniques (« flocons de neige »). Chaque machine a été configurée à la main, est subtilement différente, et personne ne sait la reconstruire. Vous l'apprenez lors d'une panne de disque. Le remède est ennuyeux : chaque changement passe par Ansible, ou au minimum est ajouté à la section de ce serveur dans le document d'inventaire, et tout serveur que vous ne pourriez pas reconstruire à partir de vos notes cet après-midi est une dette technique avec une échéance que vous ne choisirez pas.

Les trous « temporaires » dans le pare-feu. ufw allow 5432 pour déboguer quelque chose, et dix-huit mois plus tard Postgres est toujours sur internet. Auditez avec sudo ufw status numbered sur chaque machine, ou en une seule fois, ansible all -i inventory.ini -a "ufw status numbered" --become, et supprimez tout ce dont vous ne pouvez pas nommer une raison actuelle. Si une règle est vraiment temporaire, le ufw delete correspondant part dans la même fenêtre tmux avant que vous ne la fermiez.

La supervision hébergée sur une machine supervisée. Si Uptime Kuma tourne sur le serveur qu'il surveille, l'alerte qui dit « tout est en panne » est en panne elle aussi : vous avez construit une version plus petite et plus drôle du centre de données le moins efficace du monde. La supervision vit dans un domaine de défaillance différent : un VPS bon marché chez un autre fournisseur est la réponse classique, ou au minimum une vérification externe en offre gratuite qui surveille le surveillant.

Le SSH root partout. Une seule clé root partagée sur tout le parc signifie qu'un seul portable qui fuit possède tout, et aucune piste d'audit ne dit qui a fait quoi. Des utilisateurs par personne, sudo, et PermitRootLogin no dans /etc/ssh/sshd_config sur chaque hôte, ce qui est, une fois de plus, une tâche Ansible de trois lignes au lieu d'une soirée à taper au clavier.

Quand le parc dépasse une poignée, votre premier playbook Ansible automatise les parties 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 plus tmux bat tout ce que vous pourriez installer. À partir d'environ cinq serveurs, Ansible est la réponse standard : sans agent, gratuit, tourne par-dessus le SSH que vous avez déjà, et transforme l'installation d'un serveur en fichiers dans git. Ajoutez Uptime Kuma pour les alertes en ligne/hors ligne ; chaque outil nommé dans ce guide est un logiciel libre.

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, et beaucoup de gens fonctionnent ainsi pendant des années. Au-delà, l'alternative à Ansible n'est pas « rien », c'est une dérive non documentée : dix-huit serveurs chacun configuré un peu différemment à la main. Si Ansible vous paraît lourd, commencez par un seul playbook qui ne gère que les authorized_keys et unattended-upgrades ; cela seul rembourse la courbe d'apprentissage.

Comment lancer la même commande sur plusieurs serveurs Linux à la fois ?

ansible all -i inventory.ini -a "uptime" est la réponse propre et ne demande aucun playbook, juste le fichier d'inventaire. Pour du travail interactif côte à côte, tmux peut diffuser les frappes vers chaque volet avec setw synchronize-panes on, mais considérez cela comme un tour de passe-passe, car diffuser des commandes interactives vers des serveurs de production, c'est ainsi qu'une faute de frappe devient une panne multipliée par N.

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

Besoin, non : tout ce que fait un panneau, SSH et Ansible le font de façon plus reproductible. Webmin gagne sa place quand des personnes de niveaux variés administrent les mêmes machines, ou quand vous touchez un serveur assez rarement pour que redécouvrir les chemins de configuration coûte un temps réel. Si vous en utilisez un, traitez-le comme l'application web équivalente à root qu'il est : liez-le à localhost ou à une adresse de VPN, jamais à une interface publique.

Combien de serveurs Linux une seule personne peut-elle réalistement gérer ?

Avec une administration à la main, la qualité se dégrade quelque part en dessous de dix. Avec la configuration comme code, les correctifs automatisés et la supervision centralisée, une personne soigneuse peut faire tourner 20 à 50 serveurs à temps partiel : la contrainte devient la fréquence à laquelle quelque chose de nouveau casse, pas l'entretien de routine. Le nombre qui compte n'est pas le nombre de serveurs par administrateur mais le nombre de flocons de neige par administrateur : gardez-le proche de zéro et le plafond est élevé.