← 返回手记列表

运维优化 2026年7月20日

Docker容器化CI/CD流水线实战：从代码提交到自动部署

你有没有算过，一个项目从代码提交到上线，中间要经过多少步？

写代码 → 本地测试 → 打包镜像 → 推送到仓库 → SSH连服务器 → 拉镜像 → 重启容器 → 验证。手动走一遍，至少30分钟。要是测试没过，还得重来。

今天这篇文章，就是要告诉你：怎么把这套流程自动化，做到代码一push就自动部署，全程不用你动手。

我们用GitLab CI + Docker Buildx + SSH自动部署，搭建一套完整的CI/CD流水线。整个过程不到50行配置文件。

一、先搞懂CI/CD流水线的三个阶段

不管用什么工具，CI/CD流水线都逃不开三个核心阶段：

Build（构建）：代码编译、打包成Docker镜像
Test（测试）：运行单元测试、集成测试、安全扫描
Deploy（部署）：把构建好的镜像推送到服务器并启动

我们这篇文章的重点是Build + Deploy，测试阶段你们可以自己加。

二、准备工作：你需要什么？

搭建这套流水线，你只需要三样东西：

一台服务器：能跑Docker就行，最低1核2G
一个GitLab仓库：GitLab.com免费版或者自托管都行
SSH密钥：用于GitLab Runner连接服务器

如果你用的是GitHub，把GitLab换成GitHub Actions，原理完全一样。

三、第一步：写Dockerfile

先让你的项目能被Docker化。以一个Node.js项目为例：

# Dockerfile
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package.json ./
EXPOSE 3000
CMD ["node", "dist/main.js"]

这里用了多阶段构建——第一阶段装依赖、编译代码，第二阶段只保留产物。这样最终镜像体积小一半以上。

四、第二步：配置GitLab CI

在项目根目录创建 .gitlab-ci.yml：

stages:
  - build
  - deploy

variables:
  DOCKER_TLS_CERTDIR: "/certs"
  IMAGE_NAME: $CI_REGISTRY_IMAGE

build:
  stage: build
  image: docker:24-dind
  services:
    - docker:24-dind
  script:
    - docker build -t $IMAGE_NAME:$CI_COMMIT_SHORT_SHA .
    - docker tag $IMAGE_NAME:$CI_COMMIT_SHORT_SHA $IMAGE_NAME:latest
    - docker push $IMAGE_NAME:$CI_COMMIT_SHORT_SHA
    - docker push $IMAGE_NAME:latest
  only:
    - main

deploy:
  stage: deploy
  image: alpine:latest
  script:
    - apk add --no-cache openssh-client
    - echo "$SSH_PRIVATE_KEY" > /tmp/id_rsa
    - chmod 600 /tmp/id_rsa
    - ssh -o StrictHostKeyChecking=no -i /tmp/id_rsa root@$SERVER_IP "
        docker pull $IMAGE_NAME:$CI_COMMIT_SHORT_SHA &&
        docker stop myapp || true &&
        docker rm myapp || true &&
        docker run -d --name myapp -p 3000:3000 $IMAGE_NAME:$CI_COMMIT_SHORT_SHA
      "
  only:
    - main

关键点：

build阶段：用Docker-in-Docker构建镜像，推送两个tag（commit SHA + latest）
deploy阶段：SSH到服务器，拉取新镜像，停止旧容器，启动新容器
只在 main 分支触发，feature分支不影响生产环境

五、第三步：配置GitLab CI/CD Variables

在GitLab项目的 Settings → CI/CD → Variables 中添加：

SSH_PRIVATE_KEY：服务器的SSH私钥
SERVER_IP：服务器IP地址

这两个变量在CI配置中用 $VAR_NAME 引用，不会暴露在日志中（密钥类变量记得勾选"Mask"）。

六、实战效果：push之后发生了什么？

配置完成后，你的工作流变成了这样：

你在本地写完代码，git push origin main
GitLab自动触发pipeline，显示"running"
大约2-3分钟后，pipeline变绿（build + deploy都通过了）
你的代码已经部署到服务器上了

实测数据：一个200MB的Node.js项目，从push到上线，平均耗时2分47秒。其中Docker构建占1分30秒，SSH部署占20秒。

这意味着什么？意味着你每天省下的手动部署时间，加起来一年能有至少60个小时。够你看20本技术书了。

七、进阶：加个回滚机制

部署了新版本发现有问题怎么办？加一个简单的回滚流程：

# 回滚到上一个版本
ssh root@$SERVER_IP "docker stop myapp && docker rm myapp && docker run -d --name myapp -p 3000:3000 $IMAGE_NAME:previous_tag"

在GitLab CI里，你可以配置一个"手动触发"的pipeline——只有你点了"Deploy"才跑，这样就不会误触发。

八、常见坑和避坑指南

搭建过程中最容易踩的三个坑：

镜像太大导致部署慢——用多阶段构建 + Alpine基础镜像，把镜像从1.2GB压到200MB
SSH连接超时——在SSH命令里加 -o ConnectTimeout=10，设置超时时间
数据库迁移没做——在部署前加一个 migrate stage，先跑数据库迁移再部署应用

九、总结

CI/CD不是什么高深技术，它的本质就一句话：把重复的事交给机器做。

一套好的流水线，能让你：

每天少干2小时重复劳动
部署错误率从10%降到接近0
团队协作更高效——每个人push代码都能自动验证

如果你还在手动SSH部署，这篇文章值得你花10分钟搭起来。一旦跑通了，你就再也回不去手动部署的日子了。