告别死记硬背！用思维导图+场景案例图解Docker核心命令

每次看到那些动辄几十条、按字母顺序排列的Docker命令列表，你是不是也感到一阵头疼？仿佛回到了学生时代，面对着一本厚厚的词典，每个单词都认识，但组合在一起却不知道如何在实际对话中运用。对于视觉学习者和初学者来说，这种“命令大全”式的学习方式效率极低，它割裂了命令之间的内在联系，让你记住了docker run，却不知道它和docker exec、docker logs在同一个工作流中如何协同。

真正的掌握，不是记住一个个孤立的命令，而是理解它们背后的生命周期逻辑和状态转换关系。想象一下，你不再需要翻查笔记，就能清晰地知道：当容器卡住时，是该用stop还是kill？在CI/CD流水线中，如何组合build、push、run命令实现自动化？今天，我们就换一种学法。我将带你用思维导图构建Docker命令的宏观认知框架，再通过本地开发、CI/CD部署、日常运维三大真实场景，将抽象的命令转化为你指尖下的具体操作。你会发现，当命令被置于它该在的“位置”和“流程”中时，记忆和理解都变得自然而然。

1. 重构认知：用思维导图理解Docker命令的生命周期

学习Docker命令，第一步不是打开终端，而是打开你的思维。我们需要一张地图，来看清整个“Docker世界”的疆域和道路。这张地图的核心，是理解两个核心概念的生命周期：镜像（Image） 和 容器（Container）。它们的关系，就像“蓝图”与“房子”。

1.1 镜像生命周期：从获取到消亡的完整视图

镜像是静态的、分层的模板，包含了运行一个应用所需的一切：代码、运行时、库、环境变量和配置文件。它的生命周期是一条清晰的单向流水线。

思维导图核心分支：镜像流

镜像生命周期
├── 获取 (Acquire)
│   ├── 从仓库拉取：`docker pull <image>[:tag]`
│   └── 从零构建：`docker build -t <name> .`
├── 查看与管理 (Inspect & Manage)
│   ├── 列出本地镜像：`docker images` 或 `docker image ls`
│   ├── 查看镜像详情：`docker image inspect <image>`
│   └── 查看构建历史：`docker history <image>`
├── 标记与发布 (Tag & Publish)
│   ├── 添加新标签：`docker tag <source> <target>`
│   └── 推送到仓库：`docker push <image>`
└── 清理 (Cleanup)
    ├── 删除指定镜像：`docker rmi <image>` 或 `docker image rm <image>`
    └── 清理悬空镜像：`docker image prune`

这个视图的关键在于，它揭示了命令之间的依赖和顺序。例如，你无法push一个尚未通过build或pull获得的镜像；tag命令通常是为push做准备。理解了这个流程，命令就不再是孤立的单词。

提示：docker image是较新的命令语法（管理命令），与传统的docker <子命令>（如docker rmi）功能相同。建议新手从管理命令学起，语义更清晰。

1.2 容器状态转换：理解容器的“生老病死”

容器是镜像的运行实例。它的生命周期比镜像更动态，存在多种状态（Created, Running, Paused, Exited, Dead），并且可以在这些状态间转换。这是最容易让人混淆的地方。

容器状态转换图（核心）

 [创建] docker create
     |
     v
 Created (已创建)
     | (启动)
     v
 [运行] docker start / docker run
     |
     v
 Running (运行中)
     |        | (暂停)        | (停止)
     |        v               v
     |    Paused (已暂停)   Exited (已退出)
     |        | (恢复)        | (重启)
     |        v               v
     +----> Running <------ Restarting
     |        | (强制停止)     |
     |        v               |
     |     Dead (死亡)        |
     |        |               |
     |        +---------------+
     | (删除)
     v
 [移除] docker rm

这张图是理解所有容器操作命令的基石：

• docker run = docker create + docker start。它一次性完成创建并启动。
• docker stop 发送SIGTERM信号，允许容器优雅关闭；docker kill 发送SIGKILL信号，强制立即终止。在CI/CD中需要快速清理时常用kill，在关闭数据库等有状态服务时务必用stop。
• 容器处于Exited状态时，其文件系统变更（在可写层）仍然保留，直到被删除(rm)。

理解了状态，你就知道什么时候该用什么命令。容器无响应？先docker ps查看状态，如果是Running但卡死，用docker kill；如果是Exited，可能需要查看日志(docker logs)找原因。

2. 场景实战一：本地开发环境搭建（从零到交互）

现在，让我们把思维导图上的节点，变成终端里实实在在的命令。假设你是一个Python开发者，需要在本地快速搭建一个隔离的Redis服务进行功能测试。

2.1 快速启动一个可交互的测试容器

我们的目标是：启动一个Redis容器，并连接到它的CLI进行操作。

# 1. 拉取最新版的Redis镜像（如果本地没有）
docker pull redis:alpine

# 2. 以后台模式运行一个Redis容器，并命名为‘my-redis-test’
docker run -d --name my-redis-test redis:alpine

# 3. 查看容器是否正常运行
docker ps
# 输出应包含 my-redis-test，状态为 Up

# 4. 执行命令进入容器的Redis CLI
docker exec -it my-redis-test redis-cli

此时，你会直接进入Redis的命令行界面，可以执行SET mykey "Hello"、GET mykey等操作。完成后，输入exit退出CLI，但容器仍在后台运行。

关键参数解析：

• -d (detach)：后台运行。这是开发服务的标准模式。
• --name：给容器起一个有意义的名字，远比使用随机的容器ID方便管理。
• -it：这是-i (保持标准输入打开) 和 -t (分配一个伪终端) 的组合，它是实现与容器内命令行交互的黄金搭档，常用于exec或run /bin/bash。

2.2 数据持久化与端口映射：让开发环境可用

上面的容器虽然能运行，但数据在容器停止后会丢失，且外部无法访问。我们来改进它。

# 1. 停止并删除之前的测试容器
docker stop my-redis-test
docker rm my-redis-test

# 2. 创建本地目录用于持久化Redis数据
mkdir -p ~/redis-data

# 3. 启动一个具有数据卷和端口映射的Redis容器
docker run -d \
  --name my-redis-dev \
  -p 6379:6379 \
  -v ~/redis-data:/data \
  redis:alpine \
  redis-server --appendonly yes

命令组合解读：

• -p 6379:6379：将主机的6379端口映射到容器的6379端口。现在你可以在主机上通过redis-cli -h 127.0.0.1或图形化工具直接连接。
• -v ~/redis-data:/data：将主机上的~/redis-data目录挂载到容器内的/data目录。Redis的持久化文件将保存在主机上，即使容器删除，数据也不会丢失。
• redis-server --appendonly yes：这是传递给容器内启动命令的参数，开启了Redis的AOF持久化。

现在，你的本地开发环境就具备了生产环境的雏形：服务可访问、数据可持久化。你可以随时重启、重建容器，而不用担心数据丢失。

3. 场景实战二：CI/CD流水线中的命令组合艺术

在自动化部署流水线中，Docker命令很少单独出现，它们通过Shell管道(|)、命令替换($())、和逻辑运算符(&&)组合在一起，形成高效、健壮的脚本。这里的关键是错误处理和资源清理。

3.1 构建并推送镜像的健壮脚本

一个典型的CI阶段（例如在GitLab CI或GitHub Actions中）可能包含如下步骤：

#!/bin/bash
set -e # 遇到错误立即退出，防止继续执行错误状态

IMAGE_NAME="my-registry.com/myapp"
TAG="${CI_COMMIT_SHA:0:8}" # 使用提交SHA前8位作为标签

echo "1. 构建Docker镜像..."
docker build -t $IMAGE_NAME:$TAG -t $IMAGE_NAME:latest .

echo "2. 运行集成测试..."
# 启动一个临时容器运行测试
docker run --rm $IMAGE_NAME:$TAG npm test

if [ $? -eq 0 ]; then
  echo "测试通过，开始推送镜像..."
  docker push $IMAGE_NAME:$TAG
  docker push $IMAGE_NAME:latest
else
  echo "测试失败，构建中止。"
  exit 1
fi

echo "3. 清理本地构建缓存..."
docker builder prune -f

组合技巧解析：

• docker run --rm：--rm参数表示容器停止后自动删除。在CI中用于运行测试的容器都是临时的，用完即弃，避免积累大量停止的容器占用磁盘。
• docker builder prune -f：清理构建缓存，释放磁盘空间。这在资源有限的CI Runner上非常重要。
• 使用变量和标签(:latest, :$TAG)使得镜像版本管理清晰。

3.2 基于容器状态的自动化部署与回滚

在CD部署阶段，我们可能需要更新正在运行的服务。一个简单的滚动更新策略如下：

#!/bin/bash
NEW_CONTAINER="my-app:new-version"
OLD_CONTAINER_ID=$(docker ps -q -f name=my-running-app)

echo "启动新版本容器..."
docker run -d --name my-app-new $NEW_CONTAINER

# 等待新容器健康检查通过（假设应用有健康检查端点）
sleep 10
if docker inspect --format='{{.State.Health.Status}}' my-app-new | grep -q "healthy"; then
  echo "新容器健康，停止旧容器..."
  if [ ! -z "$OLD_CONTAINER_ID" ]; then
    docker stop $OLD_CONTAINER_ID
    docker rm $OLD_CONTAINER_ID
  fi
  # 将新容器重命名为正式名称
  docker rename my-app-new my-running-app
  echo "部署成功！"
else
  echo "新容器不健康，执行回滚..."
  docker stop my-app-new && docker rm my-app-new
  if [ ! -z "$OLD_CONTAINER_ID" ]; then
    docker restart $OLD_CONTAINER_ID
  fi
  echo "已回滚至旧版本。"
  exit 1
fi

这个脚本展示了如何利用docker ps -q -f name=查询特定容器，以及使用docker inspect获取容器详细状态（如健康状态），从而做出决策。-f (filter) 参数是日常运维和脚本中的利器。

4. 高效运维：查询、调试与批量操作的进阶技巧

当你管理着数十个容器时，高效地查询、筛选和批量操作就成为必备技能。死记硬背命令格式在这里行不通，你需要的是组合拳。

4.1 精准查询与过滤：告别docker ps | grep的蛮力搜索

docker ps的-f过滤器功能强大，可以基于多种条件筛选。

# 查找所有处于“退出”状态的容器
docker ps -a -f status=exited

# 查找名称包含“web”且正在运行的容器
docker ps -f name=web -f status=running

# 查找在某个特定镜像基础上运行的所有容器
docker ps -a -f ancestor=nginx:alpine

# 结合格式化输出，只显示容器ID和名称
docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Status}}"

对于镜像查询，docker images同样支持过滤：

# 查找标签为“<none>”的悬空镜像
docker images -f dangling=true

# 查找“redis”仓库的所有镜像
docker images redis

4.2 日志追踪与故障排查：不只是docker logs

查看日志是排查问题的第一步，但如何高效地查看？

# 1. 查看最近100行日志
docker logs --tail 100 my-container

# 2. 实时追踪日志输出（类似 tail -f）
docker logs -f my-container

# 3. 查看特定时间点之后的日志
docker logs --since 2024-05-01T10:00:00 my-container

# 4. 结合时间戳查看，便于分析事件顺序
docker logs -t --since 10m my-container | grep -i error

当容器启动失败时，docker logs可能没有输出。这时需要检查容器创建时的配置：

# 查看容器的详细配置和状态，包括启动命令、环境变量、网络设置等
docker inspect my-container | less
# 重点关注 "State"（状态）、"Config.Cmd"（命令）、"NetworkSettings"（网络）

4.3 高级批量操作与系统清理

随着使用时间增长，系统中会积累很多停止的容器、未使用的镜像和网络。手动清理效率低下。

# 1. 一键停止并删除所有容器（危险操作，生产环境慎用！）
docker stop $(docker ps -aq) && docker rm $(docker ps -aq)

# 2. 更安全的清理：删除所有已退出的容器
docker container prune

# 3. 删除所有未被任何容器使用的悬空镜像
docker image prune

# 4. 删除所有未被使用的资源（镜像、容器、网络、构建缓存）
docker system prune -a

注意：docker system prune -a 会删除所有未被使用的镜像，包括那些虽然没有标签但可能以后会用到的中间层镜像。在执行前，请务必确认。

为了更精细地控制，可以结合xargs命令：

# 删除所有创建时间早于“my-app:latest”的容器
docker ps -a --filter "before=my-app:latest" --format "{{.ID}}" | xargs docker rm -f

这些组合命令的威力在于，它们将Docker命令与Linux Shell的强大文本处理能力结合，让你能应对复杂的运维场景。记住，不要试图记住所有命令的组合，而是理解每个命令的输出格式，知道如何用管道(|)、grep、awk、xargs去处理和传递这些输出。这才是从“命令使用者”到“效率工程师”的蜕变。

当你把docker ps的输出看作一个结构化的文本列表，把docker inspect的输出看作一个JSON对象时，整个世界就打开了。我自己的习惯是，在编写任何复杂的清理或部署脚本前，先在终端里用--format参数把需要的数据字段提取出来，确认无误后再套入xargs或循环中。这种“先查询，后操作”的模式，能避免很多误删或误操作的悲剧。