技术栈Vue 3 Python/Gunicorn MySQL Nginx Docker Compose部署环境阿里云 Ubuntu阅读时长约 8 分钟前言最近在阿里云上用 Docker Compose 部署一个前后端分离项目前端 Vue 打包后丢给 Nginx后端是 Python Gunicorn数据库 MySQL。本以为是个常规操作结果连踩三个坑容器反复Exited (1)排查了大半天。复盘下来发现这几个问题其实都很典型——尤其是第二个和第三个属于对 Docker 运行机制理解不到位导致的架构性错误。记录下来希望能帮到同样在摸索容器化部署的同学。坑一构建产物「人间蒸发」报错信息cp: cant 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 didnt 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:80volumes:shared-html:思路是frontend 容器负责构建并把产物复制到共享卷nginx 容器从共享卷读取文件。问题在于Docker Compose 里的每个 service 都是一个长期运行的守护进程。cp命令执行完就退出了进程结束Docker 检测到主进程退出判定服务失败返回exit 1。这就好比你雇了个人来当前台结果他把文件放桌上就走了——老板Docker觉得他旷工了。解法不要在docker-compose.yml里用command跑一次性任务。前端服务应该直接运行 Nginx 守护进程。坑三架构冗余——一个前端拆成俩容器现象docker compose ps -a一看出现了两个跟前端相关的容器yunji-frontend-builderyunji-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 --frombuild /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:80depends_on:-backend# 不写 command让 Dockerfile 的 CMD 生效# 不挂载 volumes 覆盖 /usr/share/nginx/htmlbackend:build:./backendimage:jizhang-backend:latestcontainer_name:yunji-backendports:-8000:8000depends_on:-dbdb:image:mysql:8.0container_name:yunji-dbenvironment:MYSQL_ROOT_PASSWORD:${DB_PASSWORD}MYSQL_DATABASE:jizhangvolumes:-db-data:/var/lib/mysqlvolumes:db-data:对比修正前后改动的核心就三点删掉独立的 nginx 服务——前端自己就是 Nginx删掉command: cp ...——构建产物在 Dockerfile 里就打包好了删掉共享卷——不需要容器间传文件了排查命令速查表遇到类似问题时按这个顺序排查构建失败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-A10services:# 检查本地镜像列表dockerimages|grepjizhang踩坑总结坑表象本质构建产物缺失cp: cant stat /app/dist/*构建静默失败 缓存干扰容器秒退Exited (1)把一次性命令当守护进程架构冗余两个容器 共享卷没用多阶段构建回头看这三个问题其实都指向同一个认知盲区Docker 不只是把东西装进容器它有自己的一套关于进程生命周期和镜像分层的设计哲学。不理解这些就容易把传统的部署思维先编译、再拷贝、再启动原封不动地搬进容器里造成各种水土不服。多阶段构建是解决前端容器化部署的标准答案。一个 Dockerfile两个FROM干净利落。分享 AI、Docker、全栈开发的实战经验把技术讲成人话。