Docker Compose 前后端部署踩坑实录：3 个坑让我的容器反复 Exit(1)

技术栈：Vue 3 + Python/Gunicorn + MySQL + Nginx + Docker Compose
部署环境：阿里云 Ubuntu
阅读时长：约 8 分钟

前言

最近在阿里云上用 Docker Compose 部署一个前后端分离项目，前端 Vue 打包后丢给 Nginx，后端是 Python + Gunicorn，数据库 MySQL。

本以为是个常规操作，结果连踩三个坑，容器反复Exited (1)，排查了大半天。复盘下来发现这几个问题其实都很典型——尤其是第二个和第三个，属于对 Docker 运行机制理解不到位导致的架构性错误。

记录下来，希望能帮到同样在摸索容器化部署的同学。

坑一：构建产物「人间蒸发」

报错信息

cp: can't stat '/app/dist/*': No such file or directory

现象

执行docker compose up -d，前端镜像构建阶段直接报错，Nginx 启动失败。

根因

Vue 项目在容器内执行npm run build时静默失败了。可能的原因包括：

• 网络超时导致依赖没装全
• Node 版本和项目不兼容
• 代码本身有构建错误（TypeScript 类型报错、ESLint 严格模式拦截等）

构建没成功，/app/dist目录压根没生成。到了 Dockerfile 的下一个阶段，COPY或cp找不到源文件，直接炸了。

坑在哪？Docker 默认会用缓存，如果之前有一次成功构建的缓存层，后续修改了代码但没清缓存，npm install那一步可能直接跳过，导致新代码跑在旧依赖上，报错信息还特别迷惑。

解法

# 强制重建，不用缓存，完整输出日志dockercompose build --no-cache frontend# 盯住输出里的这些关键词# "ERROR"、"npm ERR!"、"Failed to compile"

看到完整的构建日志后，问题通常一目了然。修完代码再重新构建即可。

坑二：把「构建任务」当成了「服务」

报错信息

Container yunji-frontend-builder Exited (1) service "frontend" didn't complete successfully: exit 1

现象

docker compose build显示✔ Image Built，看起来镜像构建成功了。但docker compose up之后容器状态却是Exited (1)。

更诡异的是，容器名字叫yunji-frontend-builder——一个前端服务为什么叫 builder？

根因

这是一个对 Docker Compose 运行机制的根本性误解。

当时的docker-compose.yml大概长这样（简化版）：

services:frontend:build:./frontendcontainer_name:yunji-frontend-buildercommand:cp-r /app/dist/* /shared/html/volumes:-shared-html:/shared/htmlnginx:image:nginx:alpinevolumes:-shared-html:/usr/share/nginx/htmlports:-"80:80"volumes:shared-html:

思路是：frontend 容器负责构建并把产物复制到共享卷，nginx 容器从共享卷读取文件。

问题在于：Docker Compose 里的每个 service 都是一个长期运行的守护进程。cp命令执行完就退出了，进程结束，Docker 检测到主进程退出，判定服务失败，返回exit 1。

这就好比你雇了个人来当前台，结果他把文件放桌上就走了——老板（Docker）觉得他旷工了。

解法

不要在docker-compose.yml里用command跑一次性任务。前端服务应该直接运行 Nginx 守护进程。

坑三：架构冗余——一个前端拆成俩容器

现象

docker compose ps -a一看，出现了两个跟前端相关的容器：

• yunji-frontend-builder
• yunji-nginx

它们通过volumes交互：builder 把文件写进共享卷，nginx 从共享卷读。

根因

没用上 Docker 最核心的特性之一——多阶段构建（Multi-stage Build）。

多阶段构建的思路是：在一个 Dockerfile 里定义多个阶段，前面的阶段负责编译/构建，后面的阶段只复制产物，最终镜像里不包含构建工具链，既干净又小。

如果不用多阶段构建，硬要把"构建"和"运行"拆成两个容器，就得靠共享卷来传递文件。这不仅增加了复杂度，还引入了时序依赖（builder 还没跑完，nginx 就启动了怎么办？）、命名混乱、调试困难等一系列问题。

解法

用标准的多阶段构建 Dockerfile，一个服务搞定：

frontend/Dockerfile（修正后）：

# ---- 阶段 1：构建 ---- FROM node:18-alpine AS build WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build # ---- 阶段 2：运行 ---- FROM nginx:alpine # 直接从上一阶段复制产物，不需要共享卷 COPY --from=build /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]

docker-compose.yml（修正后）：

services:frontend:build:./frontendimage:jizhang-frontend:latest# 明确指定镜像名container_name:yunji-frontend# 规范命名，不要叫 builderports:-"80:80"depends_on:-backend# 不写 command，让 Dockerfile 的 CMD 生效# 不挂载 volumes 覆盖 /usr/share/nginx/htmlbackend:build:./backendimage:jizhang-backend:latestcontainer_name:yunji-backendports:-"8000:8000"depends_on:-dbdb:image:mysql:8.0container_name:yunji-dbenvironment:MYSQL_ROOT_PASSWORD:${DB_PASSWORD}MYSQL_DATABASE:jizhangvolumes:-db-data:/var/lib/mysqlvolumes:db-data:

对比修正前后，改动的核心就三点：

1. 删掉独立的 nginx 服务——前端自己就是 Nginx
2. 删掉command: cp ...——构建产物在 Dockerfile 里就打包好了
3. 删掉共享卷——不需要容器间传文件了

排查命令速查表

遇到类似问题时，按这个顺序排查：

构建失败（dist 目录缺失）：

# 强制重建，完整日志dockercompose build --no-cache frontend# 关注 "ERROR" 和 "npm ERR!"

容器启动后立即退出：

# 查看所有容器状态（包括已停止的）dockercomposeps-a# 查看容器日志dockercompose logs frontend# 进容器检查文件是否存在dockercompose run--rmfrontendls-la/usr/share/nginx/html

架构/配置问题：

# 检查 compose 配置结构catdocker-compose.yml|grep-A10"services:"# 检查本地镜像列表dockerimages|grepjizhang

踩坑总结

回头看这三个问题，其实都指向同一个认知盲区：Docker 不只是"把东西装进容器"，它有自己的一套关于进程生命周期和镜像分层的设计哲学。不理解这些，就容易把传统的部署思维（先编译、再拷贝、再启动）原封不动地搬进容器里，造成各种水土不服。

多阶段构建是解决前端容器化部署的标准答案。一个 Dockerfile，两个FROM，干净利落。

分享 AI、Docker、全栈开发的实战经验，把技术讲成人话。