Serveurs Linux : comment tenir son parc à jour comme un vrai pro

Chez LRob, nous priorisons trois objectifs : sécurité, disponibilité, performance. Et pour cela, notre politique de mise à jour est volontairement simple, lisible, répétable… Et surtout fréquente.

Nous sommes convaincus que des serveurs à jour protègent des attaques et permettent une infrastructure plus pérenne.
Chez LRob, on n’y va pas par quatre chemins, tant dans la pratique que dans l’explication. Alors accrochez-vous et découvrez comment nous maintenons un parc de serveurs Linux propre et sans surprise.

⚠️ Attention : Cet article est notre exemple, notre avis, et non pas une vérité absolue ou un guide à calquer aveuglément sur toute entreprise. Chaque entreprise est différente, vos choix vous appartiennent et LRob ne saurait être tenu pour responsable des conséquences de vos choix. Aussi, certaines affirmations peuvent être difficiles à supporter en cas de dissonance cognitive – nous espérons que cela ne sera pas trop difficile à endurer.

Pré-requis : de bons choix en amont pour une maintenance optimale

Choisir une distribution Linux pérenne : Debian

Soyons clairs : une politique de mise à jour sur un OS mal choisi ne sert à rien. L’OS doit être le plus stable et prévisible possible, et notamment lors de l’application des mises à jour. Alors choisissez bien.

Notre choix ne fera pas l’unanimité, mais est sans conteste une valeur sûre. Nous pensons que c’est la distribution la plus sûre de toutes : Nous standardisons nos serveurs sur Debian.

Pourquoi ? Pour sa simplicité, sa stabilité, sa prévisibilité et sa gouvernance communautaire. Debian est un socle sobre, qui a su se montrer fiable sur le long terme. Debian permet également l’upgrade de version majeure de distribution, ce qui peut être utile, bien que nous préférions la réinstallation sur un serveur « frais » et plus récent et puissant. Chez LRob, les versions majeures sont vues comme une occasion de mettre le parc à jour.

Nous pensons que Debian est bien plus fiable pour la production que ses « forks » (dérivés) comme Ubuntu dont la politique nous semble moins stable (de même que les dernières versions des paquets souvent proposés), ou même que certaines distributions payantes dont la politique tarifaire peut évoluer et vous tenir prisonnier, ruinant, selon nous, une bonne part de l’intérêt de Linux.

Car Debian a également l’avantage d’être entièrement libre et open-source et donc gratuit. L’argent économisé peut ainsi être utilisé pour maintenir proprement son parc en interne… Ou si votre structure est suffisamment grosse, pourquoi pas aller jusqu’à l’amélioration de Debian et de Linux. Car « open-source » signifie aussi « communautaire, et ça n’a jamais empêché des privés de l’améliorer pour eux-même et pour les autres. Cela donne également une visibilité parfois conséquente et une image positive. Tout le monde y gagne.

Bien évidemment, l’uniformisation du parc est un élément clé dans l’efficacité de sa maintenance. Nous pensons par conséquent que l’OS choisi doit être standardisé sur la quasi totalité des serveurs.

Cycles et durées de vie software et hardware

Chez LRob, un serveur ne reste pas en production au-delà de 5 ans (OS et/ou matériel). Nos prévisions tablent même sur une moyenne de 2 à 3 ans, parfois moins… Moyenne possible uniquement grâce au fait que nous sommes locataires des serveurs… Donc pas prisonniers d’un amortissement sur 5 ans comme beaucoup. Pensez-y aussi, pour obtenir une longueur d’avance technologique.

Cela implique que la durée d’un « LTS » n’est donc généralement pas déterminante pour nous, en particulier au regard de la longue durée de vie des versions récentes de Debian (~10 ans).

Un serveur est remplacé selon :

• les versions majeures d’OS et de kernel et leur facilité d’upgrade de distribution Linux,
• les évolutions hardware (CPU, Stockage, RAM) et tarifs disponibles,
• les exigences de la charge (CPU, Stockage, RAM, là aussi).

Deux options :

• Upgrade d’OS quand c’est pertinent ;
• Souvent, réinstallation propre sur du matériel plus récent pour rester au top des performances.

A noter : Les serveurs que nous cessons d’utiliser sont ensuite réemployés par d’autres usagers moins exigeants. La recherche de performance ne doit pas empêcher d’être écoresponsable. Si vous êtes propriétaire de votre parc et souhaitez le renouveler plus régulièrement, des repreneurs/revendeurs d’ occasion existent.

Éviter la dette technique grâce à des architectures simples

Multiplier les dépendances logicielles, c’est autant de risques que l’une d’elles devienne incompatible, non maintenue, ou bien nécessite de mettre en place un nouveau « repository », ou encore plante à la mise à jour.

Dès la conception de vos logiciels, vos devez donc choisir des technologies fiables, éprouvées sur la durée. Ne cédez pas au premier langage ou framework à la mode qui risquent de ne plus être maintenus. De sorte que les serveurs exécutant ces logiciels soient pérennes, puissent être mis à jour efficacement, avec leurs applications, sans que vous n’ayez pas tout à refaire dans 2 ans…

Car on sait comment une entreprise réagit quand tout devient impossible à mettre à jour : elle cesse totalement les mises à jour, et augmente ainsi dramatiquement sa dette technique.

Au-delà de l’aspect serveur, il faut également être prêts à maintenir vos applications pour suivre les montées de version. Ne serait-ce que les montées de versions PHP. Mais cela vaut aussi pour MySQL/MariaDB, NodeJS, et ainsi de suite.

En définitive, appliquez les principes du « KISS » : « Keep It Stupid Simple » (gardez les choses stupidement simples).

Politique de maintenance

La mise à jour effraie de nombreux administrateurs système. Des équipes entières font des réunions aussi interminables qu’inutiles pour planifier chaque mise à jour de paquet… Et au final perdre des semaines, voire des mois, avec des versions de retard qui s’accumulent et des failles de sécurité qui se glissent. Sous Linux, selon notre expérience, cette méthode est absolument contre-productive et une approche beaucoup plus terre à terre est bien plus pertinente.

Principe élémentaire d’une bonne maintenance

En environnement Linux, nous faisons trois constats simples :

• Être à jour améliore la sécurité en corrigeant les failles découvertes au fil du temps.
• Une mise à jour peu fréquente implique de nombreux changements lors des mises à jour et augmente ainsi le risque de bugs multi-causaux, bien plus difficiles à comprendre et corriger qu’un seul bug.
• Une mise à jour plus fréquente réduit le nombre de changements simultanés, diminue le nombre de bugs potentiels et simplifie grandement leur résolution.

Par conséquent, nous en déduisons le principe suivant qui nous apparaît alors évident :

Une mise à jour fréquente est plus sécurisée, plus stable et plus sereine.

Nous pensons donc catégoriquement que retarder ses mises à jour est une double faute : stratégique et technique.

Approche incrémentale

L’idée : Y aller franchement, mais sûrement. Oui, c’est antinomique, mais compréhensible :

On met à jour un premier serveur, on observe les changements et ajustements éventuellement nécessaires. On peut ensuite de répéter la procédure sur le reste du parc… Qui est normalement ISO (identique) si on n’a pas fait des choix disparates à sa conception et que le suivi est correct.

Processus prévisible, reproductible, documenté. Bref, la définition de l’efficacité.

Les raisons invalides pour délayer ses mises à jour

Nous observons chaque jour des parcs insuffisamment maintenus, et parfois au sein de grandes entreprises.
Résultat : chaque jour, des entreprises de toutes les tailles sont piratées à cause de failles de sécurité connues.

En cause ? Des freins à la mise à jour. Des précautions, des prudences excessives qui poussent à l’inaction. Lorsque l’on parle de maintenir un niveau de sécurité correct, jusqu’où doit aller la prudence ? Pas trop loin, pour sûr : la priorité devrait toujours être de sécuriser.

Le pire ? Les raisons invoquées sont toujours les mêmes… Voici notre top de ces fameuses phrases qu’on ne veut plus entendre, ainsi que les réponses pour pousser à une action réelle :

• Ça marche, donc on ne touche pas
  • -> En raisonnant comme ça, les femmes n’auraient pas encore le droit de vote.
• La mise à jour risque de causer des bugs
  • -> On prendra le temps qu’il faut pour les résoudre.
• La mise à jour va causer une indisponibilité
  • -> Planifie cette maintenance et indisponibilité, personne ne t’en voudra.
• La mise à jour n’est pas compatible avec notre dette technique
  • -> Corrigeons ou refaisons cette vieille app’ sans délai.
• On ne sait pas revenir en arrière facilement en cas de problème
  • -> Apprends à rétrograder un paquet système.
• On n’a pas de sauvegardes, ou pas restaurables assez facilement
  • -> Fais-en immédiatement et établis un PRA (plan de reprise d’activité).

Les leçons que nous en tirons :

• Une « prudence » excessive concernant les mises à jour de sécurité devient un risque.
• Mieux vaut un risque fonctionnel qu’un risque de sécurité… Un hack ça fait tâche.
• Connaître les risques et ne rien faire a un nom : l’irresponsabilité.
• Voir les problèmes, c’est bien, trouver les solutions, c’est mieux.

Si jamais le message n’était pas encore assez clair, le roi Arthur a un message pour vous :

Fréquence de mise à jour : automatique vs manuelle, veille, grandes décisions

On l’a vu, une mise à jour fréquente résout d’elle-même un certain nombre de problèmes.

La fréquence de mise à jour doit donc être : le plus souvent possible. Il existe toutefois un équilibre à trouver pour éviter de passer sa vie sur le sujet, et au final réellement gagner du temps, de la sécurité et de la tranquillité.

Concrètement, voici la manière de procéder chez LRob pour le meilleur compromis sécurité/temps passé/fiabilité.

• Chaque nuit en automatique : mises à jour « safe » : les petits serveurs d’applications sont configurés avec unattended-upgrades tandis que les serveurs web Plesk font les « safe upgrades » automatiquement.
• Tous les 7 jours max : Lecture des changelogs des principaux logiciels utilisés.
• Chaque mois, manuellement : checkup serveur par serveur. On contrôle d’abord la liste des changements, puis on applique, on nettoie et on décide de rebooter ou pas pour les MAJ Kernel.
• Tous les 1 à 6 mois : évaluation et planification des changements de versions majeures (PHP, MySQL) qui ont un process spécifique de mise à jour ou d’ajout.
• Monitoring 24/7, alerte et intervention immédiate si besoin.

Résultat : presque jamais de changement fonctionnel ou de bug.
1x/an environ, on tombe sur un « breaking change » : c’est à chaque fois un correctif mineur, de type une ligne de config obsolète à enlever ou adapter.
Et 1x/an également, un service ne redémarre pas correctement après mise à jour… Le monitoring 24/7 sert aussi à ça.

La question à 1 million de dollars : préférez-vous intervenir d’urgence 5 minutes 1x/an, ou passer des heures, des semaines, des mois à planifier des mises à jour en retard ou à les faire à la main inutilement ?

Pour LRob, la réponse coule de source : simplifier, automatiser, contrôler, monitorer.

La commande d’upgrade manuel : apt (et apt-get)

Un serveur se met bien-sûr à jour depuis un terminal dans la majorité des cas.

Sous Debian, nous utilisons apt (Advanced Package Tool) pour installer, mettre à jour et supprimer les logiciels.
NB : La commande apt a progressivement remplacé apt-get.

Notre séquence standard faite en 1x pour ne rien oublier :

apt update && apt upgrade && apt autoremove && uptime && uname -a

• apt update : rafraîchit la liste des paquets. On lit ce qui va changer (notes de version, paquets sensibles) pour détecter tout breaking change.
• apt upgrade : applique les mises à jour, puisque tout va bien 99.99% du temps.
• apt autoremove : nettoie les vieux kernels et autres dépendances devenues inutiles.
• uptime : temps depuis le dernier redémarrage.
• uname -a : identité technique (noyau, architecture, etc.).

Les && signifient : on exécute la suite seulement si l’étape précédente a réussi.
Moins d’erreurs en chaîne, plus de maîtrise.

Reboot or not reboot?

Sauf crash complet de l’OS, il n’y a jamais de nécessité de rebooter une machine Linux… Sauf pour upgrader le kernel, si vous n’utilisez pas KernelCare ou similaire pour une mise à jour à chaud. Pour le reste, tous les services de l’OS sont redémarrables indépendamment et toutes les configurations sont éditables. Donc si vous pensez avoir besoin d’un reboot, c’est certainement que vous n’avez pas trouvé le bon programme à redémarrer… Ou bien que vous souhaitez mettre à jour le kernel.

Ainsi, sans KernelCare, en fonction du kernel en place, des changelogs sur les nouveaux kernels, et en particulier les patchs de sécurité, et de l’uptime, on décide de rebooter ou non la machine pour passer sur le nouveau kernel.

Alors faut-il rebooter ou non ? Voici un exemple de notre balance de décision à nous :

• Sur un serveur VPS non critique ou redondé comme un DNS → Le reboot se fait en quelques secondes, donc on reboot à chaque fois qu’un nouveau kernel est disponible.
• Sur un serveur web dédié → Le reboot prend ~8 minutes, donc on le fait plutôt pour une grosse amélioration ou un correctif de sécurité. Et surtout : la nuit pour moins déranger.
• Serveur non rebooté depuis +6 mois → Le nouveau kernel a sûrement des choses à nous apporter, on va planifier le reboot.

Ce que vous gagnez avec la mise à jour planifiée fréquente

• Performance durable : matériel renouvelé intelligemment, réemploi maîtrisé.
• Stabilité : pas de big-bang, des petites étapes contrôlées.
• Sécurité : fenêtre d’exposition minimale, patchs rapides.
• Transparence : vous savez quoi, quand, pourquoi.

Client hébergé : les bonnes questions à poser à votre hébergeur

1. Qu’est-ce qui est automatisé au quotidien ?
2. Comment se passe la gestion d’incident ?
3. Quelle est la politique de reboot (fenêtres, redondance, rollback) ?
4. Qui lit les changements sensibles chaque mois, et comment c’est tracé ?
5. Quelle est la stratégie de cycle de vie matériel (perf vs. sobriété, réemploi) ?

L’approche LRob, résumée

Automatisation des patchs de sécurité + checkup mensuel humain + monitoring 24/7, avec des reboots adaptés au service et un matériel toujours au niveau, sans e-waste inutile.

Vous en avez marre de batailler avec un parc mal maintenu ? Migrer chez LRob, c’est simple et transparent.

-> Car quand on est fier de son travail, on le montre !
-> Et on devient une valeur sûre !

• Hébergement site unique
• Hébergement multi-sites / agences
• Hébergement Nextcloud infogéré
• Maintenance WordPress complète

PS : la migration vers LRob est offerte.