KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

04 · 什么时候别做私有化 — keel 龙骨

前三章你已经会打包、会落地了。这一章收口到一件更重要的事：什么时候不该做私有化交付。

前三章你已经会打包、会落地了。这一章收口到一件更重要的事：什么时候不该做私有化交付。

先看一眼这套形态最硬的那条约束长什么样：

docker network inspect board_data --format '{{.Name}} internal={{.Internal}} driver={{.Driver}}'
docker network inspect board_edge --format '{{.Name}} internal={{.Internal}} driver={{.Driver}}'

预期形状（两条，一条真一条假）：

board_data internal=true driver=bridge
board_edge internal=false driver=bridge

internal=true 就是没有出口：这张网上的容器连不到外面。
私有化的每一条设计都是从这一条倒逼出来的——如果你的场景里没有这一条，你就不该做私有化。

一、五类「别做私有化」的场景

1. 只有一个客户，或者根本只有你自己在用

私有化交付消掉的是「这套东西要送出去、落到别人的机器上」这件事。
如果它从头到尾只跑在你自己的一台机器上，那没有「送出去」，
打包、搬运、现场五步、升级回滚——整套动作都是空转。

判断句：这东西有没有离开过你的机器？ 答案是没有，私有化的收益接近零。

2. 客户机器能连外网

交付包存在的唯一理由是「没有出口」。客户那边能 docker pull、能在线装依赖，
那只 160M 的包就是白带的：现场直接拉官方镜像，比搬一只大包更省事、更新鲜。

3. 装一次就不动了

升级、回滚、迁移那一整套，是为了对付「结构会随时间变」。
如果这套东西装上去就再也不动（版本冻结、结构冻结），
那套可逆性设计没有对手，等于为不存在的变化买了保险。

4. 现场已经有一套在跑的平台

客户已经有一套编排/发布平台（甚至就是 K8s）在管机器，你再送一份自带 compose 的包进去，
两套东西会争同一批端口、同一批名字。这时候正确动作是把你的镜像接进他那套平台，
而不是在旁边再铺一层。

5. 你没法隔着距离把它托住

前四章所有的设计——自带全部输入、现场随机生成密钥、固定顺序、失败自检——
都建立在同一个假设上：出问题时，你不在那台机器前面。
如果你的现实是「出了问题只能飞过去、人必须守着」，
那私有化交付省下的远程排障能力，你本来也用不上。

一条把它们串起来的线索

这五条其实是同一句话的不同侧面，而且这条线索能从前三章的约束一步步推出来：

第 1 章：没有出口 ⇒ 全部输入必须自带，打成一个包。
第 2 章：包要由不在现场的人交接 ⇒ 安装要有序、可重复、能自检。
第 3 章：代码会变 ⇒ 包要能重打，而且版本必须自洽。

三条合起来，指向同一个前提：

私有化交付的全部复杂度，都服务于「你要隔着一段距离，把这套东西托住」。

所以拿到需求先问的不是「怎么打这个包」，而是这一句：
「送出去之后，我有没有能力、也有没有需要，隔着一段距离把它托住？」

二、一张速查表（判断时回来查）

三、它不是什么

• 「别做私有化」不等于「这套系统别交付」。 换一个交付形态就行——托管、公有云、
  或者干脆本地不隔离；这属于「选哪种形态」的问题，
  见《构建打包与部署上线》，本课从「已经选定私有化」之后开始。
• internal=true 也不是「更安全」的通用答案。 它只是「没有出口」这条约束的形态；
  在没有这条需求的场景里，它换来的是一整套额外的搬运与维护成本。

读完你能做什么

走到这里，这门课的目标就完成了：

• 能说清私有化部署解决的是「把一个自带的包送进没有出口的地方，让它自己活下去」；
• 能亲手把一只交付包跑起来，也能把自己的程序重新打进去；
• 能判断一件事该不该做私有化——这是这一章最想留给你的东西。

下一步去哪

• 想知道「用对」是什么样：《私有化交付工程》。
  它不讲「怎么跑起来」（你已经会了），直接进各环节的判断题。想先看最有价值的一章，
  从升级与回滚进去——
  那章讲怎么让升级只有「升上去」和「退回来」两种结局，也是本课的自然下一步。
• 想补容器基础：《Docker 基础课》。
  镜像、容器、-p 端口映射这些词，卡住时点进去。

这门课到这里就结束了。它刻意不长——你已经知道它是什么、边界在哪，
剩下的交给需要的时候再学。

进入 keel 阅读