Docker自动化部署实战：从镜像构建到CI/CD流水线落地

Docker自动化部署解决什么问题

手工部署的典型流程是：登录服务器、备份旧版本、上传代码、重启服务。流程一多就出错，尤其多台服务器时容易漏操作。Docker自动化部署把环境、依赖、代码一起打进镜像，用统一的方式构建、推送、发布，环境差异导致的部署失败大幅减少。本文以一套实际可用的流水线为例，覆盖镜像构建、镜像仓库、CI/CD触发和发布回滚。

Dockerfile编写规范与镜像瘦身

镜像质量决定部署效率。一个常见的反面例子是直接把整个开发环境装进镜像，体积几个GB。工程化的做法是采用多阶段构建：构建阶段安装编译工具，运行阶段只保留产物和运行时。

# 构建阶段
FROM golang:1.22 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /app/server .

# 运行阶段
FROM alpine:3.20
RUN adduser -D appuser
COPY --from=builder /app/server /usr/local/bin/server
USER appuser
EXPOSE 8080
CMD ["server"]

这里只保留二进制和运行时依赖，镜像体积从几百MB降到几十MB。基础镜像尽量固定版本标签，不依赖latest，保证构建可复现。

镜像仓库与版本管理

构建产物要推送到镜像仓库，发布时按tag拉取。推荐镜像tag用 Git 提交哈希或构建号，保证每次发布对应唯一版本：

docker build -t registry.example.com/web:${BUILD_NUMBER} .
docker push registry.example.com/web:${BUILD_NUMBER}

打上 latest 仅用于本地联调，生产环境发布必须指定具体版本号，否则镜像被覆盖后无法回滚到旧版本。

docker-compose编排与配置管理

单机多容器场景用docker-compose编排。配置通过环境变量注入，避免把密钥写进镜像：

version: "3.8"
services:
  app:
    image: registry.example.com/web:${BUILD_NUMBER}
    ports:
      - "8080:8080"
    environment:
      - DB_HOST=mysql
      - DB_PASSWORD=${DB_PASSWORD}
    depends_on:
      - mysql
  mysql:
    image: mysql:8.0
    volumes:
      - mysql_data:/var/lib/mysql
volumes:
  mysql_data:

compose文件本身是配置文件，纳入版本管理，和环境变量文件（env）分开存放，密钥只出现在CI/CD系统的变量配置里。

CI/CD流水线设计

流水线分四段：代码提交触发构建、单测与镜像扫描、推送镜像、部署。以GitLab CI为例：

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script:
    - go test ./...

build:
  stage: build
  script:
    - docker build -t registry.example.com/web:${CI_PIPELINE_ID} .
    - docker push registry.example.com/web:${CI_PIPELINE_ID}

deploy:
  stage: deploy
  only:
    - main
  script:
    - ssh deploy@server "docker pull registry.example.com/web:${CI_PIPELINE_ID} && docker compose up -d"

只有main分支的构建结果才触发部署。测试通过前不构建镜像，镜像扫描通过前不推送，每道关卡把问题拦截在发布之前。

发布回滚与失败恢复

发布失败时，回滚比修复更快。保留上一版本的镜像，回滚就是重新部署旧tag：

docker pull registry.example.com/web:${PREVIOUS_BUILD_NUMBER}
docker compose up -d

配合健康检查自动恢复：compose里加healthcheck，服务启动后未通过健康检查会自动重启并剔除流量，把发布失败的影响控制在分钟级。