La moitié du métier qui n'est dans aucun dépôt

Le site que vous lisez, et les cinq sites projets à côté, tournent sur un serveur physique dédié : Incus pour les conteneurs système, Docker à l'intérieur, nginx qui termine le TLS et route par hôte.

Les mêmes pratiques font tourner la plateforme de production que je construis au travail : les niveaux de sauvegarde, la planification pilotée par la charge et le schéma d'effacement ci-dessous y sont tous en usage, pas seulement ici. Ce site est l'instance dont je peux vous montrer l'intérieur.

Caddy quand le HTTPS automatique est tout l'intérêt et que la config doit rester courte. nginx quand il me faut un contrôle précis du routage, des limites et du buffering. Traefik pour la répartition de charge entre conteneurs Docker, là où le proxy doit découvrir les backends au fil de leurs apparitions plutôt qu'on les lui déclare.

Les trois terminent le TLS, plafonnent la taille du corps de requête et les timeouts de client lent avant qu'une requête n'atteigne une application, et refusent par défaut tout hôte qu'ils ne reconnaissent pas.

Des dumps nocturnes partent hors site vers du stockage objet, sur une fenêtre de rétention. Un job séparé restaure la dernière sauvegarde dans un conteneur jetable et vérifie que les tables reviennent non vides, parce qu'un script de sauvegarde qui sort avec zéro n'est pas la même affirmation qu'une sauvegarde restaurable.

Le troisième niveau est physique et délibérément hors ligne. Une unité path systemd guette le montage d'une clé USB précise et lance la sauvegarde dès qu'elle apparaît — on branche le disque et ça tourne, sans commande à retenir. Elle vérifie d'abord s'il existe déjà une sauvegarde à cette date, pour qu'un remontage du même disque ne relance pas le job. Une copie hors ligne ne peut pas être atteinte par ce qui atteint le serveur.

Les sauvegardes sont planifiées en fonction de la charge du serveur plutôt que de l'horloge, pour qu'une période chargée ne reçoive pas un job lourd par-dessus.

La charge moyenne sert aussi à guetter la montée qui a précédé un crash sur cette machine. Quand elle apparaît, les bases et l'état de l'infrastructure sont poussés hors de la machine avant la panne plutôt que récupérés après. Ça s'est déclenché sur un vrai crash, et c'est la seule raison pour laquelle j'y fais confiance.

On ne peut pas retourner dans une archive immuable retirer chirurgicalement une personne. Alors les données sont chiffrées par utilisateur avant d'être écrites, et l'effacement détruit la clé de cet utilisateur plutôt que l'archive.

Les lignes restent où elles sont et deviennent définitivement illisibles, dans toutes les copies historiques à la fois. La chaîne de sauvegarde garde son intégrité et l'effacement est réel plutôt que promis.

L'environnement sur site tourne sur Proxmox pour les machines virtuelles et Incus pour les conteneurs système : chaque charge de travail a sa propre machine isolée au lieu d'en partager une.

Le travail de CI est réparti sur plusieurs runners auto-hébergés plutôt que de s'empiler sur un seul, donc un job lourd sur un runner ne bloque pas tous les autres.

La mise à l'échelle horizontale suppose qu'on peut acheter un nœud de plus. Avec une seule machine, la marge doit sortir du travail lui-même.

Le plus gros gain a été les images. Un service Rust redimensionne les fichiers à 640px et les compresse avant qu'ils n'atteignent le stockage objet. L'usage hebdomadaire du stockage a chuté de 80 %, et le frontend est devenu environ deux fois plus rapide au premier chargement, parce que les octets qu'il attend ne sont plus qu'une fraction de ce qu'ils étaient. Le stockage et l'egress, c'est la facture qui grossit discrètement et qu'il est le plus difficile de faire redescendre.