企业级 Docker 运维与管理百科指南（CRUD 视角与实战场景）

企业级 Docker 运维与管理百科指南（CRUD 视角与实战场景）

本指南以结构化的 CRUD（增、删、改、查） 逻辑为核心，提炼了企业生产环境中高频使用的 Docker 管理命令，并对关键参数、应用场景、配置策略及排错流程进行了深度拆解，旨在帮助运维与开发团队规范容器化标准作业。

---

目录

1. Docker 镜像管理（CRUD 视角）
2. Docker 容器管理（CRUD 视角）
3. Docker 网络管理（CRUD 视角）
4. Docker 存储管理（CRUD 视角）
5. Docker 指定启动命令（COMMAND 机制详解）
6. Docker 指定环境变量与工作目录
7. Docker 容器重启策略（自愈配置）
8. Docker 日常故障排错方法论
9. 企业应用部署实战：生产级三层架构全流程落地

---

1. Docker 镜像管理（CRUD 视角）

镜像管理是容器化的起点。在企业中，镜像的操作涉及拉取、构建、优化、标记及安全清理。

                       [ 增 (Pull/Build) ]
                               │
                               ▼
  [ 删 (rmi/prune) ] <─── 镜像仓库/本地 ───> [ 查 (images/inspect) ]
                               │
                               ▼
                       [ 改 (tag/push) ]

增（Create / Pull / Build）

• 从仓库拉取镜像：

  docker pull reg.enterprise.com/infra/nginx:1.25.3
  

  • reg.enterprise.com/infra/nginx：指定私有仓库及项目路径。
  • :1.25.3：明确版本标签，生产环境避免使用无版本指代的 latest。
• 通过 Dockerfile 构建镜像：

  docker build --pull --no-cache -t reg.enterprise.com/web/api:v1.0.0 -f ./Dockerfile.prod .
  

  • --pull：强制拉取最新的基础镜像（FROM 阶段声明的镜像）。
  • --no-cache：弃用本地缓存层，确保依赖包重新下载，避免安全漏洞。
  • -t：定义镜像标签（Tag）。
  • -f：指定 Dockerfile 路径。
  • .：构建上下文路径。
• 离线导入镜像：

  docker load -i /data/offline/redis-7.0.tar
  

  • -i：指定输入的压缩包路径，该命令能完整保留镜像的元数据和历史层。

删（Delete）

• 删除指定镜像：

  docker rmi reg.enterprise.com/infra/nginx:1.25.3
  

  • 注：若有容器（即使已停止）正在使用该镜像，需先删除容器或追加 -f 强行删除。
• 清理无用镜像（清理虚悬镜像 <none>:<none>）：

  docker image prune -f
  

  • -f / --force：强制执行，跳过交互式确认。

改（Update / Tag）

• 修改镜像标签（重命名）：

  docker tag local-api:test reg.enterprise.com/web/api:v1.0.0
  

  • 常用于将本地测试通过的镜像打上私有仓库的前缀，准备推送至生产环境。
• 推送镜像至仓库：

  docker push reg.enterprise.com/web/api:v1.0.0
  

查（Read）

• 查看本地镜像列表：

  docker images
  

• 查看镜像底层元数据（包括环境变量、作者、层级信息等）：

  docker inspect reg.enterprise.com/web/api:v1.0.0
  

• 查看镜像构建层级历史（用于分析镜像大小和寻找瘦身优化点）：

  docker history reg.enterprise.com/web/api:v1.0.0
  

---

2. Docker 容器管理（CRUD 视角）

容器是镜像的运行实例。容器管理涵盖了其生命周期、状态控制和资源配额的管理。

增（Create / Run）

• 创建并运行容器（最常用组合）：

  docker run -d --name app-service -p 8080:80 reg.enterprise.com/web/api:v1.0.0
  

  • -d：后台（Detach）模式运行。
  • --name：赋予容器易读且唯一的名称，便于后续管理。
  • -p：宿主机端口到容器内部端口的映射。

删（Delete）

• 删除处于停止状态的容器：

  docker rm app-service
  

• 强制删除运行中的容器：

  docker rm -f app-service
  

  • -f / --force：发送 SIGKILL 信号强制停止并清理容器。
• 批量清理所有已停止的容器：

  docker container prune -f
  

改（Update Status / Limits）

• 变更容器运行状态：

  docker start app-service     # 启动已停止的容器
  docker stop -t 15 app-service # 优雅停止（等待 15 秒不退出则发送 SIGKILL）
  docker restart app-service   # 重启容器
  

• 动态调整容器资源限制（无需重建容器）：

  docker update -m 1g --memory-swap 2g --cpus="2.0" app-service
  

  • -m：调整内存限制。
  • --memory-swap：调整内存+交换分区总额。
  • --cpus：调整 CPU 核心数。

查（Read / Monitor）

• 查看正在运行的容器：

  docker ps
  

• 查看所有容器（包括已停止的）：

  docker ps -a
  

• 实时监控容器资源消耗：

  docker stats --no-stream
  

---

3. Docker 网络管理（CRUD 视角）

网络是微服务容器互联的基石。在企业中，容器通常需要加入自定义网桥，以支持容器名（DNS）相互解析和安全隔离。

                       [ 增 (network create) ]
                                 │
                                 ▼
[ 删 (network rm/prune) ] <─── 网络栈 ───> [ 查 (network ls/inspect) ]
                                 │
                                 ▼
                [ 改 (network connect/disconnect) ]

增（Create）

• 创建自定义桥接网络：

  docker network create \
    --driver bridge \
    --subnet 172.24.0.0/16 \
    --gateway 172.24.0.1 \
    prod-bridge-net
  

  • --driver bridge：指定网络驱动，多单机环境推荐自定义 bridge。
  • --subnet：指定网段，防止与公司物理局域网冲突。
  • --gateway：设置该网络的默认网关。

删（Delete）

• 删除指定网络：

  docker network rm prod-bridge-net
  

• 批量清理所有未使用的网络：

  docker network prune -f
  

改（Update Connection）

• 动态将运行中的容器连接到新网络：

  docker network connect prod-bridge-net app-service
  

• 将容器从指定网络中断开：

  docker network disconnect prod-bridge-net app-service
  

查（Read）

• 查看宿主机上所有的网络：

  docker network ls
  

• 查看网络的详细配置和连接状态：

  docker network inspect prod-bridge-net
  

  • 注：此命令可查询出当前网络中连接的所有容器及其分配的 IP。

---

4. Docker 存储管理（CRUD 视角）

Docker 存储分为 数据卷（Volumes） 和 绑定挂载（Bind Mounts）。生产环境建议优先使用命名卷，以利于数据迁移与生命周期管理。

增（Create）

• 创建命名数据卷：

  docker volume create prod-mysql-data
  

删（Delete）

• 删除指定数据卷：

  docker volume rm prod-mysql-data
  

  • 注：如果数据卷正在被容器使用，无法直接删除，需先移除对应容器。
• 批量清理所有未被挂载的数据卷（高危命令，务必确认数据已备份）：

  docker volume prune -f
  

改（Update / Copy）

• 数据卷本身配置无法直接修改，但可以通过容器内拷机制（docker cp）向挂载目录写入、更新或提取文件：

  # 拷贝宿主机配置文件到容器内部（即间接修改存储）
  docker cp /opt/configs/my.cnf app-service:/etc/mysql/my.cnf
  

查（Read）

• 查看当前系统所有的数据卷：

  docker volume ls
  

• 查看数据卷的实际宿主机存储路径（Mountpoint）：

  docker volume inspect prod-mysql-data
  

---

5. Docker 指定启动命令（COMMAND 机制详解）

在 Dockerfile 中，ENTRYPOINT 与 CMD 共同构成了容器启动时的执行指令。在运行容器（docker run）时，我们可以覆盖这些配置来满足特定的运行需求。

执行命令覆盖机制

在 docker run 命令的末尾，添加的参数会覆盖 Dockerfile 中声明的默认 CMD：

docker run -d --name dev-nginx nginx:1.25.3 nginx -g "daemon off;"

• nginx -g "daemon off;"：这里的指令替代了 Nginx 官方镜像默认的启动行为。

ENTRYPOINT 的覆盖方式

如果镜像定义了 ENTRYPOINT，直接在末尾加参数只会被作为输入给 ENTRYPOINT 的参数。如果需要更换主执行程序（如进入容器内部进行排错），必须使用 --entrypoint 参数：

docker run -it --name debug-service \
  --entrypoint /bin/sh \
  reg.enterprise.com/web/api:v1.0.0

• --entrypoint /bin/sh：强制抛弃原镜像指定的常驻主进程（如 Java 或 Python 进程），改由 shell 进程作为 1 号进程（PID 1），方便直接进行调试。

---

6. Docker 指定环境变量与工作目录

企业应用往往通过环境变量（Env）读取不同的配置（如测试、生产、开发），通过工作目录（WORKDIR）规范日志及应用输出的位置。

docker run -d \
  --name prod-backend \
  -w /app/release \
  -e SPRING_PROFILES_ACTIVE=prod \
  -e DB_HOST=172.24.0.5 \
  --env-file /opt/env/prod_env.list \
  reg.enterprise.com/web/api:v1.0.0

参数详解

• -w / --workdir：指定容器内的当前工作目录。如果容器内的该路径不存在，Docker 会自动创建该目录。此时后续的所有执行指令（COMMAND、RUN 等）以及输出的相对路径文件都会在此目录下进行。
• -e / --env：动态注入环境变量。格式为 KEY=VALUE。容器内的应用程序可通过标准的系统调用（如 Java 的 System.getenv() 或 Python的 os.environ）直接获取。
• --env-file：大批量环境变量管理利器。将所有环境变量写在宿主机的 .list 或 .env 文件中，每行一个 KEY=VALUE，容器启动时批量注入，避免命令行过长。

---

7. Docker 容器重启策略（自愈配置）

在容器崩溃、进程退出、宿主机断电关机、或者 Docker 守护进程（Daemon）重启时，配置合理的重启策略可以实现服务无人值守自愈。

                         [ 容器退出 / 系统重启 ]
                                    │
                  ┌─────────────────┴─────────────────┐
                  ▼                                   ▼
          [ 手动停止 (stop) ]                [ 非手动停止 (崩溃/重启) ]
                  │                                   │
                  ▼                                   ▼
         任何策略均不自动拉起                    ┌─────┴──────────────┐
                                                ▼                    ▼
                                        [ always 策略 ]      [ unless-stopped 策略 ]
                                                │                    │
                                                ▼                    ▼
                                            自动重启             自动重启

重启策略参数及适用场景：

docker run -d --name app-service --restart <restart-policy> nginx:1.25.3

1. no
   • 行为：容器退出时，Docker 守护进程绝不自动重启它。
   • 适用场景：一次性数据迁移任务、临时离线分析、定时离线脚本。
2. on-failure[:max-retries]
   • 行为：仅在容器非正常退出（即退出状态码 Exit Code 不为 0，例如内存溢出、核心报错）时，Docker 才会尝试重启它。
   • 高级限制：可指定最大重试次数，如 --restart=on-failure:5，当重试 5 次依然失败，则停止尝试，防止因代码逻辑致命缺陷导致死循环。
   • 适用场景：后台数据处理等非长服务应用，避免异常死循环消耗整机算力。
3. always
   • 行为：无论容器是因为何种原因退出（包括正常退出、主动关闭、或者代码崩溃），Docker 都会无条件重启。
   • 核心逻辑：如果该容器被手动 docker stop 了，当 Docker 守护进程或宿主机重启后，该容器仍然会被自动拉起。
   • 适用场景：关键公共基础设施组件（如网关、监控组件、数据库等）。
4. unless-stopped（生产环境推荐）
   • 行为：提供与 always 相同的自愈机制（崩溃自动重启，系统重启自动拉起）。
   • 核心差异：如果在 Docker 守护进程停止或系统重启之前，该容器已被运维人员手动停止（docker stop），那么系统重启后，该容器不会被自动运行。
   • 适用场景：标准的微服务业务应用。能有效防止因计划内维护暂时停用的服务在系统关机重启后“意外复活”造成生产故障。

---

8. Docker 日常故障排错方法论

生产环境中遇到容器启动失败或请求无响应时，建议遵循以下步骤进行排查：

第一步：检查状态

docker ps -a

• 排错关键：观察容器的 STATUS 栏。
  • 如果是 Up 5 seconds（频繁重启），说明启动命令或程序内部发生异常。
  • 如果是 Exited (137) 2 minutes ago：状态码 137 代表容器被强杀（通常是被宿主机 OOM Killer 机制因为内存超限杀死）。
  • 如果是 Exited (1) 2 minutes ago：状态码 1 代表容器内程序运行中发生异常，需排查配置或代码。

第二步：分析日志

docker logs --tail 200 -t prod-api-service

• 查看最后 200 行日志，附加时间戳（-t），定位导致崩溃的最后一行报错堆栈。

第三步：深入容器元数据（探查宿主机配置映射）

docker inspect prod-api-service

• 重点排查：
  • State.Error：检查容器启动失败的底层系统报错（如内核兼容、文件挂载冲突）。
  • Mounts：检查数据卷在宿主机的绝对路径是否被误删，检查权限是否不足。
  • NetworkSettings.Ports：检查端口映射是否冲突，或映射的网卡是否正确。

第四步：进入容器内部调试

如果容器仍然在运行，但是业务无响应或网络不通：

docker exec -it prod-api-service /bin/sh

• 在容器内执行 ping、curl 测试网络链路。
• 检查 /etc/resolv.conf 确认 DNS 配置是否正确。

---

9. 企业应用部署实战：生产级三层架构全流程落地

本节将实战演练单机上标准的“Nginx（反向代理）+ Spring Boot（后端服务）+ MySQL（数据存储）”三层企业架构部署。

     [ 客户端请求 ] ─── ( 8080 端口 )
                             │
                             ▼
                 [ prod-nginx 反向代理 ] ── ( 挂载配置, 证书 )
                             │
                             ▼ ( prod-net 网络 )
                 [ prod-api 后端服务 ]
                             │
                             ▼ ( prod-net 网络 )
                 [ prod-mysql 数据库 ] ── ( 绑定挂载持久化 )

步骤一：创建隔离的业务网络

docker network create --driver bridge --subnet 172.30.0.0/16 prod-net

步骤二：部署 MySQL 数据库并进行持久化配置

创建本地数据目录：

mkdir -p /data/prod/mysql

部署容器：

docker run -d \
  --name prod-mysql \
  --network prod-net \
  -v /data/prod/mysql:/var/lib/mysql:rw \
  -e MYSQL_ROOT_PASSWORD=Sql_Prod_Pass_2024 \
  -e MYSQL_DATABASE=app_prod \
  -m 2g --memory-swap 2g \
  --restart unless-stopped \
  mysql:8.0

• 参数解析：后端程序可以通过 prod-mysql:3306 直接解析访问数据库，数据持久化到宿主机 /data/prod/mysql。配置了 2g 内存限制防止资源被无限制消耗。

步骤三：部署后端 Spring Boot 服务

部署容器（应用依赖于 MySQL 提供数据）：

docker run -d \
  --name prod-api \
  --network prod-net \
  -w /app \
  -e SPRING_PROFILES_ACTIVE=prod \
  -e SPRING_DATASOURCE_URL=jdbc:mysql://prod-mysql:3306/app_prod?useSSL=false \
  -e SPRING_DATASOURCE_PASSWORD=Sql_Prod_Pass_2024 \
  -m 1g \
  --restart unless-stopped \
  reg.enterprise.com/web/api:v1.0.0

• 参数解析：
  • --network prod-net：与数据库置于同一内网。
  • -e SPRING_DATASOURCE_URL：通过容器名 prod-mysql 连接数据库，屏蔽了底层物理 IP 的变动。
  • -w /app：规范应用在 /app 下运行。

步骤四：部署前端 Nginx 代理与网关配置

在宿主机准备好 Nginx 配置文件：

mkdir -p /data/prod/nginx

编辑配置文件 /data/prod/nginx/nginx.conf：

server {
    listen 80;
    server_name localhost;

    location /api/ {
        proxy_pass http://prod-api:8080/; # 将前端请求反向代理到后端容器
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

部署 Nginx 容器：

docker run -d \
  --name prod-nginx \
  --network prod-net \
  -p 80:80 \
  -v /data/prod/nginx/nginx.conf:/etc/nginx/conf.d/default.conf:ro \
  --restart unless-stopped \
  nginx:1.25.3

• 参数解析：
  • -p 80:80：向外部网络暴露出主要的 HTTP 访问入口。
  • -v ...:ro：配置文件在容器内设为只读，确保容器安全。

步骤五：服务连通性验证

1. 在宿主机测试外网入口：

   curl http://127.0.0.1/api/health
   

2. 检查 Nginx 转发日志：

   docker logs --tail 20 -f prod-nginx
   

   确认返回状态码为 200，说明三层网络架构已实现互联互通。