Authentik sur Proxmox : SSO et authentification centralisée pour tous tes services
À un moment dans le homelab, tu te retrouves à gérer un carnet de mots…
Estimated reading time: 5 minutes
Tu as sûrement croisé l’acronyme SRE dans des offres d’emploi, des conférences ou des fils de discussion où tout le monde a l’air très sérieux. Ça sonne « grosse entreprise », « équipes d’astreinte », « millions d’utilisateurs ». Et pourtant, quand j’ai lu les bases, je me suis dit : mais c’est exactement ce que j’essaie de faire avec mon petit homelab, sans savoir que ça avait un nom.
Cette série d’articles reprend, une par une, les idées du SRE qui valent le coup à la maison. Pas pour jouer à l’ingénieur de grande entreprise : pour que ton Nextcloud, ton Pi-hole et ton blog arrêtent de tomber en panne au pire moment.
C’est quoi, le SRE ?
SRE veut dire Site Reliability Engineering, littéralement « ingénierie de la fiabilité des sites ». Ce n’est ni un outil, ni une certification. C’est une façon de s’y prendre pour que des services restent disponibles.
L’histoire est assez simple : au début des années 2000, Google a demandé à des gens qui savent programmer de s’occuper de la production, au lieu de tout faire à la main. Résultat : on a écrit des scripts, mesuré les choses, et décidé avec des chiffres plutôt qu’au feeling. Google en a tiré deux livres, disponibles gratuitement en ligne. Ils sont écrits pour des organisations immenses, mais les idées de fond se transposent très bien en petit.
Pourquoi ça parle à un homelab
Quand on fait tourner des services chez soi, on se retrouve dans la situation d’un mini-SRE :
- on est à la fois développeur, admin et support,
- les « utilisateurs » (la famille, les amis, nous-mêmes) râlent quand ça ne marche plus,
- on a peu de temps, donc il faut éviter de perdre ses soirées à réparer.
Autrement dit : on a les mêmes problèmes, avec beaucoup moins de moyens. D’où l’intérêt de piocher les bonnes idées sans se noyer dans les processus.
Les quatre idées que je garde
1. Mesurer plutôt que deviner
« Je crois que ça marche bien » n’est pas une mesure. Savoir qu’un service a répondu 99,6 % du temps le mois dernier, c’en est une. Pas besoin d’un système compliqué : Prometheus et une sonde HTTP suffisent. J’ai détaillé les signaux qui comptent dans Ce que je surveille vraiment sur mon homelab.
2. Se fixer un objectif réaliste
Viser « jamais de panne » est impossible et épuisant. Mieux vaut choisir un objectif adapté : « mon blog doit être joignable 99,5 % du temps », par exemple. C’est ce qu’on appelle un SLO, et ça fait l’objet d’un article de cette série.
3. Supprimer le répétitif
Tout ce qu’on refait à la main tous les mois (renouveler un certificat, nettoyer un disque, redémarrer un service qui fuit) est du temps perdu et une source d’oubli. Le SRE appelle ça le toil. On y revient très bientôt.
4. Apprendre de chaque panne
Une panne n’est pas une honte, c’est une information gratuite. Prendre dix minutes pour écrire ce qui s’est passé évite de la revivre. C’est l’idée du postmortem, version mini.
Ce que je laisse de côté
Une grande partie du SRE version entreprise n’a aucun sens chez soi, et je ne vais pas faire semblant :
- les rotations d’astreinte à plusieurs, les escalades vers un responsable,
- les processus formels avec réunions, rôles et validations,
- les objectifs à quatre ou cinq neuf (99,999 %), qui coûtent une fortune en redondance.
Quand je parlerai d’« astreinte » plus loin dans la série, ce sera pour une seule personne : toi, et uniquement quand c’est vraiment utile.
SRE, DevOps, admin système : la différence en une phrase
- Admin système : « je fais tourner la machine. »
- DevOps : « on automatise la livraison et l’exploitation, ensemble. »
- SRE : « on traite la fiabilité comme un problème d’ingénierie, avec des objectifs mesurés. »
Dans un homelab, tu es les trois à la fois, donc autant prendre le meilleur de chacun.
Le programme de la série
Chaque article tient seul, mais ils s’enchaînent bien :
- Cet article : le vocabulaire.
- Le toil à la maison.
- SLO, SLI, SLA : se fixer un objectif.
- Le budget d’erreur : combien de pannes se permettre.
- Écrire un mini-postmortem.
- L’astreinte à la maison : être prévenu sans être réveillé pour rien.
- Les runbooks : le pense-bête du moi fatigué.
- Alertmanager et des règles qui ont du sens.
- Voir venir la saturation (disque, RAM).
- Casser son homelab exprès.
Pour commencer dès ce soir
Si tu ne fais qu’une chose après cet article : écris sur une feuille les trois services que tu ne supporterais pas de perdre (le mien : ce qui contient les photos de la famille). Tout le reste de la série consistera à les protéger intelligemment.
Tu as déjà des idées de ce que tu veux mesurer ? Dis-moi lesquelles, ça me donnera des exemples pour la suite.
