
Soixante conteneurs sur un seul serveur
Une machine bare-metal exécute des dizaines à des centaines de conteneurs Hoody. La dédupplication KSM et BTRFS rend le coût marginal quasi nul.
Vous êtes en pair-debug à minuit et le hotspot de l'autre côté ne survivra pas à un Zoom. Vous avez tous les deux un shell. ffmpeg capture le micro, curl envoie en PUT vers un chemin pipe, l'autre terminal fait curl et joue les octets. Pas de SDK, pas de signaling, pas de réunion.
$ ffmpeg -f alsa -i default \
-c:a libopus -f ogg - \
| curl -T - https://pipe.containers.hoody.com/api/v1/pipe/voice$ curl https://pipe.containers.hoody.com/api/v1/pipe/voice
| mpv --no-video -pas de signaling, pas de SDK, pas de Zoom
ffmpeg encode votre microphone en opus et écrit sur stdout. curl envoie en PUT ce stdin vers /api/v1/pipe/voice. Quiconque fait GET sur le même chemin reçoit les octets à mesure que l'expéditeur les produit. Le pipe maintient le destinataire jusqu'à cinq minutes en attendant que l'expéditeur se connecte, transmet le Content-Type, et ne stocke rien.
ffmpeg -f alsa -i default -c:a libopus -f ogg - lit votre microphone, encode en opus, écrit sur stdout.
curl -T - envoie en PUT stdin vers /api/v1/pipe/voice. Le pipe attend jusqu'à cinq minutes un destinataire sur le même chemin.
Leur terminal exécute curl https://.../api/v1/pipe/voice. Le pipe associe l'expéditeur au destinataire et démarre le streaming.
Leur curl est redirigé vers aplay ou mpv. L'audio joue à mesure qu'il arrive, octet par octet. ctrl-C met fin à l'appel.
Le pipe transmet le Content-Type, supporte un temps d'attente de cinq minutes maximum avant qu'une contrepartie se connecte, et utilise HTTPS — rien de plus exotique que le protocole que votre shell parle déjà.
Il n'y a pas d'annulation d'écho, pas de buffer de jitter, pas de DSP sophistiqué. C'est le genre de canal vocal sur lequel un duo SRE fait du pair-debug : dépouillé, faible surcoût, fiable. Chaque couche qu'une plateforme de réunion construit est une couche que la paire pipe n'a tout simplement pas.
Le même mécanisme micro-sur-HTTP se lit de trois façons différentes selon qui est à l'autre bout du pipe.
Vous êtes trois commandes plus loin dans un incident en prod. Lancer Zoom prendrait plus de temps que le fix. ffmpeg | curl de votre côté, curl | mpv du leur — vous pouvez parler pendant que vous suivez les logs.
Le partage de connexion téléphonique étouffe sur un appel vidéo. Un flux opus à 32 kbps sur HTTP, non. L'autre extrémité ouvre une URL et écoute — ils n'ont même pas besoin d'un micro pour participer.
Rien n'est stocké sur un serveur. Il n'y a pas d'application tierce sur l'une ou l'autre machine. Le pipe est purement streaming — les octets passent et disparaissent au moment où ctrl-C atterrit.
L'audio, ce ne sont que des octets. Les octets, ce n'est qu'un pipe.
L'arsenal d'outils vocaux que toute paire d'ingénieurs accumule. Chacun suppose une réunion, un compte, ou un serveur de signaling personnalisé. L'URL pipe ne suppose aucun d'entre eux.
La prochaine fois que quelqu'un dit « on peut faire un petit call rapide ? », ouvrez plutôt un pipe.