Aller au contenu
Théophile Diot.
Menu de navigation
Tous les projets

Ingénierie de plateforme privée

Ingénierie d’infrastructure / 2026-aujourd’hui

Une plateforme privée sur quatre hôtes, gérée comme du code, avec 69 stacks Compose incluses dans le périmètre, une automatisation bornée, de l’observabilité et des invariants testés.

Rôle
Propriétaire et opérateur
Contribution
Conception et exploitation de la plateforme privée décrite ici.
Type de preuve
Relevé privé daté
91Services administrésDéfinis dans 69 stacks Compose ; 22 stacks de projets exclues
83/83Images épingléesVersion et empreinte du manifeste, sans balise latest
28Invariants de configuration testésDeux analyseurs couvrant tout le dépôt, intégrés à des hooks pre-commit
01

Le problème

Les pannes coûteuses étaient silencieuses : des adresses allouées dynamiquement reprenaient des emplacements réservés après un redémarrage, des fichiers montés par liaison restaient liés à d’anciens inodes et des routes de connexion choisissaient le mauvais fournisseur. La configuration pouvait encore être générée sans erreur alors que l’état du système actif était déjà incorrect.

Rôles logiques sur une plateforme à quatre hôtes
Schéma conceptuel. Il relie des responsabilités sans associer de service, d’identifiant, de quantité, d’exposition ni de rôle à une machine physique.
Les frontières, de la plus externe à la plus interne
Schéma conceptuel. Il montre le motif des frontières, pas une topologie, un inventaire ni une carte d’exposition.
  1. 01Bordure publiqueLes requêtes sont inspectées et routées avant d’atteindre les charges de travail.entrée
  2. 02Identité et politiqueLes accès opérateur et l’automatisation font l’objet d’un contrôle avant exécution.contrôle
  3. 03Plan de serviceChaque charge de travail se connecte uniquement aux réseaux nécessaires.interne
  4. 04Plan de preuveJournaux, métriques et traces décrivent l’état actif.observer
  5. 05Plan de repriseLes sauvegardes sont vérifiées séparément, et la restauration hors hôte constitue le critère de réussite.restaurer
02

Décisions

  1. Traiter Compose comme un graphe de dépendances : épingler les images par version et empreinte de manifeste, documenter l’ordre de démarrage et rendre l’autorité active explicite.

    CoûtChaque mise à jour d’image devient une modification délibérée. Rien n’avance tout seul, mises à jour de sécurité comprises.

  2. Transformer les incidents d’allocation réseau et de routage de connexion en deux analyseurs couvrant tout le dépôt, appuyés par 28 tests unitaires.

    CoûtLes analyseurs ne détectent que les familles de pannes déjà comprises ; une nouvelle famille reste invisible jusqu’à ce qu’on écrive son analyseur.

  3. Placer l’automatisation de production derrière des identités à périmètre restreint, des routes API typées, des listes de commandes autorisées, des revues signées, 46 cas d’acceptation et de refus, et deux contrôles réseau.

    CoûtLe travail courant doit désormais passer ces contrôles, même lorsqu’un changement légitime échoue à l’un d’eux.

  4. Acheminer journaux, métriques et traces par un collecteur unique ; faire de la vérification des sauvegardes et de la restauration hors hôte des critères d’acceptation explicites.

    CoûtLa reprise se décrit par des critères écrits de vérification plutôt que par un chiffre unique de disponibilité, ce qui la rend plus difficile à résumer.

03

Résultat

Les analyseurs bloquent désormais avant le commit les mauvaises configurations réseau et de connexion déjà connues, tandis que des tests positifs et négatifs éprouvent la surface d’automatisation. La télémétrie sur trois signaux est configurée, et la reprise repose sur des critères écrits de vérification et de restauration plutôt que sur une promesse de disponibilité.

04

Preuves et périmètre

Vous cherchez un collaborateur ?

Présentez le projet et ses contraintes. Je réponds par e-mail.