一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
use-cases / move-200gb-between-clouds-with-two-curls / hero
PIPE · 跨云迁移
用两条 curl 在云之间搬 200GB
200GB Postgres 备份在法兰克福,新加坡有一台新机。跳过 S3 中转。一条 curl 把 pg_dump 管道送到 Hoody pipe URL;另一条 curl 在对面把它直接流进 psql。字节在飞行中,从不停歇。
src.frankfurt:~
源 · LIVE
eu-fra-1 · 法兰克福# stream the dump out$ pg_dump db | gzip \ | curl -T - https://pipe.../migration[INFO] Streaming to 1 receiver(s)...
pipe/migration
dst.singapore:~
目标 · 就绪
ap-sin-1 · 新加坡# pipe straight into psql$ curl https://pipe.../migration \ | gunzip | psql newdb[INFO] Transfer complete.
200GB · 零跳板 · 零滞留
use-cases / move-200gb-between-clouds-with-two-curls / mechanism
它不是桶。它是路由器。
Hoody Pipe 是 HTTP 服务器上一条命名路径。发送端用 PUT 把流送到它,接收端 GET 同一路径,服务器把两端拼接起来。什么都不写盘;管道按设计存零字节。
字节在两条 curl 之间5-MIN TTL · 无存储层
01 · SENDER
PUT 到路径
在源机上,pg_dump | gzip | curl -T - 到 pipe URL。PUT 体在 TCP 反压允许下尽快流。服务器在接收端到达同一路径前一直保持连接。
PUT /api/v1/pipe/migration02 · ROUTER
在内存里拼接
接收端的 GET 落到同一路径时,Hoody 把上传的字节直接拼进下载响应。无缓冲区、无落盘暂存、无异步提交——只是两个 HTTP 套接字之间的直接流。
0 bytes on disk03 · RECEIVER
以流的形式 GET
在目标机上,curl GET 路径,把响应管道送给 gunzip | psql。发送端最后一字节落下,接收端这一侧的流就结束。无重试、无清单、无清理。
GET /api/v1/pipe/migration连接顺序无所谓——接收端可以先 curl 并阻塞,等发送端到来(或反过来),最长可达 5 分钟管道 TTL。反压端到端流动:psql 慢就限到源端的 curl。没有队列要溢出,因为根本没有队列。
use-cases / move-200gb-between-clouds-with-two-curls / commands
实际的两条命令
这不是伪代码。在两台服务器上各开一个终端,各跑一条,然后看着 200GB 备份从一片云离开,落到另一片云。
frankfurt:~ · 发送端
PUT · SENDER法兰克福 → 管道
# 1. Stream the live database to the pipe$pg_dump --format=custom mydb | gzip \ | curl -T - https://pipe.containers.hoody.com/api/v1/pipe/migration# 2. The server replies with status messages[INFO] Waiting for 1 receiver(s) to connect...[INFO] Streaming to 1 receiver(s)...[INFO] Upload complete.[INFO] Transfer complete.
singapore:~ · 接收端
GET · RECEIVER管道 → 新加坡
# 1. Pipe straight into the new database$curl https://pipe.containers.hoody.com/api/v1/pipe/migration \ | gunzip | psql newdb# 2. Bytes hit psql as they leave FrankfurtCREATE TABLE okCOPY 4823918 okALTER TABLE ok
PUT(curl -T)更被推荐,因为 curl 本来就喜欢这样上传流。POST 同样可用——同路径、同状态信息。如果要把同一份 dump 扇出给多个接收端,两边都加 ?n=N。
use-cases / move-200gb-between-clouds-with-two-curls / spectator
PROGRESS · ?progress
任何人都能看的旁观 URL
第三台笔记本用同一 pipe URL 加 ?progress 打开,就拿到一份实时 SSE 流——每秒字节、ETA、已连接接收端。旁观不消耗接收端席位——五十个队友可以一起看迁移,不必改 n,也不影响传输。
- 不占接收端席位
- 最多 50 个旁观者
- 30 分钟驻留
spectator.…hoody.com/migration?progress
SSE · text/event-streamSTREAMING
event: statedata: ["state":"streaming","receivers":1]event: progressdata: ["bytes":83_421_667_840, "speed":"412 MB/s", "eta":"4m 44s"]event: progressdata: ["bytes":118_295_117_824, "speed":"406 MB/s", "eta":"3m 21s"]↻ live · 250ms throttle
use-cases / move-200gb-between-clouds-with-two-curls / why
为什么两条 curl 胜过六个步骤
S3 中转在白板上看着简单。生产里它是一堆按秒收费的部件。管道把整堆塌缩进运输本身。
无第三方存储层
S3、GCS、Azure Blob——中转之所以存在,是因为没有别的地方放字节。管道就是路径。无桶要预备、无生命周期规则、无事后清理。
为飞行付费,不为停留付费
上传出站、下载出站——两次。用管道,字节从法兰克福离开,一跳到达新加坡。你为连接打开的秒数付费,不为明天就要删的存储付费。
一路 HTTP 到底
你的监控已经懂 HTTP。VPN、防火墙、审计日志也都懂。无新 IAM 身份、无新 SDK、无新故障模式——它就是一条 curl。
维度S3 中转HOODY PIPE
- 步骤6 个阶段2 条 curl
- 占用磁盘200 GB0 字节
- 出站段2 × 200 GB1 × 200 GB
- 清理生命周期规则无
速度受较慢一端端到端约束(法兰克福出站、新加坡入站、你的 TCP 窗口)。Hoody 的管道存零字节——没有服务端存储;反压直接在两端之间流。
use-cases / move-200gb-between-clouds-with-two-curls / punchline
use-cases / move-200gb-between-clouds-with-two-curls / replaces
它替代了什么
凡是因为没人有一条会流的 HTTP 路径才存在的东西。管道把整套数据迁移栈塌缩成两端各一条 curl。
- AWS S3 跨区域复制两次出站、一个桶、生命周期规则
- Dropbox transfer200 GB 在别人盘上躺一周
- Google Drive 中转配额墙、分享链接、手动清理
- rsync over SSH在随机云之间走 SSH = 堡垒机和换密钥
- SCP + 续传单进程、无扇出、链路抖动就断
- 第三方数据迁移工具为一条加料 curl 引入整家厂商
use-cases / move-200gb-between-clouds-with-two-curls / cta
跳过桶。运输就是 URL。
use-cases / move-200gb-between-clouds-with-two-curls / related
阅读其他内容
