安装 Docker 并完成体检

Docker 的命令行只是客户端。真正负责下载镜像、创建网络和启动容器的是 Docker Engine。安装完成后，既要确认 docker 命令存在，也要确认它能连接到引擎。

选择适合你的安装方式

macOS

从 Docker Desktop for Mac 官方安装页 选择 Apple 芯片或 Intel 芯片版本。安装后启动 Docker Desktop，等状态显示引擎已经运行。

如果不确定芯片类型，可以先执行：

$ uname -m
arm64

arm64 通常表示 Apple 芯片，x86_64 表示 Intel 芯片。

Windows

按照 Docker Desktop for Windows 官方安装页 安装 Docker Desktop，并启用 WSL 2 后端。课程使用 Linux 容器，因此 Docker Desktop 菜单应处于 Linux containers 模式。

在 PowerShell 中确认 WSL 状态：

> wsl --status
Default Version: 2

如果默认版本不是 2，执行 wsl --set-default-version 2，然后重新打开 Docker Desktop。

Ubuntu

服务器通常直接安装 Docker Engine。下面使用 Docker 官方 apt 仓库；完整前置条件以 Ubuntu 安装文档 为准。

先解释命令的目的：前四行准备受信任的软件源，docker.sources 指向 Docker 官方仓库，最后一行同时安装引擎、命令行、containerd、Buildx 和 Compose 插件。

$ sudo apt update
$ sudo apt install -y ca-certificates curl
$ sudo install -m 0755 -d /etc/apt/keyrings
$ sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
$ sudo chmod a+r /etc/apt/keyrings/docker.asc
$ sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
$ sudo apt update
$ sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

安装包后启用服务：

$ sudo systemctl enable --now docker

知识点：客户端与服务端

docker version 会分别显示 Client 和 Server。只出现 Client，常见原因是 Docker Desktop 尚未启动、Docker 服务没有运行，或当前 context 指向了不可达的引擎。

docker info 更进一步，能显示容器数量、镜像数量、存储驱动和当前上下文。docker compose version 用来确认 Compose 插件可用。

一条命令经过了哪些组件

当你输入 docker run ... 时，终端里的 docker 客户端不会自己创建 Linux 进程。它会把请求发送给 Docker API，通常由 dockerd 接收。守护进程负责镜像、容器、网络和数据卷等高层对象，并通过容器运行时准备更底层的进程隔离和生命周期。

可以把调用链先简化为：

docker CLI / Docker Compose
          │ Docker API
          ▼
       dockerd
          │ 管理镜像、网络、卷并请求创建容器
          ▼
  containerd → OCI runtime → 容器主进程

这张图解释了两个常见现象：

• 客户端版本和服务端版本可以不同，因为二者是两个组件，通过 API 协作。
• docker --version 成功不代表能运行容器，因为它甚至不需要访问服务端。

Docker Desktop 为什么还需要虚拟化层

课程运行的是 Linux 容器，而容器需要 Linux 内核提供 namespace、cgroup 等能力。Ubuntu 已经有 Linux 内核，可以直接运行 Docker Engine；macOS 不是 Linux，Windows 使用 Linux 容器时也需要 Linux 内核，因此 Docker Desktop 会管理一套轻量的 Linux 虚拟化环境。

这不改变日常使用方式：命令仍然通过 Docker API 操作容器。但它会影响文件共享性能、可分配资源和网络路径，所以排查问题时要知道 Docker Desktop 不只是一张控制面板。

Context 是“连接目标”的名字

一个 Docker 客户端可以连接多个引擎。context 保存了 API 端点和相关连接配置，docker context show 只显示当前名字，docker context ls 则显示所有目标：

$ docker context ls
NAME              DESCRIPTION                               DOCKER ENDPOINT
default           Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
desktop-linux *   Docker Desktop                            unix:///...

星号代表当前 context。如果你明明启动了一个引擎，却连到另一个 context，就会看到“服务端不可达”或完全不同的一组容器。切换前要先确认目标，而不是盲目执行：

$ docker context use desktop-linux
desktop-linux

实操：完成三项体检

先查看版本：

$ docker version --format 'Client {{.Client.Version}} / Server {{.Server.Version}}'
Client 28.5.1 / Server 28.5.1

再查看当前上下文：

$ docker context show
desktop-linux

最后检查 Compose：

$ docker compose version
Docker Compose version v2.40.0-desktop.1

版本号会随安装时间变化。判断成功的标准是：Client 和 Server 都有结果，context show 返回一个上下文名称，Compose 命令能输出版本。

继续读取一份不做修改的运行摘要：

$ docker info --format 'OS={{.OperatingSystem}} Driver={{.Driver}} Images={{.Images}} Containers={{.Containers}}'
OS=Docker Desktop Driver=overlayfs Images=0 Containers=0

OperatingSystem 告诉你引擎运行在哪类系统上，Driver 是镜像层和容器可写层所使用的存储驱动，后两个数字是当前引擎管理的对象数量。不同平台的文字和驱动名称可能不同，不要把示例值当成固定答案；关键是命令能从 Server 取得结构化结果。

最后进行一次真正覆盖“拉取—创建—启动—退出”的冒烟检查：

$ docker run --rm hello-world
Hello from Docker!

hello-world 很小，但它比版本命令多验证了 Registry 访问、镜像层下载和容器进程启动。第一次可能需要等待下载；之后再次运行通常更快，因为镜像已经存在。

结果展示：识别常见失败

如果看到下面这类信息：

Cannot connect to the Docker daemon ... Is the docker daemon running?

说明命令行已经安装，但没有连上引擎。按这个顺序检查：

1. macOS 或 Windows：确认 Docker Desktop 已启动并完成初始化。
2. Ubuntu：执行 sudo systemctl status docker。
3. 执行 docker context ls，确认带 * 的上下文是你要使用的那个。
4. 重新执行 docker version，不要只用 docker --version。后者只检查客户端文件。

如果服务端能连接，但 hello-world 失败，可以按错误所属阶段判断：

为什么先看原始错误，再考虑重装

安装问题常被误判为“Docker 坏了”。实际上客户端不可达、网络拉取失败、平台不兼容和容器进程失败属于四个层次。重装只可能解决其中一部分，还可能抹掉有价值的状态。先记录完整命令、错误原文、当前 context 和 docker info，通常能更快定位边界。

安装完成后的最低安全认知

Ubuntu 上常见的 /var/run/docker.sock 是客户端访问 Docker API 的入口。把用户加入 docker 组后，用户无需 sudo 就能操作这个入口，但也能创建高权限容器、挂载广泛的文件路径。因此它不是普通“为了省事的命令权限”。

如果场景要求减少守护进程的 root 权限，可以进一步研究 Docker Engine 的 rootless 模式；它会让守护进程和容器都运行在非 root 用户的 user namespace 中。不过 rootless 也有网络、资源控制和端口等方面的约束，不应在入门阶段只为“看起来更安全”就跳过需求评估。

本章的最低目标不是做完全部加固，而是形成两个习惯：只从官方来源安装；把 Docker API 视为高权限管理入口。

小测