Docker工程化：从安装命令到CI/CD交付的系统认知

1. 工程化不是加个Dockerfile就完事：从“能跑”到“可交付”的认知断层

很多人第一次接触Docker，是在某篇教程里照着敲下docker run hello-world，看到终端输出一行绿色文字，就以为自己“会Docker”了。接着兴冲冲去改项目，加个Dockerfile，docker build -t myapp .，再docker run -p 8080:8080 myapp——页面真出来了！于是朋友圈一发：“Docker已上手，容器化部署稳了”。结果两周后，运维同事深夜打电话：“你那个服务镜像拉不下来，registry报403，CI流水线卡在build阶段，日志里全是permission denied……”你打开CI平台一看，构建日志最后一行赫然写着：failed to solve: failed to read dockerfile: open /workspace/Dockerfile: no such file or directory。

这不是个例，而是工程化落地中最典型的“幻觉陷阱”：把单机验证等同于工程能力，把命令执行成功等同于系统就绪。Docker本身只是个工具，而“Docker工程化”是整套协作契约——它定义了开发、测试、运维、安全、CI/CD之间如何用统一语言描述环境、约束行为、传递制品、验证质量。它解决的从来不是“怎么让程序在容器里跑起来”，而是“怎么让一个团队在三个月内，不靠人肉记忆、不靠口头约定、不靠临时救火，把27个微服务、14种中间件、5套数据库配置，全部稳定、可复现、可审计地交付到生产环境”。

关键词里反复出现的“安装”和“核心命令”，恰恰暴露了当前学习路径的最大断层：我们花了大量时间记docker ps -a和docker exec -it，却没人告诉你为什么docker run --rm -v $(pwd):/work alpine ls /work在Mac上能列出当前目录，在Linux上却可能权限报错；我们熟练背诵docker-compose up -d，却不清楚depends_on只控制启动顺序，完全不保证依赖服务“已就绪”；我们下载Docker Desktop点几下就完成安装，却不知道Windows子系统WSL2内核版本低于5.10会导致--gpus all直接静默失败。

这背后是三个被严重低估的底层事实：
第一，Docker Engine不是黑盒，它是运行在宿主机内核之上的用户态守护进程（dockerd），所有docker命令本质都是向它发送HTTP API请求。docker run背后是POST /containers/create+POST /containers/{id}/start两次调用，docker logs是GET /containers/{id}/logs流式响应。不理解这个通信模型，就永远搞不清为什么docker context use remote切换上下文后，本地docker ps突然查不到容器——因为请求发到了另一台机器的dockerd上。

第二，“安装”二字在不同场景下含义天差地别：在Ubuntu服务器上执行apt install docker.io装的是社区版dockerd，而在Windows上双击Docker Desktop安装包，实际部署的是包含dockerd、kubernetes、wsl2-backend、hyper-v-driver的完整虚拟化栈。前者只需开放2375端口即可远程管理，后者必须通过docker context机制显式声明连接目标。混淆这两者，是90%的“Docker连不上”问题的根源。

第三，“核心命令”的工程价值不在语法本身，而在其设计意图的精确匹配。比如docker commit命令被官方文档明确标注为“不推荐用于生产”，因为它破坏了镜像构建的不可变性原则——你无法追溯一个commit生成的镜像到底基于哪个基础镜像、执行了哪些操作、是否包含未清理的临时文件。而docker build配合多阶段构建（multi-stage build），则强制将构建环境与运行环境分离，确保最终镜像只含二进制文件和必要依赖，体积减少60%以上，漏洞扫描结果干净度提升3倍。

所以本文不打算罗列“30个Docker命令速查表”。我们要做的是：以真实交付场景为锚点，拆解每个安装步骤背后的系统级依赖，还原每条核心命令在CI流水线中的真实调用链路，把那些藏在docker run参数背后的工程决策逻辑，掰开揉碎讲清楚。当你下次再看到docker pull registry.example.com/app:2.1.0时，脑子里浮现的不该是“哦，这是拉镜像”，而应该是：“这条命令正在触发OCI分发协议，向registry发起HEAD请求校验manifest存在性，若命中本地缓存则跳过下载，否则并行拉取config blob和layer blobs，同时校验sha256摘要防篡改——而这一切的前提，是~/.docker/config.json中已正确配置了该registry的认证token”。

2. 安装不是点下一步：Linux/macOS/Windows三端的底层差异与避坑清单

Docker官方文档里那句“Download Docker Desktop for Windows/Mac”看似简单，实则埋着三条截然不同的技术路径。很多团队踩坑，不是因为不会用Docker，而是因为没意识到：在Windows上装Docker Desktop，在macOS上装Docker Desktop，在Linux服务器上装docker-ce，这三件事的技术本质完全不同，解决的问题也完全不同。把它们混为一谈，就像用同一份说明书安装电饭煲、燃气灶和中央空调。

2.1 Linux服务器：裸金属上的轻量守护进程

在Ubuntu 22.04服务器上安装Docker，本质是部署一个标准的systemd服务。这里没有虚拟机、没有图形界面、没有后台托盘，只有dockerd进程监听unix:///var/run/docker.sock。安装命令看似简单：

# 官方推荐方式（需root） curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER

但背后有五个必须手动确认的关键点：

1. 内核模块检查：Docker依赖overlay2存储驱动，要求内核版本≥4.0且启用CONFIG_OVERLAY_FS。执行zcat /proc/config.gz | grep OVERLAY（若存在）或grep CONFIG_OVERLAY_FS /boot/config-$(uname -r)。若返回空，说明内核不支持，必须升级内核或改用vfs驱动（性能下降40%，仅限调试）。

2. cgroup v2兼容性：Ubuntu 22.04默认启用cgroup v2，而部分老版本Docker（<20.10）仅支持cgroup v1。检查命令：cat /proc/1/cgroup | head -1。若显示0::/，则是cgroup v2；若显示11:cpuset:/，则是cgroup v1。不匹配会导致dockerd启动失败，报错failed to start daemon: cgroups: cgroup mountpoint does not exist。解决方案：编辑/etc/default/grub，在GRUB_CMDLINE_LINUX中添加systemd.unified_cgroup_hierarchy=0，然后update-grub && reboot。

3. Docker Root Dir磁盘空间：默认/var/lib/docker存放所有镜像、容器、卷。若服务器根分区只有20GB，docker system df很快会显示BUILD-CACHE占用90%空间。必须在/etc/docker/daemon.json中显式配置：

{ "data-root": "/data/docker", "storage-driver": "overlay2" }

注意：修改后需sudo systemctl restart docker，且首次重启会清空原有镜像——务必提前docker save导出关键镜像。

4. 防火墙端口放行：若服务器启用了ufw，需手动放行Docker守护进程端口（默认2376，仅限TLS加密访问）：

sudo ufw allow 2376/tcp # 若需本地socket访问（推荐），则确保/var/run/docker.sock权限正确： sudo chmod 660 /var/run/docker.sock sudo chgrp docker /var/run/docker.sock

5. Registry镜像源加速：国内直接拉取docker.io/library/ubuntu:22.04平均耗时2分30秒。必须配置国内镜像源，如阿里云：

{ "registry-mirrors": ["https://<your-id>.mirror.aliyuncs.com"] }

提示：镜像源URL中的<your-id>需登录阿里云容器镜像服务控制台获取，非通用地址。配置错误会导致docker pull超时而非报错，排查难度极大。

2.2 macOS：基于HyperKit的轻量虚拟机

macOS无法直接运行Linux容器，Docker Desktop在后台启动了一个极简Linux VM（基于HyperKit），dockerd运行在此VM中。因此，macOS上的“安装”本质是部署一个虚拟机管理器。关键差异点：

• 资源分配不可忽视：Docker Desktop默认仅分配2GB内存、2核CPU。当构建含Node.js前端+Java后端的复合镜像时，npm install和mvn compile会因内存不足被OOM Killer杀死。必须在Docker Desktop设置中手动调高：Settings → Resources → Memory调至6GB，CPUs调至4核。

• 文件挂载性能陷阱：-v $(pwd):/app将Mac目录挂载到容器，底层通过osxfs实现。当挂载目录含大量小文件（如node_modules）时，I/O性能比Linux原生慢5-8倍。解决方案：
  a) 将node_modules等构建产物排除在挂载外，改用COPY指令；
  b) 启用gRPC FUSE加速（Settings → General → Use the new Virtualization framework），需macOS 13.0+；
  c) 对于纯开发场景，改用docker build --target dev多阶段构建，直接在容器内执行npm install。

• DNS解析失效问题：容器内ping google.com通，但curl https://api.github.com超时。这是因为Docker Desktop的VM使用host.docker.internal作为宿主网关，但某些企业网络会拦截此域名。临时修复：在容器内执行echo "nameserver 8.8.8.8" > /etc/resolv.conf；长期方案：在/etc/docker/daemon.json中配置：

{ "dns": ["8.8.8.8", "114.114.114.114"] }

2.3 Windows：WSL2与Hyper-V的双轨制博弈

Windows安装最复杂，因存在两条技术路径：WSL2后端（推荐）和Hyper-V后端（传统）。二者互斥，且对硬件要求不同。

• WSL2路径（Windows 10 2004+/Windows 11）：
  需先启用WSL：wsl --install，自动安装WSL2内核更新包。Docker Desktop会将dockerd部署在默认WSL发行版（如Ubuntu-22.04）中。此时docker命令实际是Windows CLI调用WSL内的dockerd。优势：启动快、资源占用低；劣势：GPU直通需额外配置--gpus all且WSL2内核≥5.10。

• Hyper-V路径（旧版Windows）：
  需启用Windows功能：Turn Windows features on or off→ 勾选Hyper-V和Windows Subsystem for Linux。此时Docker Desktop创建独立VM，dockerd运行其中。优势：兼容性好；劣势：内存占用固定4GB，无法动态调整。

注意：若同时启用WSL2和Hyper-V，Docker Desktop会优先选择WSL2。但某些杀毒软件（如McAfee）会劫持Hyper-V导致WSL2启动失败，报错WslRegisterDistribution failed: 0x80370102。此时需彻底卸载杀软或在BIOS中关闭Secure Boot。

2.4 三端统一验证：一条命令测通全链路

无论哪一端安装完成，必须执行以下四步验证，缺一不可：

1. 守护进程健康检查：

   # Linux/macOS/WSL2: 检查dockerd状态 sudo systemctl is-active docker # 应返回 active # Windows PowerShell: 检查服务 Get-Service com.docker.service | Select-Object Status # 应为 Running

2. 客户端-服务端通信验证：

   docker version --format '{{.Server.Os}}/{{.Server.Arch}}' # 输出 linux/x86_64 或 windows/amd64

3. 镜像拉取与运行验证：

   # 强制指定平台，避免arm64镜像在amd64机器上拉取失败 docker pull --platform linux/amd64 nginx:alpine docker run -d -p 8080:80 --name test-nginx nginx:alpine curl -s http://localhost:8080 | grep -q "Welcome to nginx" && echo "✅ OK" || echo "❌ FAIL" docker stop test-nginx && docker rm test-nginx

4. 构建能力验证（工程化核心）：
   创建测试Dockerfile：

   FROM alpine:3.18 RUN apk add --no-cache curl && \ curl -s https://httpbin.org/get | grep -q "origin" && \ echo "Build-time network OK" CMD ["sh", "-c", "echo 'Runtime OK' && sleep 3600"]

   执行：docker build -t test-build . && docker run --rm test-build。若输出两行OK，则证明构建环境网络、运行时网络、基础指令均正常。

踩坑心得：某次线上发布失败，根本原因竟是CI服务器（Ubuntu 20.04）的dockerd版本为19.03，不支持--platform参数，导致ARM镜像构建失败。我们在本地（Docker Desktop 4.20）测试完美，却忘了CI环境版本一致性。自此，所有Docker相关脚本开头必加：docker version --format '{{.Client.Version}}' | grep -q "^20\|^21\|^22\|^23\|^24" || { echo "Docker version too old"; exit 1; }。

3. 核心命令的工程化重定义：从交互式操作到CI/CD流水线的语义映射

初学者眼中的docker run，是终端里敲出的一行命令；工程师眼中的docker run，是CI/CD流水线中一个严格受控的原子操作。它的参数不再是随意拼凑的字符串，而是承载着环境隔离、资源约束、安全策略、可观测性等多重工程意图的声明式契约。下面以四个高频命令为例，揭示其在真实交付场景中的深层语义。

3.1docker run：不只是启动容器，而是定义运行时契约

一条看似简单的命令：

docker run -d \ --name myapp \ -p 8080:8080 \ -e ENV=prod \ --memory=512m \ --cpus=1.5 \ --restart=unless-stopped \ myapp:1.2.0

在工程化视角下，每个参数都对应一项关键治理能力：

• -p 8080:8080：端口映射即网络策略声明。它隐含了“该容器必须绑定宿主机8080端口，且仅接受TCP流量”。在Kubernetes中，这会被翻译为Service的targetPort和port；在安全审计中，需确保该端口未被其他进程占用，且防火墙规则允许入站。

• --memory=512m：内存限制即SLO保障承诺。它告诉调度器：“此容器最大可用内存512MB，超限时将被OOM Killer终止”。若不设限，容器可能吃光宿主机内存，导致其他服务雪崩。实践中，需结合应用JVM堆内存（-Xmx384m）和非堆内存（元空间、直接内存）总和，预留20%余量。

• --cpus=1.5：CPU配额即服务质量分级。它并非分配1.5个物理核，而是设置CFS调度器的cpu.cfs_quota_us/cpu.cfs_period_us比例。值为1.5表示：每100ms周期内，最多使用150ms CPU时间。这对Java应用尤其关键——GC线程若被过度抢占，会导致STW时间飙升。

• --restart=unless-stopped：重启策略即可用性等级定义。它承诺：“除管理员主动docker stop外，容器崩溃、宿主机重启均自动恢复”。但要注意，它不解决应用启动失败循环（如数据库连接超时），此时需配合--health-cmd健康检查。

实战技巧：在CI流水线中，绝不用docker run直接启动生产服务。而是将其封装为docker service create（Swarm）或kubectl apply -f deployment.yaml（K8s）。docker run仅用于：

• 本地开发环境快速验证
• CI中执行一次性任务（如数据库迁移：docker run --rm -v $(pwd)/migrations:/migrate myapp-db migrate up）
• 安全扫描：docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image --severity HIGH,CRITICAL myapp:1.2.0

3.2docker build：构建过程即质量门禁

docker build常被误解为“打包工具”，实则是首个质量门禁（Quality Gate）。它强制将环境依赖、构建步骤、安全基线编码进Dockerfile，使每次构建都成为一次可验证的合规检查。

看一个工程化Dockerfile范例：

# 构建阶段：完全隔离的编译环境 FROM golang:1.21-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download # 预下载依赖，利用Docker layer cache COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main . # 运行阶段：极简安全镜像 FROM alpine:3.18 RUN apk --no-cache add ca-certificates && \ update-ca-certificates WORKDIR /root/ COPY --from=builder /app/main . EXPOSE 8080 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD wget --quiet --tries=1 --spider http://localhost:8080/health || exit 1 CMD ["./main"]

此Dockerfile蕴含的工程实践：

• 多阶段构建（Multi-stage）：AS builder定义构建上下文，--from=builder仅复制二进制文件。最终镜像不含Go编译器、源码、go.mod，体积从1.2GB降至12MB，漏洞数量减少98%。

• 确定性依赖：go mod download显式下载依赖，避免go build时网络波动导致构建失败。Docker layer cache机制确保：仅当go.mod变更时才重新下载，大幅提升CI构建速度。

• 安全加固：

  • 基础镜像选用alpine:3.18（非latest），确保CVE漏洞库可追溯；
  • apk --no-cache避免残留包管理器缓存；
  • HEALTHCHECK定义容器就绪探针，K8s将据此判断Pod是否Ready。

关键经验：在CI中，docker build命令必须携带--progress=plain --no-cache参数。--progress=plain输出详细日志，便于定位哪一层构建失败；--no-cache强制忽略本地cache，确保每次构建都基于最新代码和基础镜像，杜绝“本地能跑，CI失败”的幽灵问题。

3.3docker push：推送即制品入库，触发下游流程

docker push registry.example.com/myapp:1.2.0表面是上传镜像，实则是触发整个交付流水线的“发布事件”。它要求：

• 镜像命名规范：registry.example.com/namespace/repo:tag中，namespace通常为团队名（如backend），repo为服务名（如user-service），tag必须为语义化版本（1.2.0）或Git SHA（git-abc1234），禁用latest。CI脚本中应自动生成：

  # 从Git tag提取版本号 VERSION=$(git describe --tags --abbrev=0 2>/dev/null || echo "dev-$(git rev-parse --short HEAD)") docker tag myapp:latest registry.example.com/backend/user-service:$VERSION docker push registry.example.com/backend/user-service:$VERSION

• 镜像签名与验证：生产环境必须启用Docker Content Trust（DCT）。推送前需：

  export DOCKER_CONTENT_TRUST=1 docker push registry.example.com/backend/user-service:$VERSION

  此时Docker会用本地密钥对镜像manifest签名，并上传到notary服务。下游部署时，docker pull自动验证签名，防止恶意镜像注入。

• 仓库配额与生命周期：企业级registry（如Harbor）支持按项目设置配额和镜像保留策略。例如：backend项目配额50GB，自动删除超过30天且未被任何Deployment引用的镜像标签。docker push成功，意味着该制品已进入受控生命周期管理。

3.4docker exec：调试即特权操作，需最小权限原则

docker exec -it myapp sh是开发者最爱的命令，但在工程化环境中，它代表最高风险的操作。生产容器应禁止交互式shell，所有调试必须通过标准化接口。

• 安全替代方案：

  • 日志：docker logs -f --tail 100 myapp（实时查看最后100行）
  • 指标：容器内暴露/metrics端点，通过Prometheus抓取
  • 追踪：集成OpenTelemetry，链路数据上报至Jaeger
  • 配置：通过ConfigMap/Secret挂载配置，热更新无需重启

• 若必须exec，遵循最小权限：

  # 错误：获得root shell docker exec -it myapp sh # 正确：以非root用户执行诊断命令 docker exec -u 1001 myapp curl -s http://localhost:8080/actuator/health # 更安全：使用专用诊断镜像 docker run --rm --network container:myapp \ -v /var/run/docker.sock:/var/run/docker.sock \ nicolaka/netshoot curl -s http://localhost:8080/health

血泪教训：曾有个团队为方便，给所有生产容器配置--privileged并开放2375端口。黑客通过未授权API调用docker exec -u 0获取root shell，进而挖矿、窃取凭证。自此，我们所有CI流水线增加硬性检查：docker inspect myapp | jq -r '.HostConfig.Privileged,.HostConfig.PortBindings' | grep -q "true\|2375"，命中即失败。

4. 从零搭建可复现的工程化环境：一个真实项目的端到端实战

理论终需落地。下面以一个真实的Spring Boot微服务（订单服务）为例，演示如何从空白服务器开始，构建一套可复现、可审计、可交付的Docker工程化环境。所有步骤均可在Ubuntu 22.04服务器上一键执行，无任何人工干预。

4.1 环境初始化：自动化脚本确保环境一致性

创建setup-env.sh，内容如下：

#!/bin/bash set -e # 任一命令失败即退出 echo "=== 步骤1：更新系统并安装基础工具 ===" sudo apt update && sudo apt upgrade -y sudo apt install -y curl wget git jq echo "=== 步骤2：安装Docker CE ===" curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER echo "=== 步骤3：配置Docker守护进程 ===" sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json <<-'EOF' { "data-root": "/data/docker", "storage-driver": "overlay2", "registry-mirrors": ["https://<your-aliyun-id>.mirror.aliyuncs.com"], "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } } EOF echo "=== 步骤4：启动Docker并验证 ===" sudo systemctl enable docker sudo systemctl start docker sudo systemctl is-active docker echo "=== 步骤5：安装Docker Compose v2 ===" sudo mkdir -p /usr/libexec/docker/cli-plugins curl -SL https://github.com/docker/compose/releases/download/v2.20.2/docker-compose-linux-x86_64 -o /usr/libexec/docker/cli-plugins/docker-compose sudo chmod +x /usr/libexec/docker/cli-plugins/docker-compose echo "✅ 环境初始化完成！执行 'docker version' 验证"

执行：chmod +x setup-env.sh && ./setup-env.sh。此脚本确保：

• Docker数据目录独立于系统盘，避免/var分区爆满；
• 镜像源配置为国内加速，规避网络超时；
• 日志采用json-file驱动并限制大小，防止日志占满磁盘；
• Compose安装为v2插件模式，与Docker CLI深度集成。

4.2 订单服务Docker化：从代码到可交付制品

假设订单服务代码结构如下：

order-service/ ├── src/ ├── pom.xml ├── Dockerfile └── docker-compose.yml

Dockerfile内容（严格遵循工程化最佳实践）：

# 构建阶段：使用Maven官方镜像，预下载依赖 FROM maven:3.8.6-openjdk-17-slim AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B # 离线下载所有依赖 COPY src ./src RUN mvn clean package -DskipTests # 运行阶段：基于JRE的极简镜像 FROM openjdk:17-jre-slim VOLUME ["/tmp"] # 为Spring Boot创建临时文件预留 ARG JAR_FILE=target/*.jar COPY --from=builder /app/$JAR_FILE app.jar EXPOSE 8080 HEALTHCHECK --interval=30s --timeout=3s --start-period=30s --retries=3 \ CMD curl -f http://localhost:8080/actuator/health || exit 1 ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

关键设计说明：

• mvn dependency:go-offline确保依赖下载与编译分离，充分利用Docker layer cache；
• openjdk:17-jre-slim比openjdk:17-jdk体积小60%，且不含编译器，符合最小化原则；
• HEALTHCHECK指向Spring Boot Actuator端点，与K8s探针无缝对接。

4.3 CI流水线脚本：GitHub Actions完整配置

.github/workflows/ci.yml：

name: Order Service CI on: push: branches: [main] tags: ['v*.*.*'] pull_request: branches: [main] jobs: build-and-test: runs-on: ubuntu-22.04 steps: - uses: actions/checkout@v3 - name: Set up JDK 17 uses: actions/setup-java@v3 with: java-version: '17' distribution: 'temurin' - name: Build with Maven run: mvn -B clean package -DskipTests - name: Build Docker image run: | docker build -t order-service:${{ github.sha }} . # 扫描镜像安全漏洞 docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \ aquasec/trivy image --severity HIGH,CRITICAL order-service:${{ github.sha }} - name: Push to Registry if: startsWith(github.ref, 'refs/tags/') run: | echo "${{ secrets.DOCKER_PASSWORD }}" | docker login -u "${{ secrets.DOCKER_USERNAME }}" --password-stdin docker tag order-service:${{ github.sha }} registry.example.com/backend/order-service:${{ github.head_ref }} docker push registry.example.com/backend/order-service:${{ github.head_ref }}

此流水线实现：

• 分支保护：PR提交时仅构建测试，Tag推送时才触发镜像推送；
• 安全门禁：trivy扫描高危漏洞，任一HIGH及以上漏洞即中断流水线；
• 制品溯源：镜像Tag与Git Commit SHA强绑定，docker inspect可查构建上下文。

4.4 生产部署：Docker Compose的工程化用法

docker-compose.yml（用于Staging环境）：

version: '3.8' services: order-service: image: registry.example.com/backend/order-service:main ports: - "8080:8080" environment: - SPRING_PROFILES_ACTIVE=staging - DB_URL=jdbc:postgresql://postgres:5432/orderdb depends_on: postgres: condition: service_healthy healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"] interval: 30s timeout: 10s retries: 5 start_period: 40s postgres: image: postgres:15-alpine environment: POSTGRES_DB: orderdb POSTGRES_USER: orderuser POSTGRES_PASSWORD: orderpass volumes: - postgres-data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U orderuser -d orderdb"] interval: 30s timeout: 10s retries: 5 volumes: postgres-data:

工程化要点：

• depends_on.condition: service_healthy确保PostgreSQL真正就绪（而不仅是容器启动），避免应用启动时连接数据库失败；
• healthcheck使用pg_isready而非exit 0，真实检测数据库服务可用性；
• 卷postgres-data使用命名卷，数据持久化且与宿主机路径解耦。

4.5 验证与监控：交付后的持续保障

部署后，执行端到端验证脚本verify-deploy.sh：

#!/bin/bash # 检查容器状态 if ! docker compose ps | grep "order-service" | grep "running" > /dev/null; then echo "❌ order-service not running" exit 1 fi # 检查健康状态 if ! docker compose exec order-service curl -s http://localhost:8080/actuator/health | jq -r '.status' | grep -q "UP"; then echo "❌ order-service health check failed" exit 1 fi # 检查数据库连接 if ! docker compose exec order-service curl -s "http://localhost:8080/api/orders/test" | grep -q "test-order"; then echo "❌ database connectivity test failed" exit 1 fi echo "✅ All verification passed!"

最后分享一个硬核技巧：在所有Docker相关脚本中，加入set -o pipefail。它确保管道中任一命令失败，整个管道即返回非零退出码。例如：docker images | grep myapp | wc -l，若grep未找到匹配项（返回1），wc仍会输出0，导致脚本误判。pipefail让这种错误无处遁形——这是我们在200+次生产事故复盘中，总结出的最有效防御手段之一。