Sechzig Container auf einem Server
Eine Bare-Metal-Box führt Dutzende bis Hunderte von Hoody-Containern aus. KSM und BTRFS-Dedup machen die Marginalkosten nahezu null.
Containers·Snapshots
TypFreigeschaltetPhaseProduktionSchwierigkeitMittelAufgabeStream teilenFürBackend-DevsFürDevOps & InfraServicesPipeWarum HoodyHTTP-nativWarum HoodyContainer-Ökonomie
TypFreigeschaltetPhaseProduktionSchwierigkeitMittelAufgabeStream teilenFürBackend-DevsFürDevOps & InfraServicesPipeWarum HoodyHTTP-nativWarum HoodyContainer-Ökonomie
use-cases / move-200gb-between-clouds-with-two-curls / hero
PIPE · CROSS-CLOUD MIGRATION
200 GB zwischen Clouds mit zwei curls verschieben
Ein 200-GB-Postgres-Backup in Frankfurt. Eine frische Box in Singapur. Du sparst dir den S3-Round-Trip. Ein curl pipet pg_dump in eine Hoody-Pipe-URL; ein curl auf der anderen Seite streamt ihn direkt in psql. Bytes fliegen, sie ruhen nie.
src.frankfurt:~
QUELLE · LIVE
eu-fra-1 · Frankfurt# stream the dump out$ pg_dump db | gzip \ | curl -T - https://pipe.../migration[INFO] Streaming to 1 receiver(s)...
pipe/migration
dst.singapore:~
ZIEL · BEREIT
ap-sin-1 · Singapur# pipe straight into psql$ curl https://pipe.../migration \ | gunzip | psql newdb[INFO] Transfer complete.
200 GB · null Hops · null Hold
use-cases / move-200gb-between-clouds-with-two-curls / mechanism
Es ist kein Bucket. Es ist ein Router.
Hoody Pipe ist ein benannter Pfad auf einem HTTP-Server. Der Sender PUTet einen Stream darauf, der Empfänger GETet denselben Pfad, und der Server spliced die beiden zusammen. Nichts wird auf Disk geschrieben; die Pipe hält per Design null Bytes.
Bytes zwischen zwei curls5-MIN TTL · KEINE STORAGE-SCHICHT
01 · SENDER
PUT auf den Pfad
Von der Quell-Box: pg_dump | gzip | curl -T - auf die Pipe-URL. Der PUT-Body streamt so schnell, wie TCP-Backpressure es zulässt. Der Server hält die Verbindung, bis ein Empfänger auf demselben Pfad auftaucht.
PUT /api/v1/pipe/migration02 · ROUTER
Im Speicher splicen
Sobald der GET des Empfängers auf demselben Pfad landet, spliced Hoody die Bytes des Uploads direkt in die Response des Downloads. Kein Buffer, kein On-Disk-Staging, kein Async-Commit — nur ein direkter Stream zwischen zwei HTTP-Sockets.
0 Bytes auf Disk03 · EMPFÄNGER
Als Stream GETen
Von der Ziel-Box: curl GETet den Pfad und pipet die Response durch gunzip | psql. Der Empfänger-Stream endet in der Sekunde, in der das letzte Byte des Senders landet. Kein Retry, kein Manifest, kein Cleanup.
GET /api/v1/pipe/migrationDie Verbindungs-Reihenfolge ist egal — der Empfänger kann zuerst curlen und blockieren, bis der Sender verbindet (oder umgekehrt), bis zur 5-Minuten-Pipe-TTL. Backpressure fließt Ende-zu-Ende: ein langsames psql drosselt das curl auf der Quelle. Es gibt keine Queue, die überlaufen kann, weil es keine Queue gibt.
use-cases / move-200gb-between-clouds-with-two-curls / commands
Die tatsächlichen zwei Befehle
Das ist kein Pseudocode. Öffne zwei Terminals auf den zwei Servern, führe je einen aus und sieh zu, wie ein 200-GB-Backup eine Cloud verlässt und in einer anderen landet.
frankfurt:~ · sender
PUT · SENDERFrankfurt → 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:~ · receiver
GET · RECEIVERPipe → Singapur
# 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) wird bevorzugt, weil curl so einen Stream hochladen will. POST funktioniert identisch — selber Pfad, selbe Statusmeldungen. Verwende ?n=N auf beiden Seiten, falls du denselben Dump an viele Empfänger fan-outen willst.
use-cases / move-200gb-between-clouds-with-two-curls / spectator
PROGRESS · ?progress
Eine Spectator-URL, die jeder beobachten kann
Ein dritter Laptop öffnet dieselbe Pipe-URL mit ?progress und bekommt einen Echtzeit-SSE-Feed mit Bytes-pro-Sekunde, ETA und verbundenen Empfängern. Spectaten verbraucht keinen Empfänger-Slot — fünfzig Teammitglieder können der Migration zusehen, ohne den n-Wert zu ändern oder den Transfer zu stören.
- KEIN EMPFÄNGER-SLOT
- BIS ZU 50 SPECTATORS
- 30-MIN LINGER
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
Warum zwei curls sechs Schritte schlagen
Der S3-Round-Trip sieht auf einem Whiteboard simpel aus. In Produktion ist es ein Stack beweglicher Teile, die alle pro Sekunde abrechnen. Die Pipe kollabiert den ganzen Stack in den Transport selbst.
Keine dritte Storage-Schicht
S3, GCS, Azure Blob — der Round-Trip existiert nur, weil es keinen anderen Ort gab, um die Bytes zu parken. Die Pipe ist der Pfad. Es gibt keinen Bucket zum Provisionieren, mit Lifecycle-Regeln zu versehen oder hinterher zu putzen.
Bezahle für Flug, nicht für Ruhe
Egress beim Upload, Egress beim Download — zweimal. Mit der Pipe verlassen die Bytes Frankfurt und kommen in Singapur in einem Hop an. Du bezahlst die Sekunden, in denen die Verbindung offen war, nicht für Storage, den du morgen löschst.
HTTP von oben bis unten
Dein Monitoring versteht HTTP bereits. Genauso dein VPN, deine Firewall, dein Audit-Log. Keine neue IAM-Identität, kein neues SDK, kein neuer Failure-Mode — es ist ein curl-Befehl.
DIMENSIONS3 ROUND-TRIPHOODY PIPE
- Schritte6 Stages2 curls
- Disk-Verbrauch200 GB0 Bytes
- Egress-Beine2 × 200 GB1 × 200 GB
- CleanupLifecycle-Regelkeiner
Die Geschwindigkeit ist Ende-zu-Ende durch die langsamere Verbindung begrenzt (Frankfurt-Egress, Singapur-Ingress, dein TCP-Window). Die Hoody-Pipe hält null Bytes — es gibt keinen Server-seitigen Storage; Backpressure fließt direkt zwischen den beiden Endpoints.
use-cases / move-200gb-between-clouds-with-two-curls / punchline
Zwei Terminals, eine URL, keine dritte Storage-Schicht.
Die ganze Migration hat dieselbe Form wie cat file | wc -l. Dass die zwei Pipes zufällig in verschiedenen Rechenzentren leben, ist ein Implementierungsdetail der URL.
- null Hops
- null Hold
- eine URL
use-cases / move-200gb-between-clouds-with-two-curls / replaces
Was das ersetzt
Alles, was nur existiert, weil niemand einen HTTP-Pfad hatte, der streamt. Die Pipe kollabiert den gesamten Datenmigrations-Stack zu einem curl auf jeder Seite.
- AWS S3 Cross-Region-CopyZwei Egresses, ein Bucket, Lifecycle-Regeln
- Dropbox Transfer200 GB liegen eine Woche auf jemandes Disk
- Google Drive ÜbergabeQuoten-Wände, Share-Links, manuelles Aufräumen
- rsync über SSHSSH zwischen zufälligen Clouds = Bastions und Key-Tausch
- SCP + ResumeEin Prozess, kein Fan-out, bricht bei wackligen Verbindungen
- Drittanbieter-Datenmigrations-ToolsEin ganzer Vendor für ein curl mit Extra-Schritten
use-cases / move-200gb-between-clouds-with-two-curls / cta
Lass den Bucket weg. Der Transport ist die URL.
use-cases / move-200gb-between-clouds-with-two-curls / related
Lies die anderen
