Docker采用C/S架构，由Client（指令入口）、Daemon（调度核心）和Registry（镜像仓库）协同工作；镜像为分层只读文件系统，容器是镜像加可写顶层的运行实例；其本质是受Namespaces隔离和Cgroups限制的宿主机进程。

Docker 容器核心技术架构不是靠死记硬背，而是理解“镜像怎么来、容器怎么跑、资源怎么管、数据怎么留”这四条主线。掌握它，关键在理清底层逻辑和组件协作关系，而不是堆砌名词。

先搞懂三个核心角色怎么配合
Docker 是典型的客户端-服务端（C/S）结构，所有操作都围绕三块展开：

• Docker Client（命令行或 API）：你敲的 docker run、docker build 都是它发出去的请求，不干活，只传话；
• Docker Daemon（dockerd 进程）：真正干活的人，接收指令后调度镜像、启动容器、挂载卷、配置网络；
• Registry（如 Docker Hub）：镜像的“应用商店”，负责存和取，本地没镜像时自动去拉。

它们之间用 HTTP/HTTPS 通信，Client 甚至可以远程控制另一台机器上的 Daemon，这点对集群管理很实用。

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

重点吃透镜像和容器的分层本质
镜像不是完整系统盘，而是一层层叠加的只读文件系统（UnionFS，比如 OverlayFS）。每条 RUN、COPY 指令生成一层，层与层共享内容，节省空间。
容器 = 镜像 + 一个可写顶层（Container Layer）。运行时所有改动（新建文件、改配置）都写在这层，不影响底层镜像——所以重启容器，没存到卷里的修改就丢了。
这就解释了为什么 docker commit 不推荐：它把可写层打包成新镜像，破坏了“镜像不可变”的设计原则，容易引发环境漂移。

必须理解容器到底是什么进程
容器不是虚拟机，它本质是宿主机上的普通进程，只是被两样东西“罩住了”：

• Namespaces：给它划出独立的 PID、网络、挂载点、主机名等视图，让它“看不见”其他进程和配置；
• Cgroups：给它设好 CPU、内存、IO 的上限，防止它吃光服务器资源。
  换句话说，docker run nginx 启动的，就是一个被隔离+限流的 nginx 进程，轻、快、可控。

动手验证比看十遍文档更有效
学架构最怕纸上谈兵。建议按顺序做这几件事：

• 运行 docker info 查看本地 Daemon 状态和存储驱动（通常是 overlay2）；
• 用 docker history nginx:alpine 看镜像分层结构，观察每层对应哪条 Dockerfile 指令；
• 启动容器后，进到 /proc/<pid>/ns/ 目录下 ls -l，能看到它拥有的 namespace 文件；
• 用 docker inspect <容器> 查 HostConfig.CpuPeriod、Memory 字段，对照 cgroups 路径 /sys/fs/cgroup/... 验证资源限制是否生效。

不复杂但容易忽略