第一次打包Docker镜像：从"能跑就行"到"在哪都能跑"

开发团队最熟悉的场景之一：代码在自己机器上完美运行，交给测试同事后，报错信息能写满三页纸。环境差异、依赖版本、系统配置，任何一个变量都可能成为故障来源。Docker的核心价值，正是把这种不确定性装进一个标准化的盒子里。

本文以一个Node.js应用为例，演示如何从零构建可复用的Docker镜像。不需要复杂的前置知识，只需跟随步骤操作。

第一步：准备应用代码

创建一个基础的HTTP服务，暴露容器运行时的关键信息。代码使用Node.js内置模块，无需额外依赖：

• http模块创建服务器
• os模块读取主机名、操作系统、架构
• process对象获取Node版本
• Date对象显示当前时间

服务监听3000端口，返回格式化的HTML页面。这段代码的意图很明确：验证容器是否正确隔离了运行环境。

第二步：定义项目元数据

package.json文件只需三个字段：

• name：项目标识
• version：版本号
• main：入口文件路径

此处未声明dependencies，因为代码仅使用Node.js原生API。

第三步：编写Dockerfile

这是镜像构建的核心指令集，逐行解析：

FROM node:trixie —— 选择官方Node镜像的trixie版本作为基底，已预装Linux系统、Node运行时、npm及系统库

WORKDIR /app —— 设定容器内的工作目录，后续操作均以此为基准

COPY package.json /app/ —— 将依赖清单复制进容器

COPY src /app/src —— 将源代码复制进容器

RUN npm install —— 构建阶段执行依赖安装

CMD ["node", "src/server.js"] —— 容器启动时执行的默认命令

关键区分：RUN在镜像构建时运行，CMD在容器启动时运行。

第四步：构建镜像

执行命令：docker build -t node-app:1.0 .

参数说明：

• build：触发镜像构建流程
• -t：指定镜像名称和标签（此处为node-app:1.0）
• . ：告知Docker在当前目录寻找Dockerfile

构建完成后，本地镜像仓库将新增一条记录。

第五步：运行容器

执行命令：docker run -p 8080:3000 node-app:1.0

端口映射逻辑：将宿主机的8080端口绑定到容器的3000端口。外部访问localhost:8080，请求会被转发至容器内部的服务。

打开浏览器验证，页面应显示容器的主机名、操作系统、架构、Node版本及当前时间——这些信息证明应用确实运行在隔离环境中，而非直接调用宿主系统。

为什么这套流程值得掌握

传统交付方式要求接收方复刻完整的开发环境，而Docker镜像把"环境"本身变成了可传输的制品。测试团队不再需要逐行核对依赖版本，运维团队也能基于同一镜像部署至不同服务器。这种一致性在持续集成、多阶段部署、云原生架构中都是基础能力。

从单文件应用到微服务集群，镜像构建的逻辑本质相同：定义基底、复制文件、执行构建、设定启动行为。掌握这一范式，意味着跨过了从"本地开发"到"工程化交付"的关键门槛。