1 つのサーバーで 60 のコンテナ
1 台のベアメタルで、数十から数百の Hoody コンテナを動かす。KSM と BTRFS の重複排除で、限界コストはほぼゼロ。
コンテナ·スナップショット
タイプアンロック
ステージクイックウィン
難易度シンプル
ジョブストリームを共有
対象開発チーム
対象ソロ起業家
サービスパイプ
Hoody の利点HTTP ネイティブ
タイプアンロック
ステージクイックウィン
難易度シンプル
ジョブストリームを共有
対象開発チーム
対象ソロ起業家
サービスパイプ
Hoody の利点HTTP ネイティブ
タイプアンロック
ステージクイックウィン
難易度シンプル
ジョブストリームを共有
対象開発チーム
対象ソロ起業家
サービスパイプ
Hoody の利点HTTP ネイティブ
タイプアンロック
ステージクイックウィン
難易度シンプル
ジョブストリームを共有
対象開発チーム
対象ソロ起業家
サービスパイプ
Hoody の利点HTTP ネイティブ
use-cases / fastest-send-me-that-file / hero
PIPE · ストリーム共有 · ファイル転送
今までで最速の「あのファイル送って」
Slack は拒否します。Drive はフォルダ共有リクエストが必要です。メールは 25 MB で上限。2 つの curl — 1 つはあなたのラップトップで、もう 1 つは相手のラップトップで — がファイルをディスクからディスクへ移動します。パイプはバイトをルーティングし、サーバーには何もアップロードされません。
従来の方法8 分 14 秒
- 01新しいタブで Dropbox を開く
- 02ログイン (および 2FA プロンプト)
- 03アップロードをクリック、4 GB ファイルを選択
- 04アップロードのプログレスバーを待つ
- 05ファイルを右クリック、共有リンクをコピー
- 06リンクをチャットに貼り戻す
6 つのタブ · 3 つのログイン · 1 つの共有リンク
新しい方法12 秒
01 · SENDERcurl -T file.zip https://pipe.../api/v1/pipe/dump-yesterday
02 · RECEIVERcurl https://pipe.../api/v1/pipe/dump-yesterday > file.zip
アップロードなし · リンクなし · ダウンロードタブなしバイトはディスク間を移動
use-cases / fastest-send-me-that-file / flow
1 つのパイプパス。2 つの curl。中間ファイルなし。
同じパスに対して GET と PUT を実行します。Hoody Pipe は最初に接続した側を最大 5 分間保持し、もう一方が現れるとバイトはストリームでまっすぐ通り抜けます。サーバーのディスクには何も書き込まれません。
pipe.containers.hoody.com/dump-yesterday
PUT · 送信者あなた
curl からファイルを押し出す
# from your laptopcurl -T dump.sql \ https://pipe.containers.hoody.com/api/v1/pipe/dump-yesterday[INFO] Waiting for 1 receiver to connect…[INFO] Streaming to 1 receiver…[INFO] Transfer complete.
ストリーミング本文を伴う PUT (または POST)。サーバーはパイプが確立されるとステータス行を返します — 相手が実際に受け取ったというライブシグナルとして役立ちます。
GET · 受信者相手
ファイルを直接ディスクに引き込む
# on their boxcurl \ https://pipe.containers.hoody.com/api/v1/pipe/dump-yesterday \ -o dump.sql# 4.2 GB · saved · done.
同じパスに対する GET は、送信者が接続するまでブロックされます。送信者が書き込むバイトはレスポンス本文として現れます — -o でファイルにパイプするか、読み取るあらゆるプログラムの stdin にパイプします。
n=1 · デフォルト 1 対 1 転送パイプは最大 5 分間待機サーバーに 0 バイト保存
順序は問題ではありません。あなたが先に curl を実行すれば、リクエストは相手が接続するまでブロックされます。相手が先に curl を実行すれば、相手側がブロックされます。いずれにせよ、両端が接続した瞬間にバイトが移動し始めます。
use-cases / fastest-send-me-that-file / steps
リアルタイムでどう見えるか
Slack の通知から相手のディスクに届くファイルまで — パイプが起こす 4 つの動き。
Slack 通知 → 相手のマシン上のファイル4 ステップ · 1 つのパイプ
10:14 · PING01
チームメイトがファイルを要求
「昨日の本番ダンプを送ってもらえる?」ファイルは 4 GB です。Slack は拒否し、共有ドライブはフォルダ共有チケットが必要です。どちらにも手を伸ばすのをやめます。
10:14 · PUT02
curl -T でファイルを送り出す
curl -T dump.sql …/pipe/dump-yesterdayターミナルに「Waiting for 1 receiver to connect…」と表示され、そのまま待機します。URL をチャットに貼り付けます: 「これを実行して」。
10:15 · GET03
相手が URL を curl で引き込む
curl …/pipe/dump-yesterday > dump.sql相手が接続した瞬間にパイプが確立されます。バイトはあなたのディスクからパイプを経由して相手のディスク上のファイルにストリーミングされ始めます。
10:15 · DONE04
相手のマシン上にファイル、何も残らない
Transfer complete · サーバーに 0 バイトサーバー側のディスク使用量はゼロのままです。両端が切断された瞬間、パイプパスは転送が起こったことを忘れます。
use-cases / fastest-send-me-that-file / reasons
なぜ curl が共有を打ち負かすのか
Drive のラウンドトリップで打つのと同じ数のコマンド — ログイン、アップロードバー、リンク、クリーンアップを引いたもの。
アップロードなし
見るプログレスバーがない
Hoody Pipe はストリーミング中継であり、ファイルサービスではありません。ファイルはあなたのディスクと相手のディスクに存在します。その間は、2 つのネットワークが維持できる速度で飛行中のバイトに過ぎません — パイプはただ転送するだけです。
ログインなし
アカウントなし、フォルダ共有なし、IT チケットなし
パイプパスはパブリックデプロイメントで認証を必要としません。1 回の転送にスコープされたアドレス可能な URL です。両端が切断されると、パスは消えます。受信者が登録するものはありません。
残骸なし
サーバーは常にゼロバイトしか保存しない
転送はサーバー上のディスクに到達することはありません。クリーンアップするものも、漏洩するものも、有効期限を切るものもありません。バイトはあなたのラップトップにあり、その後相手のラップトップにもあり、パスは存在したことを忘れます。
use-cases / fastest-send-me-that-file / punchline
2 つの curl。ログインなし。アップロードバーなし。完了。
「あのファイル送って」はかつて、タブ、サインイン、アップロード、リンク、貼り付け、ダウンロードを意味していました。今はこう意味します: curl と入力し、URL を貼り付け、curl を実行する。今までで最速のバージョンです。
- アップロードなし
- 共有するリンクなし
- 両端でログインなし
use-cases / fastest-send-me-that-file / replaces
これが置き換えるもの
4 GB のファイルを送るために使っていたツールのほとんどは、HTTP 上で 2 つのターミナル間でバイトをストリーミングできなかった時代の遺物です。パイプはそれらすべてを不要にします。
- Dropboxサインイン、手動共有、同期待ち
- Google DriveIT 経由のフォルダ権限チケット
- Slack ファイルアップロードサイズの厳しい上限、その後「実際のリンクを使ってください」
- WeTransferメールゲート、広告ページ、謎の保持期間
- AirDrop (ネットワークをまたぐ)同じ Wi-Fi のみ、リモートになると失敗
- Firefox Sendシャットダウンされ、戻ってこなかった
- カスタムファイル共有セルフホストボックス、バケット、有効期限を切るのを忘れた cron
use-cases / fastest-send-me-that-file / cta
2 つの curl。ファイルは相手のマシン上にあります。何もアップロードされませんでした。
use-cases / fastest-send-me-that-file / related