一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
use-cases / idle-staging-stops-getting-deleted / hero
容器 · 快照 · 闲置 = 免费
闲置 staging 不花钱,所以 staging 不再被删除
在 AWS 上,staging 会消亡,因为每一小时闲置都是计费小时。在 Hoody 上,闲置容器只占磁盘、不占 CPU——所以三周前你的评审同事碰过的那个 staging 还在,精确保留着他离开时的状态。坟场变成了工作集。
containers.hoody.com / staging-survivors
https://containers.hoody.com/staging-survivors最近 6 个月
环境周活跃 · 旧 → 新成本最后触达
- staging-pr-21485 days · idle since$0/月闲置期间@alex-pike112d ago
- staging-customer-acme6 days · sporadic$0/月闲置期间@miriam-ko32d ago
- staging-payments-rebuild21 days · then dropped$0/月闲置期间@dorian-vex168d ago
- staging-mobile-v318 days · current$0/月闲置期间@iris-hwa3d ago
- staging-launch-prep4 days · revived$0/月闲置期间@noor-sayed9d ago
月份
11 月12 月1 月2 月3 月4 月
闲置
短暂触达
活跃峰值
五个容器 · 总计约 54 个活跃日 · 五个环境仍可通过 URL 访问
use-cases / idle-staging-stops-getting-deleted / lifecycle
一个闲置容器实际在做什么
三种状态、一行容器、一份账单。活跃状态烧 CPU。闲置状态什么也不烧。唤醒状态需要几百毫秒,然后你的 staging 就以你离开时的样子回来了。
01 / 活跃
评审同事正在摆弄它
你的队友登录着,调用着新接口,盯着仪表盘。容器的进程被调度,内存页是热的,CPU 时间是真实的。这是唯一会让你掏钱的状态。
被关注期间计费
02 / 闲置
十天没人碰它
容器被挂起。它的文件系统仍然可解析,它的磁盘增量仍然存在,它的代理域名仍然响应。但没有被调度的进程,没有分配的 CPU 配额,没有计费给你的内存。它只是数据库里的一行和一个内容寻址的 blob——两者都免费。
闲置期间$0/月
03 / 唤醒
有人 ping 了 URL —— 它就回来了
第一个抵达的请求会唤醒容器。同样的容器 ID、同样的环境变量、同样的卷、同样的 SSH 主机。评审同事留下的状态就是回来的状态。无需恢复脚本,无需重新供应,无需再花一天重建你删掉的东西。
恢复时间几百毫秒
Hoody 只对活跃状态计费。闲置状态是容器生命的其余部分——而这正是任何 staging 环境绝大多数时间所处的状态。这就是你不再为之付费的那个状态。
use-cases / idle-staging-stops-getting-deleted / powers
这对 staging 改变了什么
一旦闲置免费,你就不再做那些 staging 替你做出的决定。
保留
你不再为了省钱删环境
三周前评审同事用过的环境还在那儿,被挂起,可通过容器 ID 寻址。CFO 看不到它,因为它不在账单里。原本以「三个砍俩」收尾的对话也就不再发生了。
速度
你不再重建你删掉的东西
评审同事 ping 一下 URL,容器醒来,会话恢复。无需重新供应、无需种子数据、无需等 Heroku dyno 从睡眠里醒过来。前一天下午的工作就是第二天下午的起点。
工作集
坟场变成工作集
上季度的发布 staging、被废弃的支付重构、Q4 那个客户专属的演示——它们都以零成本继续活着。当有人问「我们还有那个环境吗?」时,答案是「有」。
use-cases / idle-staging-stops-getting-deleted / ledger
CFO 以前看到什么,现在看到什么
一支永远开着的 staging 队伍在 AWS 发票上的条目,以及当闲置免费时,这些条目坍缩成了什么。
旧发票 · 永远开着按小时计费
- ec2 staging-pr-2148 · t3.medium · 720h
- ec2 staging-customer-acme · m5.large · 720h
- ec2 staging-payments-rebuild · t3.large · 720h
- rds staging-db cluster · 720h
- elb shared-staging-alb · 720h
- ebs gp3 attached volumes · 1.4 TB
新发票 · 闲置免费仅在活跃时计费
- container staging-pr-2148 · 闲置 22 周included
- container staging-customer-acme · 闲置 4 周included
- container staging-payments-rebuild · 闲置 24 周included
- container staging-mobile-v3 · 本周活跃included
- container staging-launch-prep · 闲置 1 周included
CFO 不会问那三个闲置环境的事,因为它们根本不出现。关于删它们的对话从未开始。
use-cases / idle-staging-stops-getting-deleted / numbers
容器这一行实际上保证了什么
数字来自 Hoody Containers API 和快照模型——不是编造的基准。
- 每月闲置$0
闲置容器不收每小时费。你为已经租用的裸金属和快照存储的磁盘增量买单——两者都是定额、且都很小。
- 磁盘占用delta
快照是内容寻址的,以增量方式存储。基础镜像在所有由它派生的容器之间共享;只有差异部分需要你付费。
- 从闲置中归来wake
GET /api/v1/containers/[id] 会解析被挂起的容器。第一个触达其代理域名的请求会唤醒它;你不再关注时它的状态,就是它返回时的状态。
根据 Hoody Containers API:容器以一行带 snapshot_count 和 last_used_snapshot 字段的记录形式存在。快照保留期默认遵循项目策略;expires_at 可按快照配置。
use-cases / idle-staging-stops-getting-deleted / punchline
Staging 得以存活,因为让它活着不再花钱。
之前 · 永远在线的账单之后 · 闲置那一行
CFO 以前看到什么$420/月 · 5× ec2 · 5× ebs · 闲置照样计费上季度删了两个环境,只为把图表画小一些
现在他们看到什么GET containers/staging-pr-2148 · 闲置 90 天 · 还在没有 cron 任务,没有清理 PR,也没有「以后可能还要用」的坟场
use-cases / idle-staging-stops-getting-deleted / replaces
这替换了什么
标准的「永远开着」staging 技术栈——以及围绕它生长出来的 cron 脚本和部落知识。每一项都按小时收费。Hoody 容器只按活跃小时收费,而 staging 的活跃时间几乎是空。
- AWS EC2 staging 实例永远计费,即使周日凌晨 03:00 没人在线
- Heroku staging dynos睡眠模式会丢失会话状态,唤醒还要付冷启动税
- Render staging 服务按服务每月收费,无论 URL 被访问一次还是一千次
- 自制的「staging-down」cron 任务一个 Lambda 删掉闲置 N 天以上的环境,加上 Slack 频道里大家追问自己的环境为什么不见了
- 「我们删掉了 staging」的技术债Notion 上一份「也许以后还要用」的环境列表,但都已经为了把图表压平而被销毁
- 大家抢着用的共享 staging十个评审者共用一个环境,因为三个就嫌贵——每天站会都在为踩到彼此分支而道歉
use-cases / idle-staging-stops-getting-deleted / cta
别再为了省钱删环境了。坟场现在是工作集。
use-cases / idle-staging-stops-getting-deleted / related
阅读其他内容
