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.
Containers·Snapshots
TypeDéverrouilléÉtapeProductionDifficultéModéréTravailPartager un fluxPourDevs backendPourDevOps & infraServicesPipePourquoi HoodyHTTP-natifPourquoi HoodyÉconomie des conteneurs
TypeDéverrouilléÉtapeProductionDifficultéModéréTravailPartager un fluxPourDevs backendPourDevOps & infraServicesPipePourquoi HoodyHTTP-natifPourquoi HoodyÉconomie des conteneurs
use-cases / move-200gb-between-clouds-with-two-curls / hero
PIPE · MIGRATION CROSS-CLOUD
Déplacez 200 Go entre clouds avec deux curl
Une sauvegarde Postgres de 200 Go à Francfort. Une nouvelle machine à Singapour. Vous sautez l'aller-retour S3. Un curl envoie pg_dump vers une URL Hoody Pipe ; un curl de l'autre côté streame directement dans psql. Les octets sont en vol, jamais au repos.
src.frankfurt:~
SOURCE · LIVE
eu-fra-1 · Francfort# stream the dump out$ 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 straight into psql$ curl https://pipe.../migration \ | gunzip | psql newdb[INFO] Transfer complete.
200 Go · zéro saut · zéro rétention
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'émetteur PUT un flux dessus, le récepteur GET le même chemin, et le serveur épisse les deux ensemble. Rien n'est écrit sur disque ; le pipe retient zéro octet par conception.
Des octets entre deux curlTTL 5 MIN · PAS DE COUCHE DE STOCKAGE
01 · ÉMETTEUR
PUT vers le chemin
Depuis la machine source, pg_dump | gzip | curl -T - vers l'URL pipe. Le corps du PUT streame aussi vite que le backpressure TCP le permet. Le serveur garde la connexion jusqu'à ce qu'un récepteur arrive sur le même chemin.
PUT /api/v1/pipe/migration02 · ROUTEUR
Épissage en mémoire
Quand le GET du récepteur arrive sur le même chemin, Hoody épisse les octets de l'upload directement dans la réponse du download. Pas de buffer, pas de staging sur disque, pas de commit asynchrone — juste un flux direct entre deux sockets HTTP.
0 octet sur disque03 · RÉCEPTEUR
GET en flux
Depuis la machine de destination, curl GET le chemin et envoie la réponse dans gunzip | psql. Le flux côté récepteur se termine à la seconde où le dernier octet de l'émetteur arrive. Pas de retry, pas de manifeste, pas de nettoyage.
GET /api/v1/pipe/migrationL'ordre de connexion n'a pas d'importance — le récepteur peut faire curl en premier et bloquer jusqu'à ce que l'émetteur se connecte (ou inversement), jusqu'au TTL pipe de 5 minutes. Le backpressure circule de bout en bout : un psql lent freine le curl à la source. Il n'y a pas de file d'attente à déborder parce qu'il n'y a pas de file d'attente.
use-cases / move-200gb-between-clouds-with-two-curls / commands
Les deux commandes réelles
Ce ne sont pas du pseudo-code. Ouvrez deux terminaux sur les deux serveurs, lancez une commande sur chaque, et regardez une sauvegarde de 200 Go quitter un cloud et atterrir dans un autre.
frankfurt:~ · émetteur
PUT · ÉMETTEURFrancfort → pipe
# 1. Stream the live database to the pipe$pg_dump --format=custom mydb | gzip \ | curl -T - https://pipe.containers.hoody.com/api/v1/pipe/migration# 2. The server replies with status messages[INFO] Waiting for 1 receiver(s) to connect...[INFO] Streaming to 1 receiver(s)...[INFO] Upload complete.[INFO] Transfer complete.
singapore:~ · récepteur
GET · RÉCEPTEURpipe → Singapour
# 1. Pipe straight into the new database$curl https://pipe.containers.hoody.com/api/v1/pipe/migration \ | gunzip | psql newdb# 2. Bytes hit psql as they leave FrankfurtCREATE TABLE okCOPY 4823918 okALTER TABLE ok
PUT (curl -T) est préféré parce que c'est ainsi que curl veut uploader un flux. POST fonctionne à l'identique — même chemin, mêmes messages de statut. Utilisez ?n=N des deux côtés si vous devez fan-out le même dump vers plusieurs récepteurs.
use-cases / move-200gb-between-clouds-with-two-curls / spectator
PROGRESSION · ?progress
Une URL spectatrice que tout le monde peut regarder
Un troisième laptop ouvre la même URL pipe avec ?progress et reçoit un flux SSE en temps réel d'octets-par-seconde, ETA et récepteurs connectés. Spectateur ne consomme pas un slot de récepteur — cinquante coéquipiers peuvent regarder la migration sans changer la valeur de n ni interférer avec le transfert.
- PAS DE SLOT RÉCEPTEUR
- JUSQU'À 50 SPECTATEURS
- RÉMANENCE 30 MIN
spectator.…hoody.com/migration?progress
SSE · text/event-streamSTREAMING
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 · 250ms throttle
use-cases / move-200gb-between-clouds-with-two-curls / why
Pourquoi deux curl 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 rassemble 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 pour garer les octets. Le pipe est le chemin. Il n'y a pas de bucket à provisionner, à régler par règle de cycle de vie ni à nettoyer après.
Payez le vol, pas le repos
Egress sur l'upload, egress sur le download — deux fois. Avec le pipe les octets quittent Francfort et arrivent à Singapour en un saut. Vous payez les secondes pendant lesquelles la connexion était ouverte, pas un stockage que vous supprimerez demain.
HTTP de bout en bout
Votre monitoring comprend déjà HTTP. Votre VPN, votre pare-feu et votre journal d'audit aussi. Pas de nouvelle identité IAM, pas de nouveau SDK, pas de nouveau mode de défaillance — c'est une commande curl.
DIMENSIONALLER-RETOUR S3HOODY PIPE
- Étapes6 stages2 curl
- Disque utilisé200 Go0 octet
- Trajets d'egress2 × 200 Go1 × 200 Go
- Nettoyagerègle de cycle de vieaucun
La vitesse est limitée par le maillon le plus lent de bout en bout (egress Francfort, ingress Singapour, votre fenêtre TCP). Le pipe Hoody retient zéro octet — il n'y a pas de stockage côté serveur ; le backpressure circule directement entre les deux extrémités.
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 centres de données différents est un détail d'implémentation de l'URL.
- zéro saut
- zéro rétention
- une URL
use-cases / move-200gb-between-clouds-with-two-curls / replaces
Ce que cela remplace
Tout ce qui n'existe que parce que personne n'avait un chemin HTTP qui streame. Le pipe rassemble toute la pile de migration de données dans un curl de chaque côté.
- Copie cross-region AWS S3Deux egress, un bucket, des règles de cycle de vie
- Transfert Dropbox200 Go restent une semaine sur le disque de quelqu'un d'autre
- Échange via Google DriveMurs de quota, liens de partage, nettoyage manuel
- rsync sur SSHSSH entre clouds aléatoires = bastions et échanges de clés
- SCP + repriseUn seul processus, pas de fan-out, casse sur des liens instables
- Outils de migration tiersTout un éditeur 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
Découvrez les autres
