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.
Conteneurs·Snapshots
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERPartager un flux
POURDevs backend
POURDevOps et infra
SERVICESPipe
POURQUOI HOODYHTTP-natif
POURQUOI HOODYÉconomie des conteneurs
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERPartager un flux
POURDevs backend
POURDevOps et infra
SERVICESPipe
POURQUOI HOODYHTTP-natif
POURQUOI HOODYÉconomie des conteneurs
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERPartager un flux
POURDevs backend
POURDevOps et infra
SERVICESPipe
POURQUOI HOODYHTTP-natif
POURQUOI HOODYÉconomie des conteneurs
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉModéré
MÉTIERPartager un flux
POURDevs backend
POURDevOps et infra
SERVICESPipe
POURQUOI HOODYHTTP-natif
POURQUOI HOODYÉconomie des conteneurs
use-cases / move-200gb-between-clouds-with-two-curls / hero
PIPE · MIGRATION CROSS-CLOUD
Déplace 200GB entre clouds avec deux curls
Un backup Postgres de 200GB à Frankfurt. Une machine fraîche à Singapour. vous sautez l'aller-retour S3. Un curl pipe pg_dump vers une URL Hoody pipe ; un curl de l'autre côté stream directement dans psql. Les octets sont en vol, jamais au repos.
src.frankfurt:~
SOURCE · LIVE
eu-fra-1 · Frankfurt# stream le dump vers la sortie$ pg_dump db | gzip \ | curl -T - https://pipe.../migration[INFO] Streaming to 1 receiver(s)...
pipe/migration
dst.singapore:~
DEST · PRÊT
ap-sin-1 · Singapour# pipe direct dans psql$ curl https://pipe.../migration \ | gunzip | psql newdb[INFO] Transfert terminé.
200GB · zéro saut · zéro stockage
use-cases / move-200gb-between-clouds-with-two-curls / mechanism
Ce n'est pas un bucket. C'est un routeur.
Hoody Pipe est un chemin nommé sur un serveur HTTP. L'envoyeur PUT un stream dessus, le récepteur GET le même chemin, et le serveur splice les deux ensemble. Rien n'est écrit sur disque ; le pipe contient zéro octet par design.
Octets entre deux curlsTTL 5-MIN · AUCUNE COUCHE DE STOCKAGE
01 · ENVOYEUR
PUT sur le chemin
Depuis la machine source, pg_dump | gzip | curl -T - vers l'URL pipe. Le corps PUT stream à la vitesse que la backpressure TCP autorise. Le serveur tient la connexion jusqu'à ce qu'un récepteur arrive sur le même chemin.
PUT /api/v1/pipe/migration02 · ROUTEUR
Splice en mémoire
Quand le GET du récepteur atterrit sur le même chemin, Hoody splice les octets de l'upload directement dans la réponse du download. Pas de buffer, pas de staging sur disque, pas de commit async — juste un stream direct entre deux sockets HTTP.
0 octet sur disque03 · RÉCEPTEUR
GET en stream
Depuis la machine destination, curl GET le chemin et pipe la réponse à travers gunzip | psql. Le stream côté récepteur termine à la seconde où le dernier octet de l'envoyeur arrive. Pas de retry, pas de manifest, pas de cleanup.
GET /api/v1/pipe/migrationL'ordre des connexions n'a pas d'importance — le récepteur peut curl en premier et bloquer jusqu'à ce que l'envoyeur se connecte (ou inversement), jusqu'au TTL pipe de 5 minutes. La backpressure flue de bout en bout : un psql lent ralentit le curl à la source. Il n'y a pas de file à déborder parce qu'il n'y a pas de file.
use-cases / move-200gb-between-clouds-with-two-curls / commands
Les deux vraies commandes
Ce n'est pas du pseudocode. Ouvrez deux terminaux sur les deux serveurs, lancez-en un sur chacun, et regardez un backup de 200GB quitter un cloud et atterrir dans un autre.
frankfurt:~ · envoyeur
PUT · ENVOYEURFrankfurt → pipe
# 1. Stream la base live vers le pipe$pg_dump --format=custom mydb | gzip \ | curl -T - https://pipe.containers.hoody.com/api/v1/pipe/migration# 2. Le serveur répond avec des messages de statut[INFO] Waiting for 1 receiver(s) to connect...[INFO] Streaming to 1 receiver(s)...[INFO] Upload terminé.[INFO] Transfert terminé.
singapore:~ · récepteur
GET · RÉCEPTEURpipe → Singapour
# 1. Pipe direct dans la nouvelle base$curl https://pipe.containers.hoody.com/api/v1/pipe/migration \ | gunzip | psql newdb# 2. Les octets atteignent psql à mesure qu'ils quittent FrankfurtCREATE TABLE okCOPY 4823918 okALTER TABLE ok
PUT (curl -T) est préféré parce que c'est ainsi que curl veut uploader un stream. POST marche identiquement — même chemin, mêmes messages de statut. Utilise ?n=N des deux côtés si vous devez fan-out le même dump à plusieurs récepteurs.
use-cases / move-200gb-between-clouds-with-two-curls / spectator
PROGRESS · ?progress
Une URL spectateur que n'importe qui peut suivre
Un troisième laptop ouvre la même URL pipe avec ?progress et reçoit un flux SSE temps-réel d'octets-par-seconde, ETA, et récepteurs connectés. Spectater ne consomme pas un slot récepteur — cinquante coéquipiers peuvent regarder la migration sans changer la valeur n ni interférer avec le transfert.
- AUCUN SLOT RÉCEPTEUR
- JUSQU'À 50 SPECTATEURS
- LINGER 30-MIN
spectator.…hoody.com/migration?progress
SSE · text/event-streamEN DIRECT
event: statedata: ["state":"streaming","receivers":1]event: progressdata: ["bytes":83_421_667_840, "speed":"412 MB/s", "eta":"4m 44s"]event: progressdata: ["bytes":118_295_117_824, "speed":"406 MB/s", "eta":"3m 21s"]↻ live · throttle 250ms
use-cases / move-200gb-between-clouds-with-two-curls / why
Pourquoi deux curls battent six étapes
L'aller-retour S3 a l'air simple sur un tableau blanc. En production c'est une pile de pièces mobiles qui facturent toutes à la seconde. Le pipe écrase toute la pile dans le transport lui-même.
Pas de troisième couche de stockage
S3, GCS, Azure Blob — l'aller-retour existe seulement parce qu'il n'y avait pas d'autre endroit où parquer les octets. Le pipe est le chemin. Il n'y a pas de bucket à provisionner, à configurer en lifecycle ou à scrub après coup.
Paye le vol, pas le repos
Egress sur l'upload, egress sur le download — deux fois. Avec le pipe les octets quittent Frankfurt et arrivent à Singapour en un saut. vous payez pour les secondes où la connexion était ouverte, pas pour du stockage que vous supprimeras demain.
HTTP de bout en bout
votre monitoring comprend déjà HTTP. votre VPN, votre firewall, votre journal d'audit aussi. Pas de nouvelle identité IAM, pas de nouveau SDK, pas de nouveau mode d'échec — c'est une commande curl.
DIMENSIONALLER-RETOUR S3HOODY PIPE
- Étapes6 étapes2 curls
- Disque utilisé200 GB0 octet
- Trajets egress2 × 200 GB1 × 200 GB
- Cleanuprègle lifecycleaucun
La vitesse est limitée par le maillon le plus lent de bout en bout (egress Frankfurt, ingress Singapour, votre fenêtre TCP). Le pipe Hoody ne contient zéro octet — il n'y a pas de stockage côté serveur ; la backpressure flue directement entre les deux endpoints.
use-cases / move-200gb-between-clouds-with-two-curls / punchline
Deux terminaux, une URL, pas de troisième couche de stockage.
Toute la migration a la même forme que cat file | wc -l. Le fait que les deux pipes vivent dans des datacenters différents est un détail d'implémentation de l'URL.
- zéro saut
- zéro stockage
- une URL
use-cases / move-200gb-between-clouds-with-two-curls / replaces
Ce que ça remplace
Tout ce qui existe seulement parce que personne n'avait un chemin HTTP qui stream. Le pipe écrase toute la stack de migration de données dans un curl de chaque côté.
- Copie AWS S3 inter-régionsDeux egress, un bucket, des règles lifecycle
- transfert Dropbox200 GB qui traîne sur le disque de quelqu'un d'autre pendant une semaine
- passation Google DriveMurs de quota, liens de partage, cleanup manuel
- rsync sur SSHSSH entre clouds aléatoires = bastions et échanges de clés
- SCP + repriseUn seul process, pas de fan-out, casse sur des liens instables
- Outils tiers de migration de donnéesUn vendor entier pour un curl avec des étapes en plus
use-cases / move-200gb-between-clouds-with-two-curls / cta
Sautez le bucket. Le transport est l'URL.
use-cases / move-200gb-between-clouds-with-two-curls / related