
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.
Slack le rejette. Drive demande une demande de partage de dossier. L'email plafonne à 25 Mo. Deux curl — un sur votre laptop, un sur le sien — déplacent le fichier de disque à disque. Le pipe achemine les octets ; rien n'est jamais uploadé sur un serveur.
GET et PUT sur le même chemin. Le Hoody Pipe garde le côté qui se connecte en premier jusqu'à cinq minutes ; dès que l'autre côté arrive, les octets passent en flux direct. Rien n'est écrit sur le disque côté serveur.
# from your laptopcurl -T dump.sql \ https://pipe.containers.hoody.com/api/v1/pipe/dump-yesterday[INFO] Waiting for 1 receiver to connect…[INFO] Streaming to 1 receiver…[INFO] Transfer complete.
PUT (ou POST) avec un corps en streaming. Le serveur affiche des lignes de statut pendant que le pipe s'établit — utile comme signal en direct que l'autre côté a vraiment décroché.
# on their boxcurl \ https://pipe.containers.hoody.com/api/v1/pipe/dump-yesterday \ -o dump.sql# 4.2 GB · saved · done.
GET sur le même chemin se bloque jusqu'à ce que l'expéditeur se connecte. Les octets que l'expéditeur écrit apparaissent comme corps de réponse — redirigez-les vers un fichier avec -o, ou vers le stdin de tout programme qui lit.
L'ordre n'a pas d'importance. Si vous lancez curl en premier, la requête se bloque jusqu'à ce qu'il se connecte. S'il lance curl en premier, c'est la sienne qui se bloque. Dans tous les cas, dès que les deux côtés sont connectés, les octets se mettent à passer.
Du ping Slack à l'arrivée du fichier sur son disque — les quatre mouvements que le pipe fait s'enchaîner.
« tu peux m'envoyer le dump de prod d'hier ? »Le fichier fait 4 Go. Slack le rejette, le drive partagé exige un ticket de partage de dossier. Vous arrêtez de tendre la main vers l'un comme l'autre.
curl -T dump.sql …/pipe/dump-yesterdayVotre terminal affiche « Waiting for 1 receiver to connect… » et reste là. Vous collez l'URL dans le chat : « lance ça. »
curl …/pipe/dump-yesterday > dump.sqlLe pipe s'établit dès qu'il se connecte. Les octets se mettent à passer de votre disque à travers le pipe vers le fichier sur le sien.
Transfert terminé · 0 octets sur le serveurL'usage disque côté serveur reste à zéro. Le chemin de pipe oublie que le transfert a eu lieu dès que les deux côtés se déconnectent.
Le même nombre de commandes que vous taperiez pour un aller-retour Drive — moins le login, moins la barre d'upload, moins le lien, moins le nettoyage.
Hoody Pipe est un intermédiaire de streaming, pas un service de fichiers. Le fichier existe sur votre disque et sur le sien. Entre les deux, ce ne sont que des octets en vol à la vitesse que vos deux réseaux peuvent soutenir — le pipe ne fait que transférer.
Les chemins de pipe ne nécessitent aucune authentification sur le déploiement public. Ce sont des URLs adressables limitées à un seul transfert ; dès que les deux côtés se déconnectent, le chemin disparaît. Rien à signer pour le destinataire.
Le transfert n'atterrit jamais sur le disque du serveur. Rien à nettoyer, rien à fuir, rien à expirer. Les octets sont sur votre laptop ; puis ils sont aussi sur le sien ; le chemin oublie qu'il a jamais existé.
Deux curl. Pas de login. Pas de barre d'upload. Terminé.
« Envoie-moi ce fichier » signifiait un onglet, une connexion, un upload, un lien, un collage, un téléchargement. Maintenant, ça signifie : tapez curl, collez l'URL, lancez curl. La version la plus rapide de cette tâche que vous taperez jamais.
La plupart des outils que nous utilisions pour envoyer un fichier de 4 Go sont des reliques de l'époque où nous ne pouvions pas faire transiter des octets entre deux terminaux via HTTP. Le pipe les rend tous inutiles.
Deux curl. Le fichier est sur son poste. Rien n'a jamais été uploadé.