背景#

MO Gallery 官网 mo-gallery-offical 使用 GitHub Actions 通过 SSH 将源码同步到服务器，然后在服务器执行：

1
docker compose up -d --build

一次部署虽然最终成功，但 GitHub Actions 运行时间达到 8 分 42 秒：

查看本次部署记录

部署流程本身没有卡死，主要问题是 Docker 在服务器上进行了完整的应用构建，并且把只用于数据库迁移的构建阶段也导出成了一个完整镜像。

日志分段#

根据 Actions 日志，各阶段耗时如下：

真正需要关注的是下面这段：

1
[migrate] exporting layers 155.0s
2
[migrate] unpacking ... 74.5s

仅 migrate 镜像的导出和解包就占用了接近四分钟。

原因分析#

原来的 Compose 配置如下：

1
services:
2
  migrate:
3
    build:
4
      context: .
5
      target: builder
6
    command: sh -c "node_modules/.bin/prisma migrate deploy"

而 Dockerfile 的 builder 阶段负责完整的前端构建：

1
FROM base AS builder
2
COPY . .
3
RUN pnpm install --frozen-lockfile
4
RUN pnpm run build

因此，builder 阶段包含了很多数据库迁移根本不需要的内容：

• 完整的 workspace 依赖
• 全部源码
• .next 构建产物
• Next.js、Milkdown、Tiptap、图片处理等前端依赖
• Prisma CLI 以及应用的其他开发依赖

但迁移服务实际上只执行：

1
prisma migrate deploy

它只需要读取 prisma/schema.prisma、prisma/migrations 和 Prisma CLI。让 Compose 直接使用 target: builder，等于先构建完整应用，再把整个构建阶段导出成一个迁移镜像。

方案调整#

将 Dockerfile 拆成三个职责明确的阶段：

1
builder  -> 完整安装依赖并构建 Next.js 应用
2
migrate  -> 只安装 Prisma CLI，执行数据库迁移
3
runner   -> 只运行 Next.js standalone 产物

1
{
2
  "name": "mo-gallery-official-migrate",
3
  "private": true,
4
  "dependencies": {
5
    "dotenv": "17.4.2",
6
    "prisma": "7.10.0"
7
  }
8
}

1
# ---- 迁移阶段：只保留 Prisma CLI、dotenv 与迁移文件 ----
2
FROM base AS migrate
3
ENV NODE_ENV=production
4

5
COPY prisma/migrate-package.json ./package.json
6
RUN npm install --omit=dev --no-package-lock
7

8
COPY prisma.config.ts ./
9
COPY prisma ./prisma
10

11
CMD ["node_modules/.bin/prisma", "migrate", "deploy"]

1
import 'dotenv/config'
2
import { defineConfig } from 'prisma/config'

1
services:
2
  migrate:
3
    build:
4
      context: .
5
      target: migrate
6
    command: ["node_modules/.bin/prisma", "migrate", "deploy"]
7
    environment:
8
      DATABASE_URL: ${DATABASE_URL:?请在 .env 中设置 DATABASE_URL}

1
services:
2
  app:
3
    build: .
4
    depends_on:
5
      migrate:
6
        condition: service_completed_successfully

为什么这样能减少耗时#

之前的迁移镜像继承了完整 builder 阶段。即使迁移命令只运行几秒，Docker 仍需要：

1. 导出包含完整依赖和构建产物的镜像层；
2. 将这些镜像层写入 Docker 镜像存储；
3. 解包迁移镜像；
4. 再创建迁移容器。

调整后，migrate 阶段只包含 Prisma 运行所需内容，完整应用构建仍然只服务于 app 镜像，不再被重复作为迁移镜像导出。

本次日志中旧迁移镜像的导出和解包约耗时 230 秒，因此这部分是最明确的优化目标。实际第一次切换到独立阶段后，新的迁移镜像导出和解包约耗时 74 秒，但同时新增了约 68 秒的精简 Prisma 依赖安装；由于两个镜像阶段并行构建，最终部署从约 8 分 42 秒降至约 6 分 36 秒，实际减少约 2 分 06 秒。

迁移依赖清单只复制 prisma/migrate-package.json，后续源码变化不会使 npm install 层失效。只要 Prisma 版本和迁移依赖没有变化，后续部署应能复用这一层，迁移阶段还会比本次更快。

实测结果#

优化前的部署运行时间约为 8 分 42 秒，优化后的本次运行时间约为 6 分 36 秒，减少约 2 分 06 秒。

查看优化后的部署记录

本次运行的迁移阶段日志如下：

1
npm install --omit=dev --no-package-lock       约 68 秒
2
migrate 镜像导出与解包                         约 74 秒

因此不能简单地把原来的 230 秒全部视为净收益：精简镜像仍然需要首次安装 Prisma CLI 及其传递依赖。不过迁移镜像已经从“完整应用构建镜像”变成了独立小阶段，后续部署可以复用稳定的 npm 安装层。

当前剩余耗时#

拆分迁移镜像后，部署仍会有两个主要耗时来源：

1. pnpm install --frozen-lockfile：最新运行中应用构建阶段用了约 108 秒。当前 Dockerfile 为了解决 workspace 包复制顺序问题，将完整源码复制后再安装依赖，普通源码变化会导致依赖安装层失效。
2. next build：最新运行中用了约 233 秒，服务器需要重新执行 Turbopack 编译和 TypeScript 检查。

后续还可以继续优化：

• 使用 BuildKit cache mount 持久化 pnpm store；
• 将根目录和 workspace 的 package.json 与源码分层复制，尽可能复用依赖安装层；
• 使用更轻量的构建缓存策略；
• 评估在 CI 构建镜像后推送到镜像仓库，服务器只拉取并重启，减少服务器本地构建时间。

不过这些优化涉及构建缓存和发布链路调整，而独立 migrate 阶段不改变现有发布流程，优先级更高、风险更低。

结论#

部署耗时长并不是 SSH 同步慢，也不是 Prisma 迁移本身慢，而是数据库迁移服务错误地复用了完整应用构建阶段：

1
target: builder

将其调整为：

1
target: migrate

并为迁移服务提供只包含 Prisma CLI、dotenv 和迁移文件的独立镜像，可以避免导出完整 builder 镜像，同时保持“迁移成功后再启动应用”的部署语义不变。