Docker 入门与实战

Docker 是一种把应用和它运行所需的一切（操作系统的库、Java 等运行环境、配置文件）打包进一个箱子（容器），在任何地方都以同样方式运行的机制。它于 2013 年发布，如今已成为分发和运行应用的标准形式。

打个比方，它就像集装箱。不管装的是家具还是食品，只要放进规格统一的箱子，轮船、卡车、火车都能同样运输。Docker 容器也是如此：里面是 Java 应用也好、数据库也好，只要机器上装了 Docker，就能用同样的步骤启动。

要“整套准备运行环境”，过去就有虚拟机（VM）。两者的区别在于各自带多少操作系统。

与其说谁更好，不如说分工不同。无论云上还是企业内部，“在 VM 上跑 Docker”都是非常普遍的组合：用 VM 划分机器，用容器划分应用。

镜像采用 OCI 这一业界标准格式，所以用 Docker 构建的镜像在 Podman、Kubernetes 等其他工具中也能直接运行。

下面以面向客户的业务 Web 系统（客户管理等 CRM）为例。构成是当下 Java 项目中常见的Spring Boot（Java）API、Vue 页面和 PostgreSQL 数据库。

本文的示例（Spring Boot 4.1.1・Java 25、Vue 3、nginx 1.30、PostgreSQL 18），笔者已在 Docker Engine 29 和 Compose v5 上实际完成了构建、启动、更新和回滚的验证。

先从效果最大、风险最小的地方开始：只把数据库放进容器。在项目根目录放下面这个 compose.yaml。

# crm/compose.yaml（开发用：只有数据库）
services:
  postgres:
    image: postgres:18          # 与生产相同的主版本
    environment:
      POSTGRES_DB: crm
      POSTGRES_USER: crm
      POSTGRES_PASSWORD: secret
    ports:
      - "5432"                  # 自动分配电脑上空闲的端口

Spring Boot 提供了与 Docker Compose 的联动功能（spring-boot-docker-compose）。加入依赖后，在 IDE 中启动应用时，Spring Boot 会自动执行 docker compose up，并把数据库连接指向容器，连 application.properties 里的连接信息都不用写。

# 启动应用时的日志（节选・实际输出）
DockerComposeLifecycleManager : Using Docker Compose file .../crm/compose.yaml
DockerCli : Container crm-postgres-1 Started
DockerCli : Container crm-postgres-1 Healthy
DbMigrate : Migrating schema "public" to version "1 - create customer"
CrmApplication : Started CrmApplication in 7.271 seconds

测试可以用 Testcontainers：只在测试运行期间启动真实的 PostgreSQL，结束后自动清理。Spring Boot 中加上 @ServiceConnection 就会自动配置连接。

// 测试配置（与 Spring Initializr 生成的基本相同）
@TestConfiguration(proxyBeanMethods = false)
class TestcontainersConfiguration {
    @Bean
    @ServiceConnection
    PostgreSQLContainer postgresContainer() {
        return new PostgreSQLContainer(DockerImageName.parse("postgres:18"));
    }
}

接下来把 Spring Boot 应用本身做成镜像。要点是多阶段构建：构建用（带 JDK 和 Maven）和运行用（只有 JRE）分开，生产镜像里不放编译器和源码。

# crm/Dockerfile
# syntax=docker/dockerfile:1

# ---- 1. 构建阶段（用 JDK 和 Maven 生成 jar）----
FROM eclipse-temurin:25-jdk AS build
WORKDIR /src
COPY .mvn/ .mvn/
COPY mvnw pom.xml ./
RUN --mount=type=cache,target=/root/.m2 ./mvnw -B -q dependency:go-offline
COPY src/ src/
RUN --mount=type=cache,target=/root/.m2 ./mvnw -B -q -DskipTests package

# ---- 2. 运行阶段（只有 JRE 的小镜像）----
FROM eclipse-temurin:25-jre
WORKDIR /app
RUN useradd --system --uid 10001 app
COPY --from=build /src/target/crm-*.jar app.jar
USER app
EXPOSE 8080
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75", "-jar", "app.jar"]

• 先复制依赖描述 ── pom.xml 没变，下载依赖的步骤就会命中缓存而跳过。只改了一点源码，构建几秒到几十秒
• 不用 root 运行 ── 用专用用户（app）运行，万一出事损失更小
• 内存按比例 ── -XX:MaxRAMPercentage=75 让堆上限取容器内存的 75%
• 也可以不写 Dockerfile ── Spring Boot 的 ./mvnw spring-boot:build-image 用 Buildpacks 自动生成镜像

页面（Vue）也是同样思路：用 node 构建，只把生成的静态文件放进 nginx 镜像。

# web/Dockerfile
FROM node:24-alpine AS build
WORKDIR /web
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:1.30-alpine
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /web/dist /usr/share/nginx/html

# web/nginx.conf
server {
    listen 80;
    root /usr/share/nginx/html;

    location / {                       # Vue 页面（SPA）
        try_files $uri $uri/ /index.html;
    }
    location /api/ {                   # API 转发到 Spring Boot 容器
        proxy_pass http://app:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

proxy_pass http://app:8080 里的 app 是下面 Compose 文件中的服务名。不写 IP 地址，用名字就能找到对方。

一台服务器就能承载的规模，Docker Compose 最省事。测试服务器和生产服务器放同一个 compose.yaml。

# deploy/compose.yaml（测试・生产用）
services:
  web:                      # Vue 页面 + 入口（nginx）
    image: registry.example.com/crm/web:${TAG}
    ports:
      - "80:80"
    depends_on:
      - app
    restart: unless-stopped

  app:                      # Spring Boot 业务应用
    image: registry.example.com/crm/app:${TAG}
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://db:5432/crm
      SPRING_DATASOURCE_USERNAME: crm
      SPRING_DATASOURCE_PASSWORD: ${DB_PASSWORD}
      TZ: Asia/Tokyo
    depends_on:
      db:
        condition: service_healthy   # 等数据库就绪后再启动
    restart: unless-stopped

  db:                       # PostgreSQL（数据保存在卷中）
    image: postgres:18
    environment:
      POSTGRES_DB: crm
      POSTGRES_USER: crm
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      TZ: Asia/Tokyo
    volumes:
      - db-data:/var/lib/postgresql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U crm -d crm"]
      interval: 5s
      retries: 10
    restart: unless-stopped

volumes:
  db-data:

# deploy/.env（每台服务器各放一份，不提交到 Git）
TAG=1.0.0
DB_PASSWORD=change-me

• 版本只在 TAG 一处 ── 运行哪个版本由 .env 决定
• 密码放在文件之外 ── 不写进 Compose 文件，用 .env 或密钥管理机制传入
• PostgreSQL 18 的卷 ── 从 18 起数据位置有变，卷挂载到 /var/lib/postgresql（17 及以前是 /var/lib/postgresql/data）
• restart: unless-stopped ── 服务器重启或应用崩溃后自动拉起

启动只需一句 docker compose up -d。文章开头的画面就是实际输出，可以看到应用是在数据库变成 healthy 之后才启动的。

升级只需改掉 .env 里的 TAG，再执行一次 docker compose up -d。只有变化的服务会被重建，数据库照常运行。

涉及数据结构变化的更新（如加表），在应用启动时用 Flyway 等自动执行，就只需替换镜像。回滚时数据库如何还原要事先定好（做成可回退的变更，或更新前先备份）。

运维

• 状态一目了然 ── docker compose ps 看所有服务状态，docker compose logs -f app 看应用日志，每台服务器命令相同
• 自动恢复 ── 借助重启策略和健康检查，挂掉的容器会自动重启
• 环境差异导致的故障减少 ── 消除了“只有生产乱码”“只有生产跑不起来”常见根源——操作系统和库的差异
• 资源可以隔离 ── 可给每个容器设定 CPU 和内存上限，一个失控不至于拖垮全部
• 规模变大也用同一镜像 ── 用户增多时，原样迁移到 Kubernetes 或云上的容器服务

维护

不必一开始就全部容器化。推荐的顺序是：① 开发用数据库 → ② 测试（Testcontainers）→ ③ 在 CI 中生成镜像 → ④ 测试环境 → ⑤ 生产。确认前一阶段的效果，再一步步推进。