13 - 为什么后端要打成 Docker 再上 Serverless

上一章知道了后端要交给 Serverless 跑。但中间还有一步关键动作：先把后端打成 Docker 镜像。这一章讲清楚为什么，以及”镜像 → Serverless”这条路是怎么走的。

先回顾：Docker 镜像是什么

（详见 Docker 入门）一句话：

Docker 镜像 = 你的代码 + 它需要的所有运行环境（Python 版本、依赖库、系统配置）打包成的一个标准”集装箱”。

拿到这个镜像的任何机器，都能一模一样地把你的应用跑起来，不用再装环境。

为什么要”先打成镜像”？

原因一：环境跟着代码走，彻底告别”装环境”

传统方式部署后端，要在服务器上装 Python、装依赖、配环境——又慢又容易出错（第 01、02 章的痛点）。

有了 Docker 镜像，环境已经打包在镜像里了。Serverless 平台拿到镜像直接跑，根本不需要”装环境”这一步。你本地能跑的镜像，线上就能一模一样地跑。

原因二：镜像是”标准交付物”，平台能直接消费

Serverless 平台不认识你项目的具体结构，但它认识 Docker 镜像这个标准格式。你交出一个镜像，它就知道怎么拉起来。

类比：镜像就像标准集装箱。不管里面装的是 FastAPI 还是 Node，Serverless 这台”吊车”都能用同样的方式吊起来跑。

原因三：本地、CI、线上完全一致

同一个镜像，在你电脑、在 CI 流水线、在线上跑的都是同一个东西。彻底消灭”在我电脑上是好的呀”。

“镜像 → Serverless”这条路怎么走

完整链路是这样（大部分由 CI/CD 自动完成）：

写 Dockerfile → docker build 出镜像 → 推到镜像仓库 → Serverless 拉取并运行

1. 写 Dockerfile：描述”怎么把你的后端打成镜像”（用哪个 Python、装哪些依赖、启动命令是什么）
2. docker build：按 Dockerfile 造出镜像
3. 推到镜像仓库：镜像仓库是云厂商提供的”存镜像的地方”（阿里云 ACR、腾讯云 TCR）。把镜像推上去
4. Serverless 拉取运行：告诉 Serverless 平台”用这个镜像”，它就拉下来、启动实例、开始处理请求

[配图：Dockerfile → 镜像 → 镜像仓库 → Serverless 实例，四个环节的流水线，标注”这一整条通常由 CI/CD 自动跑”]

两种 Serverless 形态（了解即可）

后端上 Serverless，实践中主要有两种形态，都支持 Docker 镜像：

对我们这种”用 FastAPI 写的后端 + Docker 镜像”，Serverless 容器这一类通常更顺手（直接跑镜像、支持常驻 HTTP 服务）。选型见附录。

把它接回 CI/CD 和全景图

回顾第 08 章后端支线：docker build → 推镜像仓库 → 部署 Serverless。现在你完全理解了每一步：

• build 是为了得到”环境自带的标准成品”
• 推仓库是为了让 Serverless 能拿到它
• 部署就是让 Serverless 用新镜像替换旧的

小结

• 后端上 Serverless 前要先打成 Docker 镜像，因为：环境跟着代码走、镜像是平台能直接消费的标准交付物、三端一致。
• 完整链路：Dockerfile → build 镜像 → 推镜像仓库 → Serverless 拉取运行（通常 CI/CD 自动完成）。
• Serverless 有”函数计算”和”Serverless 容器”两种形态，跑 FastAPI 镜像通常选后者。

镜像和 Serverless 都懂了，但 Serverless 也有它的”脾气”。下一章讲冷启动、伸缩、计费，让你知道它的优势和坑。

下一章 → 14 - 冷启动、伸缩、计费：Serverless 的脾气