为什么使用 Docker 镜像

mylab版本 v1.0 | 2026-07-22适用读者想搞懂「镜像到底是干嘛的、为什么不直接在 ECS 上装 Node 跑」的部署新手一、先说结论对于 mylab 这样的 Next.js 站点「把应用打包成 Docker 镜像、在容器里运行」并不是为了炫技而是为了解决一个很现实的问题宿主机环境不可控、构建太吃资源、多项目容易互相污染。镜像的本质是把「应用 它运行所需的一切环境」打包成一个可移植的文件。谁拿到这个文件在任意装了 Docker 的机器上都能原样跑起来且跑出来的结果一致。二、镜像Image到底是什么可以把镜像理解成「一台装好环境、配好应用的只读快照」。类比镜像容器面向对象class类instance实例做菜菜谱 备好的料按菜谱做出来的那盘菜虚拟机模板 / 母盘从模板克隆出来的虚拟机镜像Image静态文件包含操作系统基础层、Node 运行时、依赖、编译好的代码本项目是 Next.jsstandalone产物。容器Container镜像运行起来的实例是真正在干活的程序进程。关键点镜像是「一次构建、到处运行」的交付物。我在 GitHub 的 Runner 上docker build出一份镜像ECS 上docker pull下来docker run跑出来的东西和我在 Runner 上跑的完全一样——环境差异被封死在镜像里了。三、镜像到底起了什么作用3.1 环境一致性最重要不在宿主机直接跑 Node最大的好处是不再受宿主机环境影响宿主机装的是 Node 18项目要 Node 20镜像里自带 Node 20互不干扰。项目锁定pnpm9.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.ioGitHub 容器仓库ECS 一条docker pull就拿到无需把源码和构建工具搬上服务器。3.5 与 CI/CD 天然契合镜像把「构建」和「运行」彻底分开构建在 GitHub Actions Runner 上完成CPU/内存充足运行在 ECS 上完成只拉镜像、启动容器几秒搞定。这就是为什么本项目的小内存 ECS1.8G也能流畅部署 Next.js——重活儿不在它身上干。四、那为什么「不能直接放到宿主机里」这里分两种理解都说说。4.1 理解一为什么不在宿主机直接node server.js如果直接在 ECS 上git clone 装 Node pnpm buildnode server.js会遇到问题直跑宿主机用镜像Node / pnpm 版本依赖宿主机全局安装易错配镜像内固定永远一致系统污染全局装包、占端口、留垃圾零污染删容器即清多项目冲突端口/版本抢资源容器隔离迁移/重装要重装整套环境装 Docker 即可回滚手动切代码、重 build换镜像重启进程守护得另配 systemd / pm2restart: 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 Actionsdocker buildpush到ghcr.io/gouxinjie/mylab:latestECS 的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.ioECS 只pull运行不装 Node容器和镜像区别镜像是静态模板容器是跑起来的实例一句话镜像让你把「运行环境」和「服务器」解耦——服务器只管提供 Docker应用的一切都在镜像里。相关文档《Next项目Docker自动部署到ECS实战.md》部署架构、端口规划、CI/CD、排障记录— 文档结束 — 感谢阅读想了解更多 我的博客网站 | 记录思考分享干货 我的个人主页 | 关于我、开源项目