Docker CI/CD 流水线

流水线四阶段与镜像的角色 1/7

不管用哪个平台，一条容器化流水线的骨架都一样：

为什么镜像是理想的交付物

构建阶段优化 2/7

Dockerfile 层面的技巧（层顺序、多阶段、镜像瘦身）在 Dockerfile 最佳实践 里已经讲过，这里只补 CI 特有的三个问题。

问题一：CI runner 是无状态的，本地缓存每次都丢

你在自己机器上享受的层缓存，在 CI 里不存在——每个 job 都是崭新的一次。所以必须把缓存存到外面：

问题二：BuildKit 已经是默认，但你得知道它带来了什么

Docker 23 之后 BuildKit 已是默认构建后端。它在 CI 里真正有用的三点：DAG 并行（互不依赖的多阶段会同时跑）、更好的缓存键（内容寻址，比旧的层哈希更准）、secret mount（构建时用密钥但不落进任何层）：

# Dockerfile 里：构建时读密钥，但不会留在镜像里
RUN --mount=type=secret,id=npmrc,dst=/root/.npmrc \
    npm ci --production

# 构建时传入
docker buildx build --secret id=npmrc,src=.npmrc -t myapp .

问题三：多架构镜像——QEMU 能跑通，但慢得你可能无法接受

要同时产出 linux/amd64 和 linux/arm64，最常见的是用 QEMU 模拟另一种架构。它能用，但对编译型语言可能是数倍的时间开销——因为编译器本身也在被模拟执行。所以：

GitHub Actions 实战 3/7

下面是一个完整可用的工作流：多架构构建、推送到 GHCR、带构建缓存、按 git 信息自动打标签。

# .github/workflows/docker.yml
name: Build and push image

on:
  push:
    branches: [main]
    tags: ['v*']
  pull_request:
    branches: [main]

env:
  IMAGE: ghcr.io/${{ github.repository }}

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write          # 推 GHCR 必须有这项
    steps:
      - uses: actions/checkout@v4

      - uses: docker/setup-qemu-action@v3
      - uses: docker/setup-buildx-action@v3

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.IMAGE }}
          tags: |
            type=ref,event=branch
            type=semver,pattern={{version}}
            type=sha,prefix=sha-,format=short

      - uses: docker/build-push-action@v6
        with:
          context: .
          platforms: linux/amd64,linux/arm64
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

几个容易踩的点

GitLab CI 实战 4/7

GitLab 的好处是它自带容器镜像仓库，且凭据变量（$CI_REGISTRY_*）是自动注入的，不用手工配 secret。

# .gitlab-ci.yml
stages:
  - build

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

build-and-push:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  before_script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
  script:
    - docker buildx create --use --driver docker-container
    - docker buildx build
      --platform linux/amd64,linux/arm64
      --cache-from type=registry,ref=$CI_REGISTRY_IMAGE:buildcache
      --cache-to   type=registry,ref=$CI_REGISTRY_IMAGE:buildcache,mode=max
      --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
      --tag $CI_REGISTRY_IMAGE:latest
      --push .
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

关键分歧：DinD 需要特权，那不用特权怎么办？

上面的 docker:dind 是最省事的写法，但它要求 runner 开启 privileged——等于把宿主机的 Docker 交给了流水线，任何能改 CI 配置的人都能借此拿到宿主机权限。自建 runner 上尤其要谨慎。

制品与供应链 5/7

镜像一旦推到仓库，它就成了你的正式制品。这里有三件事必须定规矩：怎么打标签、怎么清理、怎么验真。

标签策略

清理：不清会出事

每次提交都推一个镜像，一年下来仓库能吃掉几百 GB。三层清理各管一段：

签名与 SBOM：让「这个镜像是我构建的」可验证

部署与回滚 6/7

镜像推上去只是做了一半。真正让流水线见效的是最后这一步——怎么让线上换到新镜像，以及怎么退回来。

三条落地路径

路径一：SSH 触发拉取（附完整片段）

  # 接在第 3 节的 build job 之后
  deploy:
    needs: [build]
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: 准备 SSH
        run: |
          mkdir -p ~/.ssh
          printf '%s\n' "${{ secrets.DEPLOY_SSH_KEY }}" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519
          printf '%s\n' "${{ secrets.DEPLOY_HOST_KEY }}" >> ~/.ssh/known_hosts

      - name: 拉取新镜像并重启
        run: |
          ssh "${{ secrets.DEPLOY_USER }}@${{ secrets.DEPLOY_HOST }}" '
            cd /opt/myapp &&
            docker compose pull &&
            docker compose up -d &&
            docker compose ps
          '

回滚：比发布更该被验证的能力

最小可用模板与演进清单 7/7

如果第 3 节那份完整配置看起来太重，这里是能跑的 20 行版本。先让它绿，再按需要加能力。

# .github/workflows/docker.yml —— 最小可用版
name: Build and push
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/OWNER/REPO:sha-${{ github.sha }}

按需往上加，不要一次全上

继续往下走