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
TypFreigeschaltetPhaseProduktionSchwierigkeitEinfachAufgabeStream teilenFürBackend-DevsFürDev TeamsServicesPipeWarum HoodyHTTP-nativ
TypFreigeschaltetPhaseProduktionSchwierigkeitEinfachAufgabeStream teilenFürBackend-DevsFürDev TeamsServicesPipeWarum HoodyHTTP-nativ
use-cases / send-a-teammate-a-database-state / hero
PIPE · SHARE STREAMS · POSTGRES
Schicke einem Teammitglied einen Datenbank-Stand in einer Zeile
Ein Teammitglied trifft auf einen Bug, den du nicht reproduzieren kannst. Spar dir die Datei. pg_dump auf deinem Laptop streamt direkt in dessen psql auf Staging — kein Upload, kein Link, kein Download. Die Pipe leitet die Bytes durch.
dev
# stream the dump out$ pg_dump dev | curl -T - \ https://pipe…/dev-snapshot[INFO] Streaming to 1 receiver…
pipe/dev-snapshot0 Bytes gespeichert
staging
# pull the dump in$ curl https://pipe…/dev-snapshot \ | psql stagingINSERT 0 142 · done.
pipe/dev-snapshot0 Bytes gespeichert
use-cases / send-a-teammate-a-database-state / flow
Ein Pipe-Pfad. Zwei curls. Keine Datei dazwischen.
Die Hoody-Pipe-API hält eine unetablierte Pipe bis zu fünf Minuten, während sie auf die andere Seite wartet. Sobald beide verbunden sind, streamen die Bytes hindurch. Auf dem Server wird nie etwas auf Disk geschrieben.
pipe.containers.hoody.com/dev-snapshot
PUT · SENDERdu · dev
Den Dump aus pg_dump rausstreamen
# from your dev laptoppg_dump --format=custom dev \ | curl -T - \ https://pipe.containers.hoody.com/api/v1/pipe/dev-snapshot[INFO] Waiting for 1 receiver to connect…[INFO] Streaming to 1 receiver…[INFO] Transfer complete.
PUT (oder POST) mit einem streamenden Body. Der Server druckt Statusmeldungen zurück in dein Terminal, während die Pipe sich aufbaut — praktisch, damit du siehst, wann die andere Seite tatsächlich verbunden hat.
GET · RECEIVERTeammitglied · staging
Den Dump direkt in psql ziehen
# on their staging shellcurl https://pipe.containers.hoody.com/api/v1/pipe/dev-snapshot \ | pg_restore -d staging# rows imported · staging now matches dev
GET auf demselben Pfad blockiert, bis der Sender verbindet. Die Bytes, die der Sender schreibt, erscheinen als Response-Body. Pipe das in pg_restore (oder psql) und der Dump landet direkt in der Datenbank — niemals als Datei.
n=1 · Default-Fan-outPipe wartet bis zu 5 Minuten0 Bytes auf dem Server gespeichert
Wenn du den Fortschritt beobachten willst, ohne einen Empfänger-Slot zu verbrauchen, richte einen dritten curl mit ?progress auf denselben Pfad und du bekommst ein Live-HTML-Dashboard mit übertragenen Bytes, Geschwindigkeit und ETA.
use-cases / send-a-teammate-a-database-state / steps
Wie das in Echtzeit aussieht
Die vier Bewegungen, die es braucht, um eine Dev-DB ins Staging deines Teammitglieds zu bekommen, ohne dass jemals etwas auf einem Server die Disk berührt.
Slack-Nachricht → wiederhergestellte DBVIER SCHRITTE · EINE PIPE
10:14 · BUG REPORT01
Teammitglied kann nicht reproduzieren
„kannst du mir deine Dev-DB schicken?“Gestern hieß das pg_dump, S3-Bucket, presigned URL und ein Slack-Paste.
10:14 · PUT02
Du streamst den Dump raus
pg_dump dev | curl -T - …/pipe/dev-snapshotDein Terminal druckt „Waiting for 1 receiver to connect…“ und sitzt da. Es wird auch lokal keine Datei angelegt.
10:15 · GET03
Teammitglied startet den Empfänger
curl …/pipe/dev-snapshot | pg_restoreDie Pipe etabliert sich in dem Moment, in dem sie verbinden. Bytes fließen aus deinem pg_dump direkt in deren pg_restore.
10:18 · DONE04
Staging matcht jetzt Dev
Transfer complete · 0 Bytes auf dem ServerServer-seitiger Disk-Verbrauch bleibt bei null. Der Pipe-Pfad vergisst, dass der Transfer stattfand, sobald beide Seiten trennen.
use-cases / send-a-teammate-a-database-state / reasons
Warum ein Pfad eine Datei schlägt
Es ist dieselbe Anzahl Befehle, die du für einen S3-Round-Trip tippen würdest — minus Bucket, Credential, Upload, Download und Cleanup.
KEIN STORAGE
Der Server hält die Bytes nie
Hoody Pipe ist ein streamender Vermittler, kein Datei-Service. Der Dump existiert auf deiner Disk und auf ihrer; dazwischen sind es nur Bytes im Flug. Nichts aufzuräumen, nichts zu leaken.
KEINE GROSSEN DATEIEN
Größe ist von der Pipe begrenzt, nicht vom RAM
Es gibt keine Upload-Fortschrittsanzeige zu babysitten, weil es keinen Upload gibt. Ein 40-GB-Dump bewegt sich mit dem Tempo, das dein Netzwerk und deren pg_restore halten können — die Pipe leitet einfach durch.
BEOBACHTBAR
Häng ?progress an für ein Live-Dashboard
Öffne denselben Pfad mit ?progress in einer dritten URL und sieh übertragene Bytes, Geschwindigkeit und ETA in Echtzeit. Bis zu 50 Spectators pro Pipe, keiner verbraucht einen Empfänger-Slot.
use-cases / send-a-teammate-a-database-state / punchline
Datenbank-Stand war früher ein Anhang. Jetzt ist er ein Pfad.
Dateien sind Zustand in Ruhe. Pfade sind Zustand in Bewegung. Hoody Pipe lässt einen Datenbank-Snapshot zum Zweiten werden — adressierbar, ephemer und nie auf einem Server liegend, den du später aufräumen musst.
- kein Upload
- kein Download
- kein Link zum Teilen
use-cases / send-a-teammate-a-database-state / replaces
Was das ersetzt
Die meisten Tools, mit denen wir eine Dev-Datenbank geteilt haben, sind Überreste aus der Zeit, als wir keine Bytes zwischen zwei Terminals über HTTP streamen konnten. Die Pipe macht sie alle überflüssig.
- AWS S3 + presigned URLEin Bucket, ein Credential, ein Upload und ein 24-Stunden-Link
- Dropbox / Google DriveLogin, manueller Share, auf Sync warten
- Slack-File-Uploads30-MB-Limit, dann „bitte einen echten Link verwenden“
- WeTransfer-artige DiensteE-Mail-Gates, Werbeseiten, mysteriöse Retention-Fenster
- Postgres dblink-WorkaroundsEinen Port nach Dev öffnen, damit Staging Live-Zeilen ziehen kann
- rsync über SSH-BastionZwei SSH-Keys, ein Jump-Host und eine Temp-Datei auf jeder Seite
use-cases / send-a-teammate-a-database-state / cta
Zwei curls. Ein Pfad. Ihr Staging matcht jetzt dein Dev.
use-cases / send-a-teammate-a-database-state / related
Lies die anderen
