为什么使用 Docker 镜像（而不是直接在宿主机跑 Node）

更新: 7/22/2026字数: 0 字 时长: 0 分钟

mylab 版本 v1.0 | 2026-07-22 适用读者：想搞懂「镜像到底是干嘛的、为什么不直接在 ECS 上装 Node 跑」的部署新手

一、先说结论

对于 mylab 这样的 Next.js 站点，「把应用打包成 Docker 镜像、在容器里运行」并不是为了炫技，而是为了解决一个很现实的问题：

宿主机环境不可控、构建太吃资源、多项目容易互相污染。

镜像的本质，是把「应用 + 它运行所需的一切环境」打包成一个可移植的文件。谁拿到这个文件，在任意装了 Docker 的机器上都能原样跑起来，且跑出来的结果一致。

二、镜像（Image）到底是什么

可以把镜像理解成「一台装好环境、配好应用的只读快照」。

类比	镜像	容器
面向对象	class（类）	instance（实例）
做菜	菜谱 + 备好的料	按菜谱做出来的那盘菜
虚拟机	模板 / 母盘	从模板克隆出来的虚拟机

• 镜像（Image）：静态文件，包含操作系统基础层、Node 运行时、依赖、编译好的代码（本项目是 Next.js standalone 产物）。
• 容器（Container）：镜像运行起来的实例，是真正在干活的程序进程。

关键点：镜像是「一次构建、到处运行」的交付物。我在 GitHub 的 Runner 上 docker build 出一份镜像，ECS 上 docker pull 下来 docker run，跑出来的东西和我在 Runner 上跑的完全一样——环境差异被封死在镜像里了。

三、镜像到底起了什么作用

3.1 环境一致性（最重要）

不在宿主机直接跑 Node，最大的好处是不再受宿主机环境影响：

• 宿主机装的是 Node 18，项目要 Node 20？镜像里自带 Node 20，互不干扰。
• 项目锁定 pnpm@9.15.4，镜像里就用这个版本，不依赖宿主机的 pnpm / corepack。
• 系统库缺失、glibc 版本不对、Python 版本不符……这些问题在镜像构建阶段就暴露并解决，不会出现「我本地能跑、服务器上跑不了」。

3.2 自带运行环境，宿主机零污染

镜像把所有依赖（包括 node_modules、Next.js runtime）都封在里面。宿主机不需要预装 Node、pnpm、编译工具链。

• 部署一台新 ECS，只要装 Docker，就能跑 mylab；
• 不往系统目录塞一堆全局包，卸载/重装就是删容器，不会残留。

3.3 隔离与多项目共存

本项目 ECS 上同时跑着其他站点（宿主裸 Nginx 占用 80 端口就是证据）。如果 mylab 直接在宿主机跑 Node，它会：

• 占用宿主机的端口、进程、文件描述符；
• 和别的项目的 Node/Python 版本、全局包互相打架。

用容器后，每个项目在各自命名空间里独立运行，端口、文件、网络都隔离，互不影响。

3.4 可复制、可回滚、可分发

• 复制：同一份镜像能在测试机、生产机、同事电脑上跑出一样的结果。
• 回滚：出问题了，把容器换回旧镜像重启即可（本项目当前用 latest 标签，回滚靠重新构建旧代码，见《阿里云ECS部署方案（Docker）》5.4 节）。
• 分发：镜像存在 ghcr.io（GitHub 容器仓库），ECS 一条 docker pull 就拿到，无需把源码和构建工具搬上服务器。

3.5 与 CI/CD 天然契合

镜像把「构建」和「运行」彻底分开：

• 构建在 GitHub Actions Runner 上完成（CPU/内存充足）；
• 运行在 ECS 上完成（只拉镜像、启动容器，几秒搞定）。

这就是为什么本项目的小内存 ECS（1.8G）也能流畅部署 Next.js——重活儿不在它身上干。

四、那为什么「不能直接放到宿主机里」

这里分两种理解，都说说。

4.1 理解一：为什么不在宿主机直接 node server.js

如果直接在 ECS 上 git clone + 装 Node + pnpm build + node server.js，会遇到：

问题	直跑宿主机	用镜像
Node / pnpm 版本	依赖宿主机全局安装，易错配	镜像内固定，永远一致
系统污染	全局装包、占端口、留垃圾	零污染，删容器即清
多项目冲突	端口/版本抢资源	容器隔离
迁移/重装	要重装整套环境	装 Docker 即可
回滚	手动切代码、重 build	换镜像重启
进程守护	得另配 systemd / pm2	restart: unless-stopped 自带

而且 mylab 这类 Next.js 站点还涉及 next-intl 国际化中间件在 Node 端执行，需要常驻 Node 运行时，无法纯静态导出——也就是说它「必须有一个 Node 进程在跑」。把这种进程放进容器，比在宿主机裸跑更可控。

4.2 理解二：为什么连「构建」也不能在宿主机做

这是本项目更关键的一点。ECS 只有 1.8G 内存，next build 编译阶段内存峰值很高，极易触发 OOM（内存溢出） 被系统杀进程，或者被迫用 swap 卡到天荒地老。

因此本项目的策略是：

GitHub Actions Runner（内存充足）
   │  docker build  →  产出镜像 ghcr.io/gouxinjie/mylab:latest
   ▼
ghcr.io（镜像仓库）
   │  docker pull
   ▼
ECS（只运行，不构建）  →  docker compose up -d

ECS 上从头到尾不需要 Node、不需要 build、不需要编译工具链。它只是「镜像消费者」。这正是「为什么不能放宿主机」最硬的理由：哪怕你想放，1.8G 内存也 build 不动。

4.3 一个常见误区

「镜像不也是跑在宿主机上吗？凭什么更省事？」

是的，容器进程最终跑在宿主机内核上，但隔离发生在用户态：镜像是自包含的运行环境包，宿主机只提供 Docker 这个「运行平台」。差异在于——宿主机不再需要为「跑 mylab」专门准备任何东西，它只需要 Docker 这一个能力。

五、本项目的镜像实践（一句话串起来）

结合《阿里云ECS部署方案（Docker）》：

1. Dockerfile 用多阶段构建，产出轻量 standalone 镜像；
2. GitHub Actions docker build + push 到 ghcr.io/gouxinjie/mylab:latest；
3. ECS 的 docker-compose.yml 里 app 服务直接引用该镜像；
4. CI 每次 push 自动 docker compose pull && up -d，用最新镜像替换旧容器；
5. nginx 容器（独立镜像 nginx:1.27-alpine）反代到 app，对外只暴露 3500。

整条链路里，镜像就是连接「代码」和「线上运行」的标准交付物。没有它，就没有这套「本地改完代码 → push → 线上自动更新」的省心流程。

六、小结

你可能会问	一句话回答
镜像干嘛用？	把「应用 + 环境」打包成一份可到处原样运行的文件
为什么不直接宿主机跑 Node？	环境易错配、污染系统、多项目冲突、回滚难
为什么连构建都不放宿主机？	ECS 仅 1.8G 内存，next build 会 OOM，重活在 GitHub Runner 干
镜像放哪？	放 ghcr.io，ECS 只 pull 运行，不装 Node
容器和镜像区别？	镜像是静态模板，容器是跑起来的实例

一句话：镜像让你把「运行环境」和「服务器」解耦——服务器只管提供 Docker，应用的一切都在镜像里。

相关文档：《Next项目+Docker自动部署到ECS实战.md》（部署架构、端口规划、CI/CD、排障记录）

— 文档结束 —