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.
Un coéquipier tombe sur un bug que vous n'arrivez pas à reproduire. Sautez le fichier. Le pg_dump sur votre laptop streame directement dans son psql sur staging — pas d'upload, pas de lien, pas de download. Le pipe route les bytes.
L'API Hoody Pipe garde un pipe non établi pendant cinq minutes en attendant que l'autre côté se connecte. Quand vous êtes tous deux connectés, les bytes streament à travers. Rien n'est jamais écrit sur disque côté serveur.
# depuis votre laptop devpg_dump --format=custom dev \ | curl -T - \ https://pipe.containers.hoody.com/api/v1/pipe/dev-snapshot[INFO] En attente de connexion d'un destinataire…[INFO] Diffusion vers 1 destinataire…[INFO] Transfert terminé.
PUT (ou POST) avec un body en stream. Le serveur affiche des messages de statut sur votre terminal pendant que le pipe s'établit — utile pour voir quand l'autre côté s'est réellement connecté.
# sur leur shell stagingcurl https://pipe.containers.hoody.com/api/v1/pipe/dev-snapshot \ | pg_restore -d staging# rows importées · staging égale dev
GET sur le même chemin bloque jusqu'à ce que le sender se connecte. Les bytes que le sender écrit apparaissent comme corps de la réponse. Pipe vers pg_restore (ou psql) et le dump atterrit dans la base directement — jamais un fichier.
Si vous voulez suivre la progression sans consommer un slot de receiver, pointe un troisième curl sur le même chemin avec ?progress et vous obtenez un dashboard HTML live affichant bytes transférés, vitesse et ETA.
Les quatre mouvements qu'il faut pour amener une DB dev sur le staging de votre coéquipier sans rien faire toucher au disque d'un serveur.
« vous pouvez m'envoyer votre db dev ? »Hier ça aurait voulu dire pg_dump, bucket S3, URL présignée et un collage Slack.
pg_dump dev | curl -T - …/pipe/dev-snapshotvotre terminal affiche « Waiting for 1 receiver to connect… » et reste là. Aucun fichier n'est créé localement non plus.
curl …/pipe/dev-snapshot | pg_restoreLe pipe s'établit dès qu'ils se connectent. Les bytes commencent à circuler de votre pg_dump direct dans leur pg_restore.
Transfer complete · 0 bytes sur le serveurL'usage disque côté serveur reste à zéro. Le chemin pipe oublie que le transfert a eu lieu dès que les deux côtés se déconnectent.
C'est le même nombre de commandes que vous taperiez pour un round-trip S3 — moins le bucket, le credential, l'upload, le download et le cleanup.
Hoody Pipe est un intermédiaire de stream, pas un service de fichiers. Le dump existe sur votre disque et sur le leur ; entre les deux, ce sont juste des bytes en vol. Rien à nettoyer, rien à fuir.
Pas de barre de progression d'upload à surveiller parce qu'il n'y a pas d'upload. Un dump de 40 GB circule à la vitesse que votre réseau et le pg_restore de votre coéquipier peuvent soutenir — le pipe forwarde, c'est tout.
Ouvrez le même chemin avec ?progress sur une troisième URL et observez les bytes transférés, la vitesse et l'ETA en temps réel. Jusqu'à 50 spectateurs par pipe, aucun ne consomme de slot de receiver.
L'état d'une base était une pièce jointe. Maintenant c'est un chemin.
Les fichiers sont du state au repos. Les chemins sont du state en mouvement. Le Hoody Pipe permet à un snapshot de base d'être le second — adressable, éphémère, et jamais posé sur un serveur que vous devez nettoyer plus tard.
La plupart des outils utilisés pour partager une base dev sont des reliques de l'époque où on ne pouvait pas streamer des bytes entre deux terminaux en HTTP. Le pipe les rend tous inutiles.
Deux curls. Un chemin. Leur staging égale votre dev.