
一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
队友撞到一个你复现不了的 bug。跳过文件这步。你笔记本上的 pg_dump 直接流进对方 staging 上的 psql——无上传、无链接、无下载。管道把字节穿过去。
Hoody Pipe API 让一条未建立的管道最多挂五分钟,等另一端连接。两端连上,字节就流。服务器从不写盘。
# 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)带流式 body。服务器会把状态信息回打到你的终端,管道一建立就能看见——方便看出对方实际什么时候连上的。
# 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),dump 直接落到数据库——从不变成文件。
想看进度又不想占接收端席位,把第三条 curl 指向同一路径加 ?progress,就能拿到一个实时 HTML 仪表盘,显示已传字节、速度和 ETA。
把开发库塞进队友 staging,只要四步,且服务器上从不落盘。
“能把你的 dev 库发我吗?”搁昨天,这意味着 pg_dump、S3 桶、预签名 URL,再粘到 Slack。
pg_dump dev | curl -T - …/pipe/dev-snapshot终端打出“Waiting for 1 receiver to connect…”然后停在那。本地也不会创建文件。
curl …/pipe/dev-snapshot | pg_restore对方一连上,管道就建立。字节从你的 pg_dump 直接流进对方的 pg_restore。
Transfer complete · 服务器 0 字节服务端磁盘占用一直为零。两端一断开,管道路径就忘了这次传输。
命令数和走 S3 中转一样多——但少了桶、凭据、上传、下载和清理。
Hoody Pipe 是流式中介,不是文件服务。dump 在你盘上、也在对方盘上;中间只是飞行中的字节。无清理、无泄漏。
没有上传进度条要盯着,因为根本没上传。40 GB dump 以你的网络和对方 pg_restore 能顶住的速度走——管道只是转发。
用 ?progress 在第三个 URL 上打开同一路径,实时看已传字节、速度和 ETA。每条管道最多 50 个旁观者,都不占接收端席位。
数据库状态过去是附件。现在是路径。
文件是静止的状态。路径是运动的状态。Hoody Pipe 让数据库快照成为后者——可寻址、短生命周期,且不会留在服务器上让你回头收拾。
我们以前共享 dev 库用的大多数工具,都是当年还不能在两个终端之间通过 HTTP 流字节时留下的遗物。管道让它们都不必要。
两条 curl。一条路径。对方 staging 现在和你 dev 一致。