【虚拟容器-docker】docker核心“铁三角“--网络、存储、镜像管理

Docker的这三大模块------网络、存储、镜像管理，构成了容器技术核心的"铁三角"。

理解它们不能死记硬背指令，而要先吃透背后的设计逻辑：网络解决的是"容器怎么通"，存储解决的是"数据怎么留"，镜像解决的是"应用怎么装"。

---

一、网络：从隔离到互联的精密设计

Docker的网络设计基于Linux内核的Namespace（命名空间） 与veth pair（虚拟以太网对） 技术。它的核心逻辑是：为每个容器营造独立的网络协议栈，再通过虚拟设备像插网线一样将它们连起来。

1. 设计逻辑与核心模式

Docker守护进程启动时，默认创建一个叫docker0的虚拟网桥，这就像一个软件实现的交换机。当你创建容器时，Docker会做两件事：在容器内部创建一个eth0网卡，在宿主机上创建一个veth开头的虚拟接口，然后把它们一对一配对 起来，并把宿主机这端的veth"插"到docker0网桥上。

这套机制支撑起了四种核心网络模式：

• bridge（桥接模式）：默认模式。宿主机是一个大的局域网，每个容器都有独立IP，通过NAT访问外网。适合大多数单机容器场景。
• host（主机模式）：容器直接"借用"宿主机的网络栈，没有自己的IP，网络性能最高，但端口冲突风险大。适合对网络延迟极度敏感的服务。
• none（无网络） ：容器只有lo回环接口，完全隔离。适合不需要网络，或要自定义网络的特殊场景。
• container（容器共享模式）：新容器直接加入一个已存在容器的网络命名空间，共享IP和端口。适合让边车（Sidecar）模式，比如让一个日志采集容器共享应用容器的网络来监听本地端口。

2. 关键指令与进阶操作

基础网络模式的指定很简单，比如 docker run --network host。但更关键的，是自定义网络。

默认的bridge网络有一个致命缺陷：容器间无法通过服务名互相通信 ，只能靠IP。一旦容器重启，IP就会变化。已过时的--link参数就是为了解决这个问题的，但官方早已不推荐使用。

正确做法是创建自定义的bridge网络：

# 创建一个名为 my-net 的自定义桥接网络
docker network create my-net

# 将容器启动到这个网络中
docker run -d --name web --network my-net nginx
docker run -d --name app --network my-net my-app

这时，app容器可以直接ping web，因为Docker为自定义网络内置了DNS服务，将容器名解析为IP。这才是服务发现最原生的实现。

你还可以进行更精细的规划：

# 创建网络时指定子网段和IP范围
docker network create --driver bridge --subnet=192.168.100.0/24 --ip-range=192.168.100.128/25 my-gateway

对于跨主机的集群，则需要使用overlay模式，这通常与Docker Swarm结合，允许不同宿主机上的容器在同一个扁平网络内通信。

---

二、存储：数据的永恒与瞬逝

容器存储的核心矛盾在于：容器本身是无状态的，但业务数据需要持久化。容器中写入的数据默认存活在可写层，一旦容器被删除，数据就没了。

Docker的解决方案是将数据绕过容器文件系统，直接存储在宿主机上，从而获得独立于容器生命周期的持久性。主要有两种方式，理解它们的区别是选型的关键。

1. Volume vs. Bind Mount：设计的权衡

数据卷（Volumes）

这是Docker推荐 的方式。它由Docker完全管理（默认路径在/var/lib/docker/volumes/），你可以把它想象成一个Docker"托管"的U盘。它的好处是：与宿主机路径解耦，可以在不同系统上移植；可以安全地在多个容器间共享；可以通过卷驱动插件对接远程云存储（如NFS、AWS EBS）。这正是为生产环境的数据库设计的。

绑定挂载（Bind Mounts）

这是直接将宿主机上的一个绝对路径"映射"进容器，就像在墙上凿了个洞。它的强项是实时共享 ：你修改了宿主机上的代码文件，容器内立刻生效。因此，这是开发环境的神器，但在生产环境中使用需要格外注意权限和路径管理。

特性	数据卷 (Volumes)	绑定挂载 (Bind Mounts)
管理者	Docker	用户
适用场景	数据库、生产环境持久化数据	开发环境代码同步、配置文件注入
可移植性	高，与宿主机路径无关	低，强依赖宿主机文件系统结构
性能	较高，直接写主机文件系统	高，但大量小文件IO可能较差

2. 关键指令与备份恢复

使用-v或更推荐的--mount语法来挂载，后者对路径不存在等错误更明确。

# Volume方式：创建一个具名卷，并挂载到容器的 /var/lib/mysql
docker volume create mysql_data
docker run -d --name db -v mysql_data:/var/lib/mysql mysql:8.0

# Bind Mount方式：将宿主机 ./app 目录挂载到容器的 /app，并以只读方式
docker run -d --name web -v /home/user/app:/app:ro nginx

# --mount语法更清晰，明确指定type
docker run -d --name db --mount type=volume,source=mysql_data,target=/var/lib/mysql mysql:8.0

数据卷的强大还体现在数据备份与恢复，可以直接用一个临时的"工具人"容器来完成：

# 备份：启动一个临时容器，挂载数据卷和一个备份目录，执行tar打包
docker run --rm --volume=mysql_data:/volume --volume=/backup:/backup alpine tar cvf /backup/mysql_backup.tar /volume

# 恢复：同样用临时容器，但执行解包
docker run --rm --volume=new_mysql_data:/volume --volume=/backup:/backup alpine tar xvf /backup/mysql_backup.tar -C /

---

三、镜像管理：分层构建的工程之美

镜像是容器的"模具"。它的设计精髓在于联合文件系统（UnionFS） 带来的分层存储 与写时复制机制。

1. 设计逻辑：分层与写时复制

一个Docker镜像不是单一的整体，而是由多个只读层 叠加而成。你用Dockerfile里的每一行指令（FROM, RUN, COPY）都会创建一个新层。这样做的好处是惊人的效率提升：当你拉取一个新版本的nginx镜像时，只会下载你本地没有的那几层。

容器启动时，Docker会在所有只读层之上，添加一个薄薄的可写层（Container Layer）。当容器修改一个文件时，Docker会通过"写时复制"技术，先将这个文件从下层拷贝到可写层，然后再进行修改。这一机制保证了镜像层不可变，能被无数个容器实例安全地共享。

2. 从构建到分发的全生命周期

构建：不仅仅是打包

一个高质量的Dockerfile是一场关于"瘦身"和"加速"的工程实践。多阶段构建是其中的典范，它将编译环境和运行环境分离，最终镜像只包含运行时所需的二进制和依赖，体积可能从1.2GB骤降到15MB。

# 第一阶段：构建阶段，使用庞大的SDK镜像
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY *.csproj . 
RUN dotnet restore
COPY . . 
RUN dotnet publish -c Release -o /app

# 第二阶段：运行阶段，仅使用精简的运行时镜像
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from=build /app .
EXPOSE 80
ENTRYPOINT ["dotnet", "MyApp.dll"]

分发：从本地到仓库

镜像的流动离不开仓库（Registry）。docker build -t my-app:v1 . 只是把它留在了本地。把它推送到仓库（如Docker Hub、私有Harbor），才能真正实现跨环境交付。标签（Tag）是版本管理的核心，生产环境务必避免使用飘忽不定的latest标签，应使用语义化版本或Git Commit哈希。

安全：左移的防线

镜像安全不能等上线后再扫。现在Docker已内置docker scout命令，可以在构建后立即进行漏洞扫描，在生产上线前把高危CVE挡在门外。

# 快速扫描镜像的高危漏洞
docker scout cves --only-severity critical,high my-app:v1

---

梳理这三大模块可以看到，Docker并非一堆命令的堆砌。网络 通过虚拟化桥接和DNS实现了服务的互联与发现；存储 通过卷与挂载弥合了容器的短暂性与数据的持久性间的鸿沟；镜像则通过分层与写时复制，用工程化的方式解决了环境一致性与交付效率的难题。这三者共同构成了容器即服务、一次构建到处运行的技术根基。