KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

01 · 它到底解决了什么问题 — keel 龙骨

## 现场：包搬进去了，它却报「网络问题」

现场：包搬进去了，它却报「网络问题」

一套系统在你自己的机器上跑得好好的。客户那边有一台不能连外网的机器，
你把整套东西打包搬过去，敲 docker compose up，屏幕上先出现一行：

 Image board:1.0.0 Pulling

然后它开始等。等了几十秒，最后落到这一句：

 Image board:1.0.0 Error unknown: failed to resolve reference "docker.io/library/board:1.0.0":
   unexpected status from HEAD request to http://hub-mirror.c.163.com/...: 502 Bad Gateway
Error response from daemon: No such image: board:1.0.0

屏幕上写的是网络，但真相跟网络无关：这个镜像根本没有进到这台机器上。
（镜像是一份「装好的、能整只搬走的运行环境」；容器是把它跑起来的那一次。）
compose 的默认动作是「本地找不到就去仓库取」，而这台机器没有通向外面的路，
于是它只能一直等到超时——看起来像网络抖了一下，其实是制品没到。

这就是私有化交付的起点：你要交付的那套东西，运行在一个你进不去、也不该假设有外网的地方。

一、普通部署默认了什么

「部署」平时建立在一串默认前提上：

• 目标机器能连外网（缺什么就现装什么）；
• 出错时你能连上去看（ssh 过去、翻日志）；
• 一次失败可以重来（下载断了再拉一次就好）。

只要这些前提里还有一条成立，你做的就是「部署」。一旦它们同时不成立，做的就换了一件事。

二、私有化部署做了什么

一句话定义：

私有化部署，是把一次安装所需的全部输入打成一个自带的包，搬进一个没有出口的地方，
让这套东西在那里按固定顺序自己起来、自己自检、自己升级、失败了自己退回来。

先认三个词，后面每一章都会用到：

这条命令就是「包里到底装了什么」：

tar -tzf board-delivery-1.0.0.tar.gz | sed -n '1,10p'

预期形状——包根下面就是全部输入：

board-delivery-1.0.0/MANIFEST.sha256
board-delivery-1.0.0/compose.yml
board-delivery-1.0.0/env.example
board-delivery-1.0.0/images/board__1.0.0.tar
board-delivery-1.0.0/images/postgres__16-alpine.tar
board-delivery-1.0.0/install.sh
board-delivery-1.0.0/selfcheck.sh
...

前置：这条命令要看的是第 2 章会用到的那只交付包，手边还没有就先读完第 2 章。
读的是形状：一份哈希清单、两只镜像 tar、一份编排、一份配置模板、一串脚本——
没有一项需要现去网上取。（其中的 compose.yml 是编排文件：
它描述这几个容器各跑什么、按什么顺序起。）

这条链路长这样：

flowchart LR
  A["我们这边（有外网）<br/>打成交付包"] --> B["一段没有出口的路<br/>靠介质搬进去"]
  B --> C["客户内网（无外网）<br/>包里的输入自己起"]

它解释了开头那个现场：交付包把「需要外网」的那一段，全部提前到了它被打出来的那一刻。

三、它不是什么

• 不是「把服务装到更远的一台服务器上」。 部署的前提是那张网还在，私有化的前提是它不在了。
  这一条差别决定了包里放什么、脚本为什么不能问任何交互问题。
• 不是「我们派人驻场」。 私有化交付的核心恰恰是人不在现场：所以它必须自带全部输入、
  自己会自检——这两件事在第 2、3 章各有落地，第 4 章告诉你什么时候根本不需要它们。

读完你能做什么

• 用一句话说清私有化部署解决的是「把一个自带的包，送进一个没有出口的地方，让它自己活下去」；
• 说出 交付包、内网隔离、实例 三个词各指什么，并各举一个能看见的形态；
• 说清那次「报网络问题」的真正原因是制品没到，而不是网络抖。

下一步：现在你知道它是什么了。下一章把包真的跑起来——
一条 ./install.sh，看它把五件事按什么顺序做完。

进入 keel 阅读