1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
コンテナ·スナップショット
use-cases / send-a-teammate-a-database-state / hero
PIPE · ストリーム共有 · POSTGRES
1 行でチームメイトにデータベースの状態を送信
チームメイトがあなたが再現できないバグに当たる。ファイルをスキップ。あなたのラップトップの pg_dump が、彼らのステージングの psql に直接ストリーミング — アップロードなし、リンクなし、ダウンロードなし。パイプがバイトをそのまま通す。
dev
# stream the dump out$ pg_dump dev | curl -T - \ https://pipe…/dev-snapshot[INFO] Streaming to 1 receiver…
pipe/dev-snapshot0 バイト保存
staging
# pull the dump in$ curl https://pipe…/dev-snapshot \ | psql stagingINSERT 0 142 · done.
pipe/dev-snapshot0 バイト保存
use-cases / send-a-teammate-a-database-state / flow
1 つのパイプパス。2 つの curl。中間ファイルなし。
Hoody Pipe API は、もう片方が接続するのを待つ間、未確立のパイプを最大 5 分間保持する。両方が接続すると、バイトが流れる。サーバー上のディスクには何も書かれない。
pipe.containers.hoody.com/dev-snapshot
PUT · 送信側あなた · dev
pg_dump からダンプをストリーミング
# 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 (または POST)。パイプが確立されるとサーバーがステータスメッセージをターミナルに出力 — 反対側が実際にいつ接続したか確認できるので便利。
GET · 受信側チームメイト · staging
ダンプを直接 psql に取り込む
# 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 は送信側が接続するまでブロックする。送信側が書き込むバイトはレスポンスボディとして現れる。pg_restore (または psql) にパイプすると、ダンプはファイルではなく直接データベースに着地する。
n=1 · デフォルトのファンアウトパイプは最大 5 分待つサーバー上に 0 バイト保存
受信側スロットを消費せずに進捗を見たい場合は、3 つ目の curl を ?progress 付きで同じパスに向けると、転送バイト、速度、ETA を表示するライブ HTML ダッシュボードが得られる。
use-cases / send-a-teammate-a-database-state / steps
リアルタイムでの見え方
サーバー上のディスクに何も触れずに dev DB をチームメイトのステージングに取り込むのに必要な 4 つの動き。
Slack メッセージ → 復元された DB4 ステップ · 1 パイプ
10:14 · バグ報告01
チームメイトが再現できない
「あなたの dev db を送ってもらえる?」昨日まではこれは pg_dump、S3 バケット、署名済み URL、Slack 貼り付けを意味していた。
10:14 · PUT02
ダンプをストリーミング
pg_dump dev | curl -T - …/pipe/dev-snapshotターミナルが「Waiting for 1 receiver to connect…」を出力してそこに座る。ローカルにもファイルは作成されない。
10:15 · GET03
チームメイトが受信側を実行
curl …/pipe/dev-snapshot | pg_restore彼らが接続した瞬間にパイプが確立。バイトはあなたの pg_dump から彼らの pg_restore に直接流れ始める。
10:18 · 完了04
ステージングが dev と一致
Transfer complete · サーバー 0 バイトサーバーサイドのディスク使用量はゼロのまま。両側が切断した瞬間、パイプパスは転送が起こったことを忘れる。
use-cases / send-a-teammate-a-database-state / reasons
パスがファイルに勝る理由
S3 ラウンドトリップで入力するのと同じコマンド数 — バケット、認証情報、アップロード、ダウンロード、クリーンアップを除いて。
ストレージなし
サーバーは決してバイトを保持しない
Hoody Pipe はストリーミング仲介者であって、ファイルサービスではない。ダンプはあなたのディスクと相手のディスクに存在する; その間は飛行中のバイトに過ぎない。クリーンアップするものなし、漏洩するものなし。
大きなファイルなし
サイズは RAM ではなくパイプで制限
アップロードがないので、世話するアップロード進捗バーはない。40 GB のダンプは、あなたのネットワークと相手の pg_restore が維持できる速度で動く — パイプは単に転送する。
観察可能
?progress を追加してライブダッシュボード
3 つ目の URL で同じパスを ?progress 付きで開き、転送バイト、速度、ETA をリアルタイムで観察。パイプあたり最大 50 観戦者、誰も受信側スロットを消費しない。
use-cases / send-a-teammate-a-database-state / punchline
データベースの状態はかつて添付ファイルだった。今はパスだ。
ファイルは静止状態。パスは動きの中の状態。Hoody Pipe はデータベーススナップショットを後者にする — アドレス指定可能、エフェメラル、後でクリーンアップしなければならないサーバーに座らない。
- アップロードなし
- ダウンロードなし
- 共有するリンクなし
use-cases / send-a-teammate-a-database-state / replaces
これが置き換えるもの
dev データベースを共有するために使ってきたツールのほとんどは、HTTP 経由で 2 つのターミナル間でバイトをストリーミングできなかった時代の遺物。パイプはそれらをすべて不要にする。
- AWS S3 + 署名済み URLバケット、認証情報、アップロード、24 時間のリンク
- Dropbox / Google Driveサインイン、手動共有、同期待ち
- Slack ファイルアップロード30 MB キャップ、その後「本物のリンクを使ってください」
- WeTransfer 系サービスメールゲート、広告ページ、謎の保存期間
- Postgres dblink の回避策ステージングがライブで行をプルできるように dev へのポートを開く
- SSH 踏み台経由 rsync2 つの SSH 鍵、ジャンプホスト、両端の一時ファイル
use-cases / send-a-teammate-a-database-state / cta
2 つの curl。1 つのパス。彼らのステージングがあなたの dev と一致。
use-cases / send-a-teammate-a-database-state / related
他のユースケースを読む
