Infrastructure en direct

Les cinq machines derrière kerboul.me.

sentinel, c'est le cluster Proxmox de cinq nœuds que j'exploite : routage et DNS en bordure, une forge Git auto-hébergée avec sa propre CI/CD, et une vingtaine de services derrière un seul reverse proxy Traefik. Chaque chiffre de cette page est lu en direct depuis l'API du cluster.

Les nœuds
/01 Nœuds

Cinq nœuds, chacun son rôle

Un cluster Proxmox, cinq hôtes. Le relevé de chaque carte est interrogé en direct depuis l'API Proxmox du cluster : c'est la charge en ce moment même.
Pouls du cluster

lecture du pouls…

cerberus

~8 cores · 3.7 GB

La bordure. Routeur VyOS, Traefik, DNS et supervision uptime.

interrogation du cluster…

echelon

11 GB RAM

Ce site. Le portfolio, sa télémétrie et les analytics.

interrogation du cluster…

mikoshi

7.6 GB RAM

Apps et Kubernetes. Vireli, Open WebUI, un nœud kube.

interrogation du cluster…

cynosure

31 GB RAM

Le cheval de trait. Gitea, les runners CI, Nextcloud, Coolify.

interrogation du cluster…

ultron

Xeon E5-1650 v3 · 32 GB · GTX 1050

Capacité et GPU. La stack média, avec un GPU à passer en VFIO.

interrogation du cluster…

Relevé en direct depuis l'API Proxmox du cluster. En cache, lecture seule, sans secret.

/02 Chemin

Comment une requête vous parvient

Chaque visite de kerboul.me suit le même chemin, de la bordure publique jusqu'au backend sur echelon. Le voici, de bout en bout.
  1. Visiteur un navigateur
  2. Cloudflare DNS
  3. VPS WireGuard
  4. VyOS le routeur
  5. Traefik TLS, routage
  6. echelon le portfolio
Latence en bordure

mesure…

Un aller-retour en direct depuis votre navigateur vers la bordure publique du cluster. Votre distance à sentinel, en millisecondes.
/03 Services

Ce qui tourne, en ce moment

Les services publics derrière kerboul.me, chacun vérifié en direct depuis le cluster à chaque rafraîchissement.

vérification des services…

Vérifiés côté serveur, à chaque rafraîchissement. Un petit ensemble public choisi.
/04 Pipeline

Comment cette page se déploie

Un push sur main lance trois jobs sur un runner auto-hébergé et arrive ici en environ deux minutes, avec un rollback automatique si le test de fumée en direct échoue.
  1. 01 ~45s verify lint, types, build et les tests de fumée
  2. 02 ~50s image build, scan Trivy, push vers le registre
  3. 03 ~15s deploy pull, test de fumée de l'URL live, rollback si échec

ce build 4a6d810 La page que vous lisez a été déployée par exactement cette pipeline.

/05 Pile

La pile qui tient l'ensemble

Des outils éprouvés, câblés ensemble et exploités de bout en bout.
  • Proxmox VE Le cluster d'hyperviseurs à cinq nœuds
  • VyOS Le routeur en bordure
  • WireGuard Tunnel vers le VPS public
  • Traefik Reverse proxy, certificats Let's Encrypt
  • Docker Chaque service, conteneurisé
  • Gitea + Actions Forge auto-hébergée et CI/CD
  • Cloudflare DNS DNS et le challenge ACME
  • AdGuard Home DNS du LAN avec filtrage
  • Tailscale Accès nomade au LAN
  • Coolify Un petit PaaS pour les apps annexes

Une carte en direct du cluster. Les nœuds sont réels ; les points en mouvement figurent le trafic, ce n'est pas une capture réseau.

/06 Ops

Exploité de bout en bout

La partie qui ne tient pas dans une capture : le maintenir en route, le surveiller, et consigner l'exploitation pour qu'elle survive à ma mémoire.

D'astreinte sur ma propre infrastructure : sauvegardes, renouvellement de certificats, supervision, et les modes de défaillance qu'on ne rencontre qu'à la mauvaise heure.

Supervisé par Uptime Kuma

Les runbooks dans un dépôt

La configuration, les runbooks et l'automatisation du cluster vivent dans un dépôt versionné, exploités comme du code. Ajouter un nœud ou restaurer un service est une procédure documentée, pas de la mémoire tribale.

connexion à sentinel…