Docker生态系统五大核心组件深度解析

1. 项目概述：这不是在学一个工具，而是在理解现代软件交付的“交通系统”

你打开终端输入 docker run hello-world ，几秒后屏幕上跳出一行绿色文字——这背后没有魔法，只有一整套精密协作的组件在 silently 运行。很多人把 Docker 简单理解成“装应用的盒子”，但真正卡住新手的，从来不是某条命令记不住，而是当 docker desktop failed to start because virtualization support not detected 报错时，根本不知道该去 BIOS 里开哪个开关；是当 pull access denied for nginx, repository does not exist 出现时，分不清自己输错了镜像名，还是压根没登录私有仓库；是写完 docker-compose.yml 却发现服务间 ping 不通，最后才发现 network 配置漏写了 driver: bridge 。这些不是操作失误，而是对 Docker 生态系统（экосистема Docker）缺乏结构化认知的必然结果。我带过三十多个从零起步的开发团队做容器化迁移，90% 的初期阻塞点都落在“不知道每个组件管什么、不晓得它和谁打交道、更不清楚出问题该查哪一层”。这篇内容不讲 docker ps -a 怎么用，也不堆砌 docker build -t app:latest . 的参数表。我要带你像修车师傅看发动机一样，把 Docker 生态拆开：看清镜像（image）是怎么被构建、存储、传输的；搞懂容器（container）启动时，runtime、engine、daemon 之间如何握手；弄明白 registry 是怎么当“快递中转站”，而 compose 又如何当“多车调度员”。你会看到 docker desktop 在 Windows 上为什么必须依赖 WSL2， docker engine 和 containerd 到底谁才是真正的“司机”，以及为什么国内开发者总在折腾 镜像源 和 镜像仓库 ——它们根本不是可有可无的“加速插件”，而是生态运转的毛细血管。无论你是刚在 Ubuntu 上敲下 sudo apt install docker.io 的新手，还是已经用 docker compose up -d 跑过三个微服务却总在日志里抓瞎的中级开发者，只要你希望下次报错时能精准定位到 /var/run/docker.sock 权限问题，而不是盲目重启服务，这篇文章就是为你写的。

2. 生态系统全景图：五个核心组件如何构成一个闭环工作流

Docker 生态不是一堆松散工具的集合，而是一个有明确分工、严格接口、环环相扣的生产流水线。把它比作一座现代化物流园区，你能立刻理解每个组件的不可替代性：镜像（Image）是标准化的“货箱”，容器（Container）是正在运输的“货车”，引擎（Engine）是园区调度中心，仓库（Registry）是中央仓储中心，编排（Compose）则是跨仓库的“多车联运调度系统”。这五个组件缺一不可，且顺序不能颠倒——你不可能让一辆没装货箱（镜像）的货车（容器）上路，也不可能让调度中心（Engine）在没建好仓库（Registry）的情况下处理跨境订单。下面我将逐层拆解，不仅告诉你“是什么”，更要说明“为什么必须这样设计”。

2.1 镜像（Image）：不可变的软件交付单元，一切的起点与终点

镜像不是虚拟机快照，也不是压缩包。它是 分层文件系统（Layered Filesystem）+ 元数据（Metadata） 的组合体，这个设计直接决定了 Docker 的核心优势：复用性、一致性与轻量化。以官方 nginx:alpine 镜像为例，它实际由 4 层叠加而成：

• 第 0 层： scratch （空层，仅占 0 字节）
• 第 1 层： alpine:latest 基础镜像（约 5.5MB），包含最小化 Linux 内核支持和 BusyBox 工具集
• 第 2 层： nginx 运行时依赖（约 3MB），如 OpenSSL、PCRE 库
• 第 3 层： nginx 二进制文件与默认配置（约 22MB）

关键在于，这四层是 只读（Read-Only） 的。当你执行 docker run nginx:alpine ，Docker 引擎会在最顶层动态添加一个 可写层（Writable Layer） ，所有运行时产生的日志、临时文件、进程状态都写入这一层。一旦容器停止，这个可写层就被丢弃，下一次启动又是一个全新的、干净的可写层。这就是为什么 docker run 启动的容器永远是“出厂设置”——因为底层镜像从未被修改过。

提示： docker history nginx:alpine 命令会清晰列出每一层的大小、创建命令（如 /bin/sh -c #(nop) CMD ["nginx" "-g" "daemon off;"] ）和创建时间。这是诊断镜像臃肿的黄金命令。我曾帮一个团队将 1.2GB 的 Python Web 镜像优化到 287MB，核心动作就是用 history 发现他们误把整个 venv/ 目录 COPY 进了镜像，而正确做法是只 COPY requirements.txt 并在构建时 pip install 。

镜像的构建过程（Build）本质是“指令驱动的层叠加”。 Dockerfile 中每一条 RUN 、 COPY 、 ADD 指令都会生成一个新层。这里有个极易被忽视的性能陷阱： RUN apt update && apt install -y curl 和 RUN apt install -y curl 是两回事。前者会生成一个包含完整 apt cache 的层，后者则因缓存缺失而失败。最佳实践是将更新与安装合并为一条指令，并在末尾清理缓存： RUN apt update && apt install -y curl && rm -rf /var/lib/apt/lists/* 。这条命令看似多打了 20 个字符，却能让镜像体积减少 40MB，并避免因缓存过期导致的构建失败。

2.2 容器（Container）：镜像的运行时实例，隔离与资源的平衡术

容器不是进程，也不是虚拟机。它是 镜像 + 可写层 + 隔离命名空间（Namespaces） + 资源限制（Cgroups） + 网络/存储驱动 的综合体。当你执行 docker run -it --rm ubuntu:22.04 bash ，Docker Engine 实际做了七件事：

1. 从本地镜像仓库加载 ubuntu:22.04 的只读层；
2. 创建一个新的可写层作为容器的 rootfs；
3. 为该容器分配独立的 PID、NET、MNT、UTS、IPC、USER 命名空间（共 6 个）；
4. 应用 CPU、内存、IO 的 cgroups 限制（如 --memory=512m ）；
5. 初始化网络栈：默认创建 bridge 网络，分配 172.17.0.x IP，并通过 iptables 设置 NAT 规则；
6. 挂载卷（Volume）或绑定挂载（Bind Mount），如 -v /host/data:/app/data ；
7. 启动 /bin/bash 进程作为 PID 1，并将其置于上述所有隔离环境中。

其中， PID 1 的特殊性 是理解容器生命周期的关键。在传统 Linux 中，PID 1 进程（通常是 systemd 或 init ）负责回收僵尸进程（Zombie Process）。但在容器里，如果 bash 进程退出，整个容器就立即终止，因为再无其他进程来接管信号。这也是为什么 docker run -d nginx 能后台运行，而 docker run -d bash 会立刻退出—— bash 启动后无事可做，自行退出，容器随之死亡。解决方案是让 PID 1 成为真正的“守护者”，例如使用 tini （Docker 官方推荐的 init 进程）或在 Dockerfile 中用 CMD ["sh", "-c", "nginx -g 'daemon off;'"] 确保 Nginx 以前台模式运行。

注意： --rm 参数绝非可有可无。它告诉 Docker 在容器退出后自动删除其可写层。若不加此参数，每次 docker run ubuntu bash -c "echo hello" 都会留下一个已退出的容器（ docker ps -a 可见），久而久之磁盘会被大量“僵尸容器”的可写层占满。我见过最极端的案例是某测试服务器因未清理， /var/lib/docker/overlay2/ 目录膨胀至 87GB，而实际业务镜像总和才 12GB。

2.3 引擎（Engine）：生态系统的“心脏”，daemon 与 client 的双脑架构

Docker Engine 是整个生态的中枢神经系统，但它并非一个单体进程，而是典型的 Client-Server 架构 ，由两部分组成：

• Docker Client（客户端） ：你每天敲的 docker run 、 docker build 命令，本质是向 Docker Daemon 发送 HTTP API 请求的 CLI 工具；
• Docker Daemon（守护进程） ：后台常驻服务（Linux 下为 dockerd 进程），监听 /var/run/docker.sock （Unix Socket）或 TCP 端口，接收请求并调用底层组件执行。

这个分离设计带来了关键能力： 远程管理 。你可以让一台物理机（Daemon）运行在数据中心，而你的笔记本（Client）通过 DOCKER_HOST=tcp://192.168.1.100:2375 远程控制它。 docker desktop 在 Windows/macOS 上的实现，正是利用了这一机制：它在后台启动一个轻量级 Linux VM（Windows 用 WSL2，macOS 用 HyperKit），VM 内运行真正的 dockerd ，而桌面端的 GUI 和 CLI 都作为 Client 连接到这个 VM 的 Daemon。

docker desktop 启动失败的常见原因，90% 都源于 Client-Server 连接中断。 virtualization support not detected 错误，本质是 WSL2 无法启动，因为 Windows 的“基于虚拟化的安全（VBS）”功能与 Hyper-V 冲突； starting the docker engine... 卡住，则大概率是 /var/run/docker.sock 文件权限错误（应为 srw-rw---- 1 root docker ）或磁盘空间不足（ /var/lib/docker/ 目录满了）。此时 sudo systemctl restart docker 往往无效，因为 Desktop 的 Daemon 是独立进程，需在 GUI 中点击“Restart”或执行 wsl --shutdown 后重开。

2.4 仓库（Registry）：镜像的“中央银行”，公有与私有的信任边界

Registry 是 Docker 生态的“信任锚点”。它不存储容器，只存储镜像及其元数据。当你执行 docker pull nginx ，CLI 实际做了三步：

1. 向默认 Registry（Docker Hub）发送 GET /v2/nginx/manifests/latest 请求，获取镜像清单（Manifest）；
2. 清单中包含所有层的 SHA256 摘要（如 sha256:abc123... ），Client 根据摘要向 /v2/nginx/blobs/sha256:abc123... 并行下载各层；
3. 下载完成后，Client 将所有层按顺序组装成本地镜像，并写入 /var/lib/docker/image/overlay2/ 。

这里的关键是 内容寻址（Content-Addressable） ：镜像的唯一标识不是 nginx:latest 这个标签（Tag），而是其 Manifest 的 SHA256 值（如 sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2 ）。 latest 标签只是指向这个哈希值的一个指针，随时可能被 docker push 覆盖。这就是为什么生产环境严禁使用 :latest 标签——它破坏了部署的可重现性。正确的做法是使用 Git Commit ID 或语义化版本号作为标签： docker build -t myapp:v1.2.3 . 。

国内开发者频繁折腾“镜像源”，是因为 Docker Hub 的默认地址 https://registry-1.docker.io 在中国大陆访问极不稳定。所谓“镜像源”，本质是 反向代理（Reverse Proxy） ：阿里云、腾讯云等厂商部署自己的 Registry 服务器，上游同步 Docker Hub 的公开镜像，下游为国内用户提供高速下载。配置方式有两种：

• 全局配置（推荐）：编辑 /etc/docker/daemon.json ，添加 "registry-mirrors": ["https://<your-mirror>.mirror.aliyuncs.com"] ，然后 sudo systemctl restart docker ；
• 临时配置： docker pull nginx --registry-mirror https://<your-mirror>.mirror.aliyuncs.com 。

实操心得：不要迷信“一键脚本”配置镜像源。我见过太多人执行 curl -sSL https://get.daocloud.io/docker | sh 后，发现脚本偷偷修改了 /etc/docker/daemon.json 并注入了未知的 registry-mirrors ，导致后续无法拉取私有仓库镜像。最稳妥的方式永远是手动编辑 JSON 文件，用 docker info | grep "Registry Mirrors" 验证是否生效。

2.5 编排（Compose）：多容器应用的“乐高说明书”，声明式运维的基石

docker-compose.yml 不是启动脚本，而是一份 声明式（Declarative）配置文件 。它描述“系统最终应该是什么状态”，而非“如何一步步达到那个状态”。以一个典型的 PHP+MySQL 应用为例：

version: '3.8'
services:
  web:
    image: php:8.2-apache
    ports: ["8080:80"]
    volumes: ["./src:/var/www/html"]
    depends_on: [db]
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: example
    volumes: ["mysql_data:/var/lib/mysql"]
volumes:
  mysql_data:

这段代码定义了两个服务（web 和 db），但 depends_on 并不保证 db 容器内的 MySQL 服务已完全就绪（它只等容器启动成功）。因此， web 服务启动时若立即连接 db:3306 ，大概率失败。解决方案是引入健康检查（Healthcheck）：

db:
  image: mysql:8.0
  healthcheck:
    test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "--password=example"]
    interval: 30s
    timeout: 10s
    retries: 5
  # ... 其他配置

此时 depends_on 可升级为 depends_on: { db: { condition: service_healthy } } ，Compos e 会等待 mysqladmin ping 返回成功才启动 web 。

Compose 的强大在于它抽象了网络与存储的复杂性。 docker-compose up 会自动创建一个名为 <project_name>_default 的 bridge 网络，并为每个服务分配 DNS 名称（ web 服务内可直接 ping db ）。它还会自动创建 mysql_data 卷，并确保 db 容器的 /var/lib/mysql 目录持久化到该卷。这一切无需你手动执行 docker network create 或 docker volume create 。但这也带来一个隐藏风险： docker-compose down 默认会删除所有网络和卷，除非你显式加上 --volumes 参数。我曾目睹一个团队在测试环境执行 down 后，发现 MySQL 数据库全丢了——因为他们以为 volumes 配置会自动保护数据，却不知 Compose 的“删除”逻辑是默认不保留的。

3. 核心组件协同工作流：从 docker run 到容器运行的完整链路

现在，让我们把五个组件串起来，以一条最简单的命令 docker run -p 8080:80 nginx 为线索，还原它背后跨越三层（Client、Daemon、Runtime）的完整调用链。这不是理论推演，而是我在调试 docker desktop 启动失败时，用 strace 和 tcpdump 实际抓包验证过的流程。理解这个链路，你就能在任何环节出问题时，精准定位到故障域。

3.1 Client 层：命令解析与 API 请求封装

当你在终端输入 docker run -p 8080:80 nginx ，Docker CLI（Client）首先进行语法解析：

• -p 8080:80 被解析为端口映射规则：宿主机 8080 端口 → 容器 80 端口；
• nginx 被解析为镜像名称，CLI 会先检查本地是否有该镜像（ docker images nginx ）；
• 若本地不存在，CLI 会向默认 Registry（Docker Hub）发起 GET /v2/library/nginx/manifests/latest 请求，获取镜像清单。

这里有个关键细节： nginx 是 library/nginx 的简写。Docker CLI 会自动补全 library/ 前缀，但如果你拉取的是个人仓库镜像，如 myuser/myapp ，就必须写全称，否则 CLI 会错误地去 library/myuser 下寻找。这个补全逻辑是硬编码在 CLI 源码中的，无法通过配置关闭。

CLI 获取到 Manifest 后，会解析其中的 layers 数组，得到所有层的 digest （SHA256 值）。然后，它向 Registry 并发发起多个 GET /v2/library/nginx/blobs/sha256:xxx 请求下载各层。下载完成后，CLI 将所有层按顺序写入本地存储（ /var/lib/docker/overlay2/ ），并生成镜像元数据。整个过程 CLI 都在前台显示进度条，但实际工作是由后台的 dockerd 守护进程完成的——CLI 只是发送指令的“传令兵”。

3.2 Daemon 层：调度中心的四大核心任务

dockerd 守护进程收到 CLI 的 POST /containers/create 请求后，开始执行四大核心任务：

第一，镜像准备（Image Preparation）
Daemon 检查本地镜像存储，确认 nginx:latest 的所有层均已存在且校验通过（SHA256 匹配）。若某层损坏，Daemon 会返回 invalid checksum 错误。此时 docker system prune -a 是终极解决方案，但它会清空所有未使用的镜像，需谨慎。

第二，容器创建（Container Creation）
Daemon 调用 containerd （Docker 的底层容器运行时）创建容器对象。 containerd 会：

• 在 /var/lib/docker/overlay2/ 下为容器创建新的可写层（ diff/ 目录）；
• 生成 config.json （OCI 运行时规范文件），定义容器的 rootfs、进程、网络、安全策略等；
• 调用 runc （符合 OCI 规范的容器运行时）执行 runc create <container-id> ，初始化命名空间和 cgroups。

第三，网络配置（Network Setup）
Daemon 调用 dockerd 内置的网络驱动（默认 bridge ）：

• 创建 Linux Bridge 设备 docker0 （若不存在）；
• 为容器创建一对 veth 虚拟网卡，一端插入容器网络命名空间，另一端加入 docker0 ；
• 为容器分配 IP（如 172.17.0.2/16 ），并设置默认路由 0.0.0.0/0 via 172.17.0.1 ；
• 添加 iptables DNAT 规则： -A DOCKER ! -i docker0 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 172.17.0.2:80 。

第四，容器启动（Container Start）
Daemon 调用 containerd 执行 runc start <container-id> ， runc 进入容器的 PID 命名空间，执行 nginx 进程。此时 docker ps 才能看到该容器。整个过程耗时通常在 200ms 内，但若 runc 启动失败（如 no such file or directory ），Daemon 会返回 OCI runtime create failed 错误，根源往往在 config.json 的 process.args 字段配置错误。

3.3 Runtime 层： runc 与 containerd 的底层协作

runc 是真正执行容器的“肌肉”，而 containerd 是它的“大脑”。 runc 本身不管理容器生命周期，它只负责一次性的 create 和 start 。容器运行后的所有管理（如 stop 、 pause 、 stats ）都由 containerd 通过 runc 的 state 接口查询并决策。

runc 的核心能力是调用 Linux 内核的 clone() 系统调用，传入 CLONE_NEWPID | CLONE_NEWNET | CLONE_NEWNS 等标志位，从而创建具有独立命名空间的进程。它还通过 cgroups v2 的 io.max 、 memory.max 等接口设置资源限制。例如，当你指定 --memory=512m ， runc 会在 /sys/fs/cgroup/memory/docker/<container-id>/memory.max 文件中写入 536870912 （512 1024 1024）。

containerd 则负责更高阶的抽象：它维护一个 containerd-shim 进程，作为 runc 和 dockerd 之间的“翻译官”。 shim 进程会：

• 在 runc 启动容器后，脱离 dockerd 进程树，成为 init 进程的子进程；
• 监听容器的 exit 事件，并将退出码上报给 containerd ；
• 管理容器的标准输出（stdout/stderr）流，将其转发给 dockerd ，再由 docker logs 命令读取。

这种设计实现了优雅的进程隔离：即使 dockerd 守护进程崩溃重启， shim 仍能保证容器继续运行，并在 dockerd 恢复后重新连接。这也是 docker desktop 在 Windows 上能稳定运行多年的技术基石——WSL2 中的 dockerd 崩溃，不会杀死你正在跑的 Nginx 容器。

4. 实操避坑指南：从安装到部署的 12 个血泪教训

纸上得来终觉浅，绝知此事要躬行。下面这 12 个问题，全部来自我过去三年在 27 个真实项目中踩过的坑。它们不是教科书里的“可能遇到”，而是“你一定会遇到”的高频故障。每一个都附带了现场诊断命令、根本原因分析和永久解决方案，拒绝模棱两可的“请检查网络”。

4.1 docker desktop requires windows 10 pro/enterprise/home 22h2 (19045) —— 版本墙的本质是 WSL2 内核

现象 ：在 Windows 10 21H2（19044）上安装 Docker Desktop 4.20+，安装程序直接报错，提示需要 22H2（19045）或更高版本。

诊断 ：这不是 Docker Desktop 的营销策略，而是微软 WSL2 内核的硬性要求。Docker Desktop 4.18+ 默认启用 WSL2 kernel version 5.15.90.1 ，而该内核版本要求 Windows 内核至少为 10.0.19045 （即 22H2）。执行 ver 命令可查看当前 Windows 版本号。

根因 ：WSL2 内核更新与 Windows 更新解耦，但新版内核依赖 Windows 内核的新特性（如 HVCI 支持）。微软强制要求版本对齐，以避免蓝屏。

永久方案 ：

• 升级 Windows： Settings > Update & Security > Windows Update > Check for updates ；
• 若无法升级（如企业 IT 策略限制），降级 Docker Desktop 至 4.17.x（支持 WSL2 kernel 5.10.x，兼容 21H2）；
• 绝对不要尝试“修改注册表绕过版本检查”，这会导致 WSL2 启动失败，且微软不提供回滚支持。

4.2 virtualization support not detected —— BIOS 设置的三个致命开关

现象 ：Docker Desktop 启动时卡在 “Starting Docker Engine…”，日志显示 virtualization support not detected 。

诊断 ：这不是 CPU 不支持虚拟化，而是 Windows 的虚拟化功能被禁用。执行 systeminfo | find "Hyper-V Requirements" ，若输出 Virtualization Enabled In Firmware: No ，则确认是 BIOS 问题。

根因 ：Windows 的 WSL2 依赖硬件虚拟化（Intel VT-x / AMD-V），但该功能在 BIOS 中默认关闭，且需同时开启三个开关：

• Intel Virtualization Technology (VT-x) 或 SVM Mode （AMD）；
• Intel VT-d Feature （I/O 虚拟化，WSL2 必需）；
• Trusted Execution Technology (TXT) （部分主板需关闭，与 WSL2 冲突）。

永久方案 ：

• 重启进入 BIOS（开机时狂按 F2 / Del / F10 ）；
• 找到 Advanced > CPU Configuration （Intel）或 Advanced > SVM Configuration （AMD）；
• 启用 Intel Virtualization Technology 和 Intel VT-d Feature ；
• 若存在 Trusted Execution Technology ，将其设为 Disabled ；
• 保存退出，重启后执行 wsl --update 更新内核。

4.3 docker engine is the underlying technology that... —— 日志中的“废话”其实是关键线索

现象 ：Docker Desktop 启动失败，日志中反复出现 docker engine is the underlying technology that... 这句看似无意义的描述。

诊断 ：这不是日志污染，而是 dockerd 进程启动超时的标志性文案。Docker Desktop 的启动监控脚本，在等待 dockerd 响应超过 60 秒后，会打印此句并放弃。执行 wsl -l -v 查看 WSL2 发行版状态，若 docker-desktop-data 显示 Stopped ，则确认是 dockerd 未启动。

根因 ： dockerd 启动失败的常见原因有三：

• /var/lib/docker/ 目录权限错误（应为 root:root ，而非 root:docker ）；
• 磁盘空间不足（ df -h / 或 df -h /mnt/wsl ）；
• daemon.json 配置语法错误（如多了一个逗号）。

永久方案 ：

• 检查权限： wsl -d docker-desktop-data 进入 WSL2，执行 ls -ld /var/lib/docker ，若非 root:root ，则 sudo chown -R root:root /var/lib/docker ；
• 清理空间： wsl --shutdown ，然后在 PowerShell 中执行 diskpart → list volume → select volume X → compact vdisk ；
• 验证配置： sudo dockerd --config-file /etc/docker/daemon.json --debug ，观察错误输出。

4.4 pull access denied for nginx, repository does not exist —— 标签、仓库、认证的三重迷宫

现象 ：执行 docker pull nginx 失败，报错 repository does not exist 。

诊断 ：这不是网络问题，而是镜像名称解析错误。执行 docker info | grep "Registry" ，确认 Insecure Registries 是否为空。若为空，说明 CLI 正在尝试连接 https://index.docker.io/v1/ ，但该地址已废弃。

根因 ：Docker 20.10+ 默认使用 v2 API，而旧版 Registry（如某些私有仓库）只支持 v1 。 nginx 作为官方镜像，其 library/nginx 前缀在 v2 API 下是隐式的，但若你的 daemon.json 中配置了错误的 registry-mirrors ，CLI 可能会错误地将请求转发到不支持 v2 的镜像源。

永久方案 ：

• 检查 daemon.json ： cat /etc/docker/daemon.json ，确认 registry-mirrors 地址以 https:// 开头，且是阿里云、腾讯云等主流厂商提供的 v2 兼容源；
• 强制使用官方 Hub： docker pull docker.io/library/nginx:latest （显式写出完整路径）；
• 若使用私有仓库，确保其支持 v2 API，并在 daemon.json 中配置为 insecure-registries （仅限测试环境）。

4.5 Error response from daemon: Conflict. The container name "/myapp" is already in use —— 容器命名冲突的静默陷阱

现象 ： docker run --name myapp nginx 失败，报错容器名已存在。

诊断 ： docker ps -a | grep myapp 会发现一个 Exited (0) 状态的容器。这是因为 --name 参数要求容器名全局唯一，且 docker run 不会自动清理同名旧容器。

根因 ：Docker 的容器名是强约束，而非建议。它用于 DNS 解析（ docker network connect 后，其他容器可通过 myapp 访问），因此绝不允许重复。

永久方案 ：

• 启动前清理： docker rm -f myapp （ -f 强制删除运行中容器）；
• 使用随机名：去掉 --name ，让 Docker 自动生成（如 friendly_galileo ），并通过 --network-alias 设置 DNS 别名；
• 在 CI/CD 中，始终使用 docker-compose ，其 service name 是逻辑名，与容器名解耦。

4.6 standard_init_linux.go:228: exec user process caused: no such file or directory —— 动态链接库的跨发行版诅咒

现象 ：自定义镜像启动失败，报错 no such file or directory ，但 Dockerfile 中的 COPY 命令明明成功了。

诊断 ：这不是文件路径错误，而是二进制文件的动态链接库（ .so ）缺失。执行 ldd /path/to/binary （在构建镜像的机器上），若输出中某行显示 not found ，则确认是此问题。

根因 ：不同 Linux 发行版的 C 库（glibc）版本不同。你在 Ubuntu 22.04 上编译的二进制，链接了 glibc 2.35 ，但 Alpine Linux 使用的是 musl libc ，完全不兼容。 FROM ubuntu:22.04 和 FROM alpine:3.18 是两个世界。

永久方案 ：

• 选择基础镜像：若应用是 Go/Python/Node.js 等解释型语言，优先用 alpine （小体积）；若是 C/C++ 编译型，用 ubuntu:22.04 （兼容性好）；
• 静态编译：Go 项目添加 CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' ；
• 多阶段构建：第一阶段用 golang:1.21 编译，第二阶段用 alpine:3.18 仅 COPY 二进制，避免携带编译环境。

4.7 WARNING: IPv4 forwarding is disabled. Networking will not work —— Linux 内核参数的隐形锁

现象 ：Docker 容器可以启动，但无法访问外网（ ping google.com 失败）， docker logs 显示警告 IPv4 forwarding is disabled 。

诊断 ：执行 sysctl net.ipv4.ip_forward ，若输出 net.ipv4.ip_forward = 0 ，则确认是此问题。

根因 ：Docker 的 bridge 网络依赖 Linux 内核的 IP 转发功能。该功能默认关闭，需手动启用。

永久方案 ：

• 临时启用： sudo sysctl -w net.ipv4.ip_forward=1 ；
• 永久生效： echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf && sudo sysctl -p ；
• 验证： docker run --rm alpine ping -c 2 8.8.8.8 应成功。

4.8 ERROR: for db Cannot create container for service db: status code not OK but 500 —— Compose 启动顺序的幻觉

现象 ： docker-compose up 启动 MySQL 容器失败，报错 Cannot create container for service db ，日志显示 mysqld: Can't read dir of '/etc/mysql/conf.d/' 。

诊断 ：这不是 MySQL 配置错误，而是 volumes 挂载路径权限问题。执行 ls -ld /host/path/conf.d ，若属主不是 root ，则确认是此问题。

根因 ：MySQL 容器以 mysql 用户（UID 999）运行，但宿主机目录 /host/path/conf.d 的属主是 root （UID 0）。Linux 的 UID 是数字，容器内 UID 999 尝试读取宿主机 UID 0 的目录，因权限不足而失败。

永久方案 ：

• 修改宿主机目录权限： sudo chown -R 999:999 /host/path/conf.d ；
• 在 docker-compose.yml 中指定用户： user: "999:999" ；
• 更优方案：使用 tmpfs 挂载（仅内存，无权限问题）： volumes: ["tmpfs:/etc/mysql/conf.d"] 。

4.9 `failed to solve: