第3章 Docker的功能特性

3.1 环境一致性保证

"在我机器上能运行"的困境

传统开发中常见的问题：

开发环境 (MacOS) 测试环境 (Ubuntu 20.04) 生产环境 (CentOS 7) ├── Python 3.10 ├── Python 3.8 ├── Python 3.6 ├── MySQL 8.0 ├── MySQL 5.7 ├── MariaDB 10.3 ├── Redis 7.0 ├── Redis 6.2 ├── Redis 5.0 └── Node.js 18 └── Node.js 16 └── Node.js 14 结果：同一份代码在不同环境表现不一致！

Docker如何保证一致性

Docker通过打包整个运行环境解决这个问题：

FROM python:3.9-slim # 安装系统依赖 RUN apt-get update && apt-get install -y \ gcc \ libpq-dev \ && rm -rf /var/lib/apt/lists/* # 设置工作目录 WORKDIR /app # 复制依赖文件 COPY requirements.txt . # 安装Python依赖 RUN pip install --no-cache-dir -r requirements.txt # 复制应用代码 COPY . . # 设置环境变量 ENV FLASK_APP=app.py ENV FLASK_ENV=production # 暴露端口 EXPOSE 5000 # 启动命令 CMD ["flask", "run", "--host=0.0.0.0"]

关键要素：

1. 确定性的基础镜像：python:3.9-slim保证基础环境一致
2. 声明式依赖管理：requirements.txt锁定依赖版本
3. 环境变量配置：统一的配置方式
4. 启动命令标准化：相同的启动流程

一次构建，到处运行

# 开发环境构建dockerbuild -t myapp:1.0.# 开发环境运行dockerrun -d -p5000:5000 myapp:1.0# 推送到仓库dockerpush registry.company.com/myapp:1.0# 测试环境部署（完全相同的镜像）sshtest-serverdockerpull registry.company.com/myapp:1.0dockerrun -d -p5000:5000 registry.company.com/myapp:1.0# 生产环境部署（完全相同的镜像）sshprod-serverdockerpull registry.company.com/myapp:1.0dockerrun -d -p5000:5000 registry.company.com/myapp:1.0

保证：所有环境运行的是完全相同的二进制文件和配置。

配置与代码分离

虽然镜像保持一致，但不同环境的配置可以不同：

# 开发环境：使用开发数据库dockerrun -d\-eDB_HOST=localhost\-eDB_PORT=5432\-eDB_NAME=dev_db\-eDEBUG=true\myapp:1.0# 生产环境：使用生产数据库dockerrun -d\-eDB_HOST=prod-db.company.com\-eDB_PORT=5432\-eDB_NAME=prod_db\-eDEBUG=false\myapp:1.0

或使用配置文件：

# 使用不同的配置文件dockerrun -d -v /config/dev.env:/app/.env myapp:1.0# 开发dockerrun -d -v /config/prod.env:/app/.env myapp:1.0# 生产

依赖版本锁定

Python示例：

# requirements.txt - 锁定具体版本 Flask==2.3.0 SQLAlchemy==2.0.15 psycopg2-binary==2.9.6 redis==4.5.5

Node.js示例：

{"dependencies":{"express":"4.18.2","mongoose":"7.0.3","redis":"4.6.5"}}

Docker镜像包含这些确定版本的依赖，避免"依赖地狱"。

3.2 快速部署与扩展

快速部署

传统部署流程

1. 准备服务器 (15分钟) 2. 安装操作系统 (30分钟) 3. 配置网络和安全 (20分钟) 4. 安装运行时 (Python/Node.js) (15分钟) 5. 安装系统依赖 (10分钟) 6. 部署应用代码 (10分钟) 7. 配置服务自启动 (10分钟) 8. 测试验证 (20分钟) 总计：约2-3小时

Docker部署流程

# 一条命令，30秒完成dockerrun -d -p80:80 myapp:latest# 或使用Docker Composedocker-composeup -d

时间对比：

• 传统方式：2-3小时
• Docker方式：30秒
• 提速200倍+

水平扩展

当流量增加时，快速扩展实例：

# 运行3个相同的应用实例dockerrun -d --name app1 -p8001:80 myapp:latestdockerrun -d --name app2 -p8002:80 myapp:latestdockerrun -d --name app3 -p8003:80 myapp:latest# 配合负载均衡器（如Nginx）分发流量

使用Docker Compose扩展：

# 启动1个实例docker-composeup -d# 扩展到5个实例docker-composeup -d --scaleweb=5

# docker-compose.ymlversion:'3'services:web:image:myapp:latest# 不指定具体端口，让Docker自动分配nginx:image:nginx:latestports:-"80:80"volumes:-./nginx.conf:/etc/nginx/nginx.conf

蓝绿部署

无停机更新应用：

# 当前运行 v1.0（绿色环境）dockerrun -d --name app-green -p80:80 myapp:1.0# 启动 v2.0（蓝色环境）dockerrun -d --name app-blue -p8080:80 myapp:2.0# 测试 v2.0curlhttp://localhost:8080# 切换流量到 v2.0（通过负载均衡器）# 停止 v1.0dockerstop app-greendockerrmapp-green# 如果v2.0有问题，快速回滚dockerstop app-bluedockerstart app-green

金丝雀发布

逐步切换流量到新版本：

# 运行4个v1.0实例dockerrun -d --name app1 myapp:1.0dockerrun -d --name app2 myapp:1.0dockerrun -d --name app3 myapp:1.0dockerrun -d --name app4 myapp:1.0# 将1个实例更新到v2.0（25%流量）dockerstop app4dockerrun -d --name app4 myapp:2.0# 观察指标，如果正常，继续替换其他实例dockerstop app3dockerrun -d --name app3 myapp:2.0# 逐步完成全部替换

自动化部署

结合CI/CD实现自动部署：

# GitLab CI 示例stages:-build-test-deploybuild:stage:buildscript:-docker build-t myapp:$CI_COMMIT_SHA .-docker push myapp:$CI_COMMIT_SHAtest:stage:testscript:-docker run myapp:$CI_COMMIT_SHA pytestdeploy_production:stage:deployscript:-docker pull myapp:$CI_COMMIT_SHA-docker stop myapp-prod||true-docker rm myapp-prod||true-docker run-d--name myapp-prod-p 80:80 myapp:$CI_COMMIT_SHAonly:-main

3.3 资源隔离与限制

为什么需要资源限制

没有资源限制的风险：

场景：3个容器共享主机 - 容器A：正常应用，需要1GB内存 - 容器B：正常应用，需要1GB内存 - 容器C：出现内存泄漏，无限增长 结果：容器C占满所有内存，导致容器A、B和宿主机崩溃！

CPU资源限制

限制CPU份额（相对值）

# 设置CPU份额为512（默认1024）dockerrun -d --cpu-shares=512nginx# 两个容器的CPU使用比例dockerrun -d --name app1 --cpu-shares=1024myapp# 得到66.7%dockerrun -d --name app2 --cpu-shares=512myapp# 得到33.3%

注意：--cpu-shares是相对权重，只在CPU竞争时生效。

限制CPU核心数（绝对值）

# 限制使用1.5个CPU核心dockerrun -d --cpus="1.5"nginx# 限制使用特定的CPU核心（0和1）dockerrun -d --cpuset-cpus="0,1"nginx# 限制CPU使用率上限为50%dockerrun -d --cpu-quota=50000--cpu-period=100000nginx

实践建议：

# 开发环境：不限制dockerrun -d myapp# 测试环境：限制CPU防止干扰dockerrun -d --cpus="2"myapp# 生产环境：根据性能测试结果精确限制dockerrun -d --cpus="4"--memory="4g"myapp

内存资源限制

限制内存大小

# 限制最大内存为512MBdockerrun -d --memory="512m"nginx# 限制内存和交换空间总和为1GBdockerrun -d --memory="512m"--memory-swap="1g"nginx# 禁用交换空间dockerrun -d --memory="512m"--memory-swap="512m"nginx

OOM行为控制

# 当内存不足时，不要杀死容器（慎用）dockerrun -d --memory="512m"--oom-kill-disable nginx# 设置OOM分数调整值（-1000到1000，值越低越不容易被杀死）dockerrun -d --memory="512m"--oom-score-adj=-500 nginx

内存预留

# 预留256MB内存（软限制）dockerrun -d --memory="1g"--memory-reservation="256m"nginx

当内存不足时，Docker会尝试将容器内存使用降到预留值以下。

磁盘I/O限制

# 限制块设备读取速度为1MB/sdockerrun -d --device-read-bps /dev/sda:1mb nginx# 限制块设备写入速度为1MB/sdockerrun -d --device-write-bps /dev/sda:1mb nginx# 限制读取IOPS为100dockerrun -d --device-read-iops /dev/sda:100 nginx# 限制写入IOPS为100dockerrun -d --device-write-iops /dev/sda:100 nginx# 设置I/O权重（相对值，10-1000）dockerrun -d --blkio-weight500nginx

资源限制实战示例

# docker-compose.yml - 完整的资源限制配置version:'3.8'services:web:image:myapp:latestdeploy:resources:limits:cpus:'2'memory:2Greservations:cpus:'1'memory:1Grestart:unless-stoppeddatabase:image:postgres:13deploy:resources:limits:cpus:'4'memory:4Greservations:cpus:'2'memory:2Gvolumes:-db-data:/var/lib/postgresql/datacache:image:redis:6deploy:resources:limits:cpus:'1'memory:512Mreservations:cpus:'0.5'memory:256Mvolumes:db-data:

查看资源使用情况

# 实时查看所有容器的资源使用dockerstats# 查看特定容器的资源使用dockerstats myapp# 输出示例：# CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O# myapp 2.5% 256MiB / 512MiB 50% 1.2kB / 648B 0B / 0B

3.4 版本控制与回滚机制

镜像标签策略

语义化版本

# 使用语义化版本号dockerbuild -t myapp:1.0.0.dockerbuild -t myapp:1.1.0.dockerbuild -t myapp:2.0.0.# 同时打多个标签dockertag myapp:1.1.0 myapp:1.1dockertag myapp:1.1.0 myapp:1dockertag myapp:1.1.0 myapp:latest

Git提交哈希

# 使用Git提交哈希作为标签GIT_HASH=$(gitrev-parse --short HEAD)dockerbuild -t myapp:$GIT_HASH.dockertag myapp:$GIT_HASHmyapp:latest# 可追溯到具体代码版本dockerrun -d myapp:a3f7c8e

时间戳标签

# 使用时间戳TIMESTAMP=$(date+%Y%m%d-%H%M%S)dockerbuild -t myapp:$TIMESTAMP.# 示例：myapp:20260210-143022

版本回滚

简单回滚

# 当前运行v2.0，出现问题dockerstop myappdockerrmmyapp# 回滚到v1.0dockerrun -d --name myapp -p80:80 myapp:1.0

保留多个版本

# 同时保留多个版本的镜像dockerimages# REPOSITORY TAG IMAGE ID SIZE# myapp 3.0 abc123 200MB# myapp 2.0 def456 195MB# myapp 1.0 ghi789 180MB# 快速切换版本dockerstop myapp-v3dockerrun -d --name myapp-v2 -p80:80 myapp:2.0

使用数据卷保持数据

# 升级时保持数据不丢失dockerrun -d\--name myapp-v1\-v app-data:/app/data\-p80:80\myapp:1.0# 升级到v2.0，数据卷复用dockerstop myapp-v1dockerrun -d\--name myapp-v2\-v app-data:/app/data\-p80:80\myapp:2.0# 如需回滚，数据依然完整dockerstop myapp-v2dockerrun -d\--name myapp-v1-rollback\-v app-data:/app/data\-p80:80\myapp:1.0

镜像历史追踪

# 查看镜像构建历史dockerhistorymyapp:2.0# 查看镜像详细信息（包括构建时间、标签等）dockerimage inspect myapp:2.0# 导出镜像历史到JSONdockerimage inspect myapp:2.0 --format='{{json .}}'|jq

回滚策略最佳实践

# docker-compose.yml - 蓝绿部署配置version:'3.8'services:app-blue:image:myapp:${BLUE_VERSION:-1.0}ports:-"8080:80"environment:-COLOR=blueapp-green:image:myapp:${GREEN_VERSION:-2.0}ports:-"8081:80"environment:-COLOR=greennginx:image:nginx:latestports:-"80:80"volumes:-./nginx.conf:/etc/nginx/nginx.confdepends_on:-app-blue-app-green

切换版本：

# 当前使用blue（v1.0）exportBLUE_VERSION=1.0exportGREEN_VERSION=2.0docker-composeup -d# 切换到green（v2.0），通过修改nginx配置# 如需回滚，再次切换nginx配置到blue

3.5 微服务架构的支持

单体应用 vs 微服务

单体应用：

┌─────────────────────────────┐ │ Monolithic App │ │ ┌─────────────────────┐ │ │ │ User Module │ │ │ │ Order Module │ │ │ │ Payment Module │ │ │ │ Product Module │ │ │ └─────────────────────┘ │ │ ┌─────────────────────┐ │ │ │ Database │ │ │ └─────────────────────┘ │ └─────────────────────────────┘

微服务架构：

┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ User │ │ Order │ │ Payment │ │ Product │ │ Service │ │ Service │ │ Service │ │ Service │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ │DB │ │DB │ │DB │ │DB │ └───┘ └───┘ └───┘ └───┘

Docker与微服务的契合

1. 服务隔离

每个微服务运行在独立容器中：

# 用户服务dockerrun -d --name user-service -p8001:80 user-service:1.0# 订单服务dockerrun -d --name order-service -p8002:80 order-service:1.0# 支付服务dockerrun -d --name payment-service -p8003:80 payment-service:1.0# 商品服务dockerrun -d --name product-service -p8004:80 product-service:1.0

2. 独立部署

# 只更新订单服务，不影响其他服务dockerstop order-servicedockerrmorder-servicedockerrun -d --name order-service -p8002:80 order-service:2.0

3. 独立扩展

# 订单服务访问量大，扩展为3个实例dockerrun -d --name order-service-1 -p8002:80 order-service:1.0dockerrun -d --name order-service-2 -p8003:80 order-service:1.0dockerrun -d --name order-service-3 -p8004:80 order-service:1.0# 其他服务保持1个实例

Docker Compose管理微服务

# docker-compose.ymlversion:'3.8'services:user-service:build:./user-serviceports:-"8001:80"environment:-DB_HOST=user-dbdepends_on:-user-dbnetworks:-microservicesorder-service:build:./order-serviceports:-"8002:80"environment:-DB_HOST=order-db-USER_SERVICE_URL=http://user-servicedepends_on:-order-db-user-servicenetworks:-microservicespayment-service:build:./payment-serviceports:-"8003:80"environment:-DB_HOST=payment-db-ORDER_SERVICE_URL=http://order-servicedepends_on:-payment-db-order-servicenetworks:-microservicesproduct-service:build:./product-serviceports:-"8004:80"environment:-DB_HOST=product-dbdepends_on:-product-dbnetworks:-microservices# 数据库服务user-db:image:postgres:13environment:-POSTGRES_DB=user_dbnetworks:-microservicesorder-db:image:postgres:13environment:-POSTGRES_DB=order_dbnetworks:-microservicespayment-db:image:postgres:13environment:-POSTGRES_DB=payment_dbnetworks:-microservicesproduct-db:image:postgres:13environment:-POSTGRES_DB=product_dbnetworks:-microservices# API网关api-gateway:image:nginx:latestports:-"80:80"volumes:-./nginx.conf:/etc/nginx/nginx.confdepends_on:-user-service-order-service-payment-service-product-servicenetworks:-microservicesnetworks:microservices:driver:bridge

启动所有服务：

docker-composeup -d

服务发现与通信

容器间通过服务名通信：

# order-service中调用user-serviceimportrequests# 使用服务名作为主机名user_data=requests.get('http://user-service/api/users/123')

Docker自动解析服务名到容器IP。

微服务监控

# 添加监控服务services:prometheus:image:prom/prometheusports:-"9090:9090"volumes:-./prometheus.yml:/etc/prometheus/prometheus.ymlnetworks:-microservicesgrafana:image:grafana/grafanaports:-"3000:3000"environment:-GF_SECURITY_ADMIN_PASSWORD=adminnetworks:-microservices

3.6 小结

通过本章学习，我们掌握了Docker的五大核心功能特性：

✅环境一致性

• 通过镜像封装完整运行环境
• 一次构建，到处运行
• 配置与代码分离

✅快速部署与扩展

• 秒级启动容器
• 快速水平扩展
• 支持蓝绿部署和金丝雀发布
• 自动化CI/CD集成

✅资源隔离与限制

• CPU、内存、磁盘I/O限制
• 防止资源耗尽
• 精确的资源配额管理

✅版本控制与回滚

• 镜像标签管理
• 快速版本切换
• 数据持久化保证安全回滚

✅微服务架构支持

• 服务隔离
• 独立部署和扩展
• 服务发现和通信
• 完整的微服务生态

实践建议

1. 开发环境：使用Docker保证团队环境一致
2. 测试环境：使用资源限制防止相互干扰
3. 生产环境：结合编排工具（Kubernetes）管理大规模部署
4. 监控告警：始终监控容器资源使用情况

3.7 下一步

在第4章中，我们将学习Docker的安装与配置：

• Linux系统安装Docker
• Docker Desktop（Windows/macOS）
• Docker配置文件详解
• 镜像加速器配置
• 权限与用户组设置

掌握正确的安装和配置是后续实践的基础。

本章思考题：

1. 在你的项目中，如何利用Docker的环境一致性特性避免"在我机器上能运行"的问题？
2. 什么场景下需要限制容器的资源使用？如何设置合理的限制值？
3. 微服务架构中，每个服务应该如何设计镜像和配置管理？
4. 如何设计一个安全的版本回滚策略？

相关资源：

• Docker资源限制文档：https://docs.docker.com/config/containers/resource_constraints/
• 12-Factor App：https://12factor.net/
• 微服务设计模式：https://microservices.io/patterns/