1 つのサーバーで 60 のコンテナ
1 台のベアメタルで、数十から数百の Hoody コンテナを動かす。KSM と BTRFS の重複排除で、限界コストはほぼゼロ。
コンテナ·スナップショット
タイプアンロック
ステージ本番環境
難易度シンプル
ジョブストリームを共有
対象バックエンド開発者
対象開発チーム
サービスパイプ
Hoody の利点HTTP ネイティブ
タイプアンロック
ステージ本番環境
難易度シンプル
ジョブストリームを共有
対象バックエンド開発者
対象開発チーム
サービスパイプ
Hoody の利点HTTP ネイティブ
タイプアンロック
ステージ本番環境
難易度シンプル
ジョブストリームを共有
対象バックエンド開発者
対象開発チーム
サービスパイプ
Hoody の利点HTTP ネイティブ
タイプアンロック
ステージ本番環境
難易度シンプル
ジョブストリームを共有
対象バックエンド開発者
対象開発チーム
サービスパイプ
Hoody の利点HTTP ネイティブ
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