容器、Docker 与课程项目

很多 Docker 教程从命令表开始，读者能照着输入，却不知道这些命令为什么存在。这门课换一种走法：我们先明确要交付的项目，再让每个 Docker 概念解决一个真实问题。

课程主线是一个“任务清单 API”。它能接收任务、列出任务，并把数据保存在 Redis 中。我们会从一条命令开始，逐步得到两个容器、一张可分发的应用镜像、一份 compose.yaml，以及一套能复现的启动和排错流程。

先理解容器解决什么问题

一个应用要运行，通常需要程序文件、语言运行时、系统库、配置和启动命令。只复制源代码，很容易出现“依赖版本不同”“缺少系统库”“启动方式不一致”等问题。

容器把应用和它的运行条件一起组织起来。镜像描述静态内容，容器是镜像的一次运行实例。只要运行平台支持对应的操作系统与 CPU 架构，同一镜像就能以相同方式启动。

容器和虚拟机都能隔离工作负载，但边界不同：

“共享内核”到底意味着什么

把容器理解成“带着独立视野和资源边界的一组进程”，比把它想成一台小电脑更准确。一个普通进程能看到设备上的进程列表、网络接口和文件目录；容器里的进程仍然由同一个 Linux 内核调度，但 Docker 会借助内核能力改变它能看到和能使用的范围。

• namespace（命名空间）负责隔离视野。 PID namespace 让容器拥有自己的进程编号；network namespace 给它独立的网卡、路由和端口空间；mount namespace 决定它看到哪一套挂载点。
• cgroup（控制组）负责限制资源。 它可以统计并约束 CPU、内存和进程数，防止一个工作负载无限制占用资源。
• 分层文件系统负责组织文件。 镜像层只读并可复用，容器在最上面获得自己的可写层。多个容器可以共享同一组镜像层，却各自记录运行时改动。

这三部分解决的是不同问题：namespace 不等于资源限制，cgroup 也不负责隐藏进程；文件系统隔离更不代表网络已经隔离。后面学习网络、存储和安全时，我们会分别把这些边界展开。

容器解决的是“交付一致性”，不是所有环境差异

镜像能固定应用的用户空间依赖，却不会消除外部条件。CPU 架构、内核能力、可用内存、挂载的数据、运行时注入的配置和外部服务仍然会影响结果。因此“在容器里能运行”只是交付链的一部分，可靠交付还需要：

1. 明确镜像支持的平台，例如 linux/amd64 或 linux/arm64。
2. 把需要持久化的数据放到独立存储，而不是容器可写层。
3. 把地址、端口和密钥作为运行配置注入，而不是写死进镜像。
4. 用健康检查验证服务真正就绪，而不是只看进程是否存在。
5. 用日志、退出码和资源指标解释失败，而不是反复删除重建碰运气。

这正是课程从单容器一路讲到 Compose、排错、安全和发布的原因。

认识贯穿全课的六个对象

后面的命令会反复操作这些对象。现在先建立一张简单地图。

镜像

镜像是只读模板，包含文件系统和默认启动配置。例如 redis:8-alpine 表示 Redis 仓库中标记为 8-alpine 的镜像。

容器

容器由镜像创建。删除容器不会删除镜像；没有挂载到数据卷的数据，会随容器删除而丢失。

Dockerfile

Dockerfile 是构建镜像的配方。FROM 选择基础镜像，COPY 放入文件，RUN 执行构建步骤，ENTRYPOINT 或 CMD 定义默认进程。

Registry

Registry 是镜像仓库服务。Docker Hub 是常见的公共 Registry，团队也可以使用私有仓库。pull 下载镜像，push 上传镜像。

网络

容器网络让容器彼此通信。接入同一自定义网络的容器，可以通过容器名或 Compose 服务名发现对方。

数据卷

数据卷由 Docker 管理，生命周期独立于容器。数据库数据、上传文件等需要跨容器重建保留的内容，应放进数据卷。

把六个对象放进一次请求里

用户访问任务 API 时，这六个对象不是彼此孤立的名词：

1. Docker 根据 Dockerfile 构建任务 API 镜像。
2. Docker 用该镜像创建 API 容器。
3. API 容器与 Redis 容器加入同一张 网络，因此能用服务名通信。
4. Redis 把数据写入 数据卷，即使 Redis 容器被替换，数据仍然存在。
5. 构建完成的镜像可以推送到 Registry，供另一台设备拉取。

注意这里有两条完全不同的生命周期：镜像从构建走向分发，容器从创建走向运行和删除。把二者分开，是后面不误删数据、不混淆状态的基础。

建立三个必须分清的边界

构建时与运行时

docker build 负责把源代码和依赖变成镜像；docker run 负责从镜像创建容器并启动进程。编译器通常只在构建时需要，端口、数据库地址和密钥则通常在运行时决定。把两类信息混在一起，会得到体积大、难复用或泄露配置的镜像。

容器内与容器外

容器里的 localhost 指向容器自己，不自动指向另一个容器，也不等于访问者所在的网络空间。容器端口只有被发布后，外部请求才能按映射进入；两个容器之间则通常通过共享网络和服务名通信。

可替换状态与持久状态

应用二进制、系统库和默认配置适合放进镜像，因为它们可以重新构建。用户数据、数据库文件和上传内容不能依赖某个容器一直存在，应放到数据卷或外部存储。一个健康的容器化应用应该允许“删掉旧容器，用同一镜像创建新容器”。

课程最终会交付什么

项目目录最终包含这些文件：

docker-task-api/
├── .dockerignore
├── Dockerfile
├── compose.yaml
├── go.mod
├── go.sum
└── main.go

最终运行关系如下：

浏览器或 curl
      │ 端口 8080
      ▼
任务 API 容器 ── 服务名 redis:6379 ──► Redis 容器
                                              │
                                              ▼
                                         命名数据卷

课程结束时，你应该能独立完成这些动作：

• 安装 Docker，并判断客户端、引擎和 Compose 是否可用。
• 拉取镜像，创建、查看、停止、重启和删除容器。
• 为应用编写 Dockerfile，构建小而可维护的镜像。
• 用数据卷保存状态，用网络连接服务。
• 用 Compose 启动、检查、更新和拆除多容器应用。
• 根据日志、健康状态和容器配置定位故障。
• 给镜像打标签、导出、加载，并理解多平台发布。
• 以非 root、只读文件系统和最小权限运行应用。

怎样读这门课

每次实操都按同一个顺序展开：先讲清楚命令要改变哪个对象，再执行命令，最后展示可核对的结果。不要跳过结果展示。Docker 的学习关键不是记参数，而是能根据状态判断下一步。

代码块中的 $ 只表示终端提示符，复制时不要输入。Windows 用户建议在 PowerShell 或 WSL 2 终端中执行；macOS 与 Linux 用户使用常见终端即可。

每章建议按下面四轮学习：

1. 先预测。 读完知识点后，先写下命令会创建或修改哪些对象。
2. 再执行。 一次只改变一个关键条件，保留完整输出。
3. 做核对。 用 ps、inspect、日志或实际请求验证状态，不以“命令没报错”代替验收。
4. 再解释。 尝试说明结果为什么出现，以及删掉某个参数会发生什么。

每章末尾都应该留下三类答案：我创建了什么、状态在哪里观察、失败时第一条证据从哪里找。学到后半程，你会发现 Docker 的多数问题都能沿着“配置 → 对象状态 → 进程输出 → 外部连通性”逐层缩小，而不需要猜。

下一节先把 Docker 安装好，并用一组体检命令分清“命令存在”和“引擎能工作”这两件事。