Soixante conteneurs sur un seul serveur
Une seule machine bare-metal fait tourner des dizaines à des centaines de conteneurs Hoody. La déduplication KSM et BTRFS rend le coût marginal quasi nul.
vous faites tourner une migration de huit heures. Cinq personnes veulent un statut sans consommer un slot receiver ni interrompre le stream. Ajoutez ?progress à l'URL pipe. Quiconque l'ouvre obtient un dashboard HTML live — octets transférés, vitesse courante, ETA, transitions d'état. La migration tourne à pleine vitesse, peu importe le nombre d'yeux qui regardent.
?progress est une lecture en side-channel. Il ne réclame jamais un slot receiver, ne crée jamais de backpressure, ne touche jamais aux octets. La migration tourne à pleine bande passante quel que soit le nombre de spectateurs.
Elle colle l'URL pipe avec ?progress dans le navigateur de son téléphone. Le dashboard HTML apparaît instantanément — état : en attente, 0 % — pas d'install, pas de login, pas de slot receiver consommé.
SSE pousse un événement state: streaming. La barre saute à 22 %, les octets défilent, MB/s se stabilise à 118. Le dashboard se met à jour toutes les 250 ms sans un seul reload.
Elle ferme l'onglet. Sa connexion spectateur saute. La migration ne s'en aperçoit pas — elle n'a jamais été dans le data path. Le sender et son receiver réel continuent.
Elle rouvre l'URL au lever du jour. Le dashboard montre un événement done : 7.6 GB transférés, 8 h 02, zéro erreur. L'état serveur survit au refresh — les retardataires voient toujours la dernière ligne.
Elle transmet l'URL au Slack équipe. Trois ingés l'ouvrent et voient le même état done. Pas de fil de statut à clore, pas de panel Grafana à dé-favoriser. Une URL, cinq témoins, zéro interruption.
# 1. Sender — migration de huit heures. Comme d'habitude.
tar czf - /var/lib/postgres | curl -T - "$PIPE/api/v1/pipe/migration"
# 2. Receiver — le seul client qui compte pour le backpressure.
curl "$PIPE/api/v1/pipe/migration" | tar xzf - -C /restore
# 3. Le boss ouvre l'URL sur son téléphone. Dashboard HTML. Zéro setup.
# => https://pipe.hoody.com/api/v1/pipe/migration?progress
# 4. vous voulez du SSE pour un bot Slack ? Même URL, autre Accept.
curl -N -H "Accept: text/event-stream" \
"$PIPE/api/v1/pipe/migration?progress" \
| grep -E '^event: (progress|state|done)'
# event: state \n data: '{'"state":"streaming","receivers":1'}'
# event: progress \n data: '{'"bytes":5046464512,"mbps":118,"etaSec":840'}'
# event: done \n data: '{'"bytes":8160000000,"durationSec":28800'}'Trois types d'événements SSE. state pour les transitions (idle → waiting → streaming → complete), progress toutes les 250 ms pendant le flux (bytesTransferred, speed, ETA), done une fois à la fin avec les stats finales. Jusqu'à cinquante spectateurs par path, chacun avec une fenêtre de connexion de cinq minutes.
?progress est un side-channel. Le boss, le collègue, le client externe, l'astreinte — ils ouvrent tous la même URL. Aucun n'affecte le transfert. Tous voient le même état live.
Marque l'URL en favori sur son téléphone. Vérifie deux fois par jour.
Dashboard HTML, pas de logincurl le SSE vers un webhook Slack. Bot de statut en une ligne.
text/event-stream, même URLEmbarqué dans une page status publique. Poll toutes les 30 s.
0 slot receiver, état live completBranché à PagerDuty via l'événement done. Ping en fin.
event: done, déclencheur uniqueRegarder la migration est sa propre URL. La migration ne s'en rend pas compte.
Chaque équipe a sa façon de répondre à « ça en est où ? ». La plupart coûtent un service à faire tourner, un dashboard à câbler, ou un canal de chat à entretenir. Un paramètre d'URL ne coûte rien de tout ça.
Envoyez l'URL. Arrêtez d'envoyer des updates.