Docker镜像（Image）和容器（Container）到底有什么区别？

Question

**常见技术问题：** 初学者常困惑：Docker镜像（Image）和容器（Container）到底有什么区别？二者是否可以互换使用？镜像是不是“运行中的容器”？为什么`docker build`生成的是镜像，而`docker run`才启动容器？镜像分层只读、容器层可写——这个“写时复制”（Copy-on-Write）机制具体如何工作？当容器停止后，其数据会丢失吗？镜像ID与容器ID有何本质不同？能否从一个正在运行的容器直接生成新镜像？如果能，`docker commit` 与 `Dockerfile` 构建方式在可维护性、安全性和一致性上有何关键差异？此外，同一镜像可同时运行多个容器实例，这些容器之间是否共享内存或文件系统？它们的网络、PID、IPC等命名空间又是如何隔离的？理解这些区别，是掌握Docker生命周期管理、镜像分发、状态持久化及CI/CD自动化部署的前提。

Answer 1

```html

一、概念本质：镜像与容器的哲学分野

Docker 镜像（Image）是静态的、不可变的文件系统快照，由多层只读层（Layer）按顺序堆叠构成，每层代表一次构建指令（如 RUN、COPY）的文件系统变更；而容器（Container）是镜像的运行时实例——即镜像 + 可写容器层 + 运行时命名空间 + cgroups 限制 + 网络/存储驱动挂载的完整执行环境。二者绝不可互换：镜像无 PID 1、无进程树、无状态；容器有生命周期（created → running → paused → stopped → exited）、可交互、可信号控制。

二、构建与启动：为何 docker build ≠ docker run？

• docker build：编译期行为，解析 Dockerfile，逐层拉取基础镜像、执行指令、缓存中间层、最终生成带 Content-Addressable ID（如 sha256:abc123...）的只读镜像对象。
• docker run：运行时行为，以镜像为模板，创建新的可写容器层（thin writable layer），注入配置（env、volumes、network mode），调用 containerd-shim 启动 runc 容器进程，并为其分配独立 Linux 命名空间。

三、“写时复制”（Copy-on-Write）机制深度解析

COW 并非简单“复制整个文件”，而是按文件粒度在首次写入时触发：

1. 容器启动时，联合文件系统（如 overlay2）将镜像各只读层（lowerdir）与一个空可写层（upperdir）叠加为统一视图（merged dir）；
2. 当容器内进程修改 /app/config.json（该文件位于某只读层），overlay2 将其从 lowerdir 拷贝至 upperdir，再执行写入；
3. 若仅读取，则直接穿透至最上层存在的只读副本，零开销；
4. 删除文件时，overlay2 在 upperdir 创建 .wh.config.json 白名单条目，屏蔽下层同名文件。

四、数据持久性：停止 ≠ 数据丢失？关键取决于存储策略

场景	数据是否保留	技术依据
容器内写入 /tmp 或未挂载卷的路径	❌ 容器删除后立即丢失	可写层随容器生命周期销毁
使用 -v /host/path:/container/path	✅ 主机路径数据永久保留	绑定挂载（bind mount）绕过 Union FS
使用 --mount type=volume	✅ 卷数据独立于容器存在	Docker Volume 由 volume driver 管理，支持备份/迁移

五、ID 体系：镜像 ID 与容器 ID 的底层差异

镜像 ID 是其内容的加密哈希摘要（SHA256），具备强一致性：相同 Dockerfile + 相同构建上下文 → 相同镜像 ID；容器 ID 则是 UUIDv4 随机生成的运行时标识符，反映宿主机上该容器实例的唯一调度身份。二者语义完全分离：docker ps -a 显示容器 ID 与 IMAGE 列（镜像名称/ID）并列，印证“一对多”关系（一镜像→N容器）。

六、镜像生成双路径：docker commit vs Dockerfile 构建对比

graph LR A[运行中容器] -->|docker commit| B[新镜像] C[Dockerfile + Context] -->|docker build| D[新镜像] B --> E[隐式状态
不可追溯
易含敏感数据] D --> F[显式声明
Git 可审计
多阶段构建隔离构建/运行环境]

七、多容器隔离模型：同一镜像的 N 个“平行宇宙”

同一镜像启动的多个容器，通过 Linux namespace 实现强隔离：

• PID Namespace：每个容器拥有独立进程树，PID 1 为容器主进程（如 nginx），彼此不可见；
• Network Namespace：独占网卡、IP、端口、iptables 规则（默认 bridge 模式下通过 veth-pair + iptables DNAT 互通）；
• IPC Namespace：共享内存段、信号量、消息队列完全隔离，ipcs 在各容器内输出不同结果；
• Mount & UTS Namespace：文件系统挂载点、hostname/domainname 独立；
• 文件系统：仅容器层可写，镜像层全局只读共享 —— 10 个容器共用同一套只读层，节省磁盘与内存（page cache 复用）。

八、工程实践启示：从理解到落地的关键跃迁

对上述机制的掌握，直接决定 CI/CD 流水线健壮性：例如，若误用 docker commit 生成生产镜像，将导致构建过程不可复现、漏洞扫描失效、无法做 diff-based 层级缓存优化；又如，忽视命名空间隔离，在 Kubernetes 中部署多租户服务时可能引发 PID 泄露或网络端口冲突。真正的 Docker 工程化，始于对镜像不可变性的敬畏，成于对容器生命周期与存储策略的精准编排。

```