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 -dECS 上从头到尾不需要 Node、不需要 build、不需要编译工具链。它只是「镜像消费者」。这正是「为什么不能放宿主机」最硬的理由：哪怕你想放，1.8G 内存也 build 不动。
4.3 一个常见误区
「镜像不也是跑在宿主机上吗？凭什么更省事？」
是的，容器进程最终跑在宿主机内核上，但隔离发生在用户态：镜像是自包含的运行环境包，宿主机只提供 Docker 这个「运行平台」。差异在于——宿主机不再需要为「跑 mylab」专门准备任何东西，它只需要 Docker 这一个能力。
五、本项目的镜像实践（一句话串起来）
结合《阿里云ECS部署方案（Docker）》：
Dockerfile用多阶段构建，产出轻量standalone镜像；- GitHub Actions
docker build+push到ghcr.io/gouxinjie/mylab:latest； - ECS 的
docker-compose.yml里app服务直接引用该镜像； - CI 每次 push 自动
docker compose pull && up -d，用最新镜像替换旧容器； 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、排障记录）
— 文档结束 —
🚀 感谢阅读！想了解更多？
📖 我的博客网站 | 记录思考，分享干货
🏡 我的个人主页 | 关于我、开源项目
