Docker实战案例：从开发到部署的平滑落地

公司新上线了一个电商促销系统，ref="/tag/156/" style="color:#874873;font-weight:bold;">开发团队在本地跑得好好的，一上测试环境就出问题。数据库连不上，依赖版本对不上，运维还得一个个手动装环境。这样的场景太常见了，直到我们引入了 Docker。

用容器统一开发与生产环境

我们给整个应用打包成几个容器：前端用 Nginx + React，后端是 Spring Boot，数据库是 MySQL，再加个 Redis 做缓存。每个服务写一个 Dockerfile，比如后端服务：

FROM openjdk:11-jre-slim
WORKDIR /app
COPY app.jar .
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

开发人员不再需要本地装 Java 环境、Maven、MySQL。拉下代码，docker-compose 启动，三分钟所有服务就位。前端改了样式，也不用担心和后端接口对不上，因为大家跑的都是同一个镜像基线。

CI/CD 流水线中的实际运用

我们在 GitLab 上配置了 CI 脚本，每次 push 代码，自动构建镜像并推送到私有仓库。Kubernetes 集群监听镜像更新，自动拉取并滚动发布。整个过程无需人工登录服务器，发布失败也能快速回滚。

deploy:
  stage: deploy
  script:
    - docker build -t registry.zhiyitong.com/promo-backend:$CI_COMMIT_TAG .
    - docker push registry.zhiyitong.com/promo-backend:$CI_COMMIT_TAG
    - kubectl set image deployment/promo-deployment backend=registry.zhiyitong.com/promo-backend:$CI_COMMIT_TAG

有一次线上发现一个空指针异常，开发修复后提交，不到十分钟，新版本已经在生产运行。这种效率在过去是不可想象的。

多环境隔离，避免“我本地没问题”

我们用 Docker Compose 定义了三套配置：dev、test、prod。通过环境变量控制数据库连接地址和日志级别。测试环境模拟高并发，直接用 docker-compose up 启动多个实例，压力测试完一键销毁。

version: '3'
services:
  backend:
    image: promo-backend:latest
    environment:
      - SPRING_PROFILES_ACTIVE=prod
      - DB_HOST=mysql-prod
    ports:
      - "8080:8080"

以前 QA 总抱怨“开发说修了，我这还是错的”，现在他们只要确认镜像版本一致，问题边界立刻清晰。

资源利用率提升明显

物理机时代，每个服务独占一台虚拟机，内存 8G 只用到 2G。换成容器后，同一台机器跑七八个服务互不干扰。监控显示平均资源利用率从 25% 提升到 65%，节省了一半以上的云服务器成本。

某次大促前，临时扩容三个后端实例，Docker 秒级启动，Nginx 自动注册 upstream。活动结束，容器自动回收。弹性伸缩不再是口号，而是每天都能操作的日常。