Docker核心功能全解析：网络、资源控制、数据卷

文章目录

• 文章目录
• 前言
• 一、Docker网络管理
• • [1.1 Docker网络实现原理](#1.1 Docker网络实现原理)
  • [1.2 Docker端口映射](#1.2 Docker端口映射)
  • [1.2.1 随机端口映射](#1.2.1 随机端口映射)
  • [1.2.2 指定端口映射](#1.2.2 指定端口映射)
  • [1.2.3 Docker端口映射总结](#1.2.3 Docker端口映射总结)
  • [1.3 Docker的网络模式](#1.3 Docker的网络模式)
  • [1.3.1 host模式（与宿主机共享网络栈）](#1.3.1 host模式（与宿主机共享网络栈）)
  • [1.3.2 Container模式（与其他容器共享网络栈）](#1.3.2 Container模式（与其他容器共享网络栈）)
  • [1.3.3 无网络模式（none）](#1.3.3 无网络模式（none）)
  • [1.3.4 桥接模式（bridge）](#1.3.4 桥接模式（bridge）)
  • [1.3.5 自定义模式](#1.3.5 自定义模式)
  • [1.3.6 Docker网络模式总结](#1.3.6 Docker网络模式总结)
• 二、Docker资源控制（Docker优化）
• • [2.1 CPU资源控制](#2.1 CPU资源控制)
  • [2.1.1 设置CPU使用率上限（--cpu-period / --cpu-quota）](#2.1.1 设置CPU使用率上限（--cpu-period / --cpu-quota）)
  • [2.1.2 设置CPU占用比（权重 --- --cpu-shares）](#2.1.2 设置CPU占用比（权重 — --cpu-shares）)
  • [2.1.3 绑定指定CPU（--cpuset-cpus）](#2.1.3 绑定指定CPU（--cpuset-cpus）)
  • [2.1.4 CPU压力测试与验证示例](#2.1.4 CPU压力测试与验证示例)
  • [2.1.5 CPU资源控制注意事项](#2.1.5 CPU资源控制注意事项)
  • [2.2 内存使用限制](#2.2 内存使用限制)
  • [2.2.1 --memory与--memory-swap规则](#2.2.1 --memory与--memory-swap规则)
  • [2.2.2 内存限制示例命令](#2.2.2 内存限制示例命令)
  • [2.2.3 内存限制验证与OOM行为](#2.2.3 内存限制验证与OOM行为)
  • [2.2.4 内存限制建议与注意](#2.2.4 内存限制建议与注意)
  • [2.3 磁盘IO（blkio/io）控制](#2.3 磁盘IO（blkio/io）控制)
  • [2.3.1 常用Docker磁盘IO限制参数](#2.3.1 常用Docker磁盘IO限制参数)
  • [2.3.2 磁盘IO限制验证（dd测试）](#2.3.2 磁盘IO限制验证（dd测试）)
  • [2.3.3 磁盘IO控制注意事项](#2.3.3 磁盘IO控制注意事项)
  • [2.4 清理Docker占用的磁盘空间](#2.4 清理Docker占用的磁盘空间)
  • [2.5 Docker资源控制常见命令速查](#2.5 Docker资源控制常见命令速查)
  • [2.6 Docker资源控制常见陷阱与建议](#2.6 Docker资源控制常见陷阱与建议)
• [三、Docker数据卷容器（Data Volumes Containers）](#三、Docker数据卷容器（Data Volumes Containers）)
• • [3.1 数据卷](#3.1 数据卷)
  • [3.1.1 创建与挂载数据卷](#3.1.1 创建与挂载数据卷)
  • [3.1.2 在数据卷中写入数据](#3.1.2 在数据卷中写入数据)
  • [3.1.3 查看宿主机同步的数据](#3.1.3 查看宿主机同步的数据)
  • [3.2 数据卷容器](#3.2 数据卷容器)
  • [3.2.1 创建数据卷容器](#3.2.1 创建数据卷容器)
  • [3.2.2 在数据卷容器中写入数据](#3.2.2 在数据卷容器中写入数据)
  • [3.2.3 使用--volumes-from共享数据卷](#3.2.3 使用--volumes-from共享数据卷)
  • [3.2.4 在新容器中验证共享数据](#3.2.4 在新容器中验证共享数据)
  • [3.3 数据卷与数据卷容器总结](#3.3 数据卷与数据卷容器总结)
• 四、Docker容器互联（使用CentOS镜像）
• • [4.1 创建并运行源容器web1](#4.1 创建并运行源容器web1)
  • [4.2 创建并运行接收容器web2（--link互联）](#4.2 创建并运行接收容器web2（--link互联）)
  • [4.3 在接收容器web2中测试连接](#4.3 在接收容器web2中测试连接)
  • [4.4 Docker容器互联总结](#4.4 Docker容器互联总结)
  • [Docker 命令无法补全解决方案](#Docker 命令无法补全解决方案)
• 总结
• 前言
• Docker网络管理
• • Docker网络实现原理
  • Docker端口映射
  • 随机端口映射
  • [1.2.2 指定端口映射](#1.2.2 指定端口映射)
  • Docker端口映射总结
  • Docker的网络模式
  • • host模式（与宿主机共享网络栈）
    • Container模式（与其他容器共享网络栈）
    • 无网络模式（none）
    • 桥接模式（bridge）
    • 自定义模式
    • Docker网络模式总结
• Docker资源控制（Docker优化）
• • CPU资源控制
  • • [设置CPU使用率上限（--cpu-period / --cpu-quota）](#设置CPU使用率上限（–cpu-period / --cpu-quota）)
    • [设置CPU占用比（权重 --- --cpu-shares）](#设置CPU占用比（权重 — --cpu-shares）)
    • 绑定指定CPU（--cpuset-cpus）
    • CPU压力测试与验证示例
    • [2.1.5 CPU资源控制注意事项](#2.1.5 CPU资源控制注意事项)
  • 内存使用限制
  • • --memory与--memory-swap规则
    • 内存限制示例命令
    • 内存限制验证与OOM行为
    • [2.2.4 内存限制建议与注意](#2.2.4 内存限制建议与注意)
  • 磁盘IO（blkio/io）控制
  • • 常用Docker磁盘IO限制参数
    • [2.3.2 磁盘IO限制验证（dd测试）](#2.3.2 磁盘IO限制验证（dd测试）)
    • [2.3.3 磁盘IO控制注意事项](#2.3.3 磁盘IO控制注意事项)
    • 清理Docker占用的磁盘空间
  • [2.5 Docker资源控制常见命令速查](#2.5 Docker资源控制常见命令速查)
  • Docker资源控制常见陷阱与建议
• [Docker数据卷容器（Data Volumes Containers）](#Docker数据卷容器（Data Volumes Containers）)
• • 数据卷
  • • 创建与挂载数据卷
    • 在数据卷中写入数据
    • [3.1.3 查看宿主机同步的数据](#3.1.3 查看宿主机同步的数据)
  • 数据卷容器
  • • [3.2.1 创建数据卷容器](#3.2.1 创建数据卷容器)
    • [3.2.2 在数据卷容器中写入数据](#3.2.2 在数据卷容器中写入数据)
    • [3.2.3 使用--volumes-from共享数据卷](#3.2.3 使用–volumes-from共享数据卷)
    • [3.2.4 在新容器中验证共享数据](#3.2.4 在新容器中验证共享数据)
  • [3.3 数据卷与数据卷容器总结](#3.3 数据卷与数据卷容器总结)
• Docker容器互联（使用CentOS镜像）
• • 建并运行源容器web1
  • [4.2 创建并运行接收容器web2（--link互联）](#4.2 创建并运行接收容器web2（–link互联）)
  • [4.3 在接收容器web2中测试连接](#4.3 在接收容器web2中测试连接)
  • [4.4 Docker容器互联总结](#4.4 Docker容器互联总结)

文章目录

前言

一、Docker网络管理

1.1 Docker网络实现原理

1.2 Docker端口映射

1.2.1 随机端口映射

1.2.2 指定端口映射

1.2.3 Docker端口映射总结

1.3 Docker的网络模式

1.3.1 host模式（与宿主机共享网络栈）

1.3.2 Container模式（与其他容器共享网络栈）

1.3.3 无网络模式（none）

1.3.4 桥接模式（bridge）

1.3.5 自定义模式

1.3.6 Docker网络模式总结

二、Docker资源控制（Docker优化）

2.1 CPU资源控制

2.1.1 设置CPU使用率上限（--cpu-period / --cpu-quota）

2.1.2 设置CPU占用比（权重 --- --cpu-shares）

2.1.3 绑定指定CPU（--cpuset-cpus）

2.1.4 CPU压力测试与验证示例

2.1.5 CPU资源控制注意事项

2.2 内存使用限制

2.2.1 --memory与--memory-swap规则

2.2.2 内存限制示例命令

2.2.3 内存限制验证与OOM行为

2.2.4 内存限制建议与注意

2.3 磁盘IO（blkio/io）控制

2.3.1 常用Docker磁盘IO限制参数

2.3.2 磁盘IO限制验证（dd测试）

2.3.3 磁盘IO控制注意事项

2.4 清理Docker占用的磁盘空间

2.5 Docker资源控制常见命令速查

2.6 Docker资源控制常见陷阱与建议

三、Docker数据卷容器（Data Volumes Containers）

3.1 数据卷

3.1.1 创建与挂载数据卷

3.1.2 在数据卷中写入数据

3.1.3 查看宿主机同步的数据

3.2 数据卷容器

3.2.1 创建数据卷容器

3.2.2 在数据卷容器中写入数据

3.2.3 使用--volumes-from共享数据卷

3.2.4 在新容器中验证共享数据

3.3 数据卷与数据卷容器总结

四、Docker容器互联（使用CentOS镜像）

4.1 创建并运行源容器web1

4.2 创建并运行接收容器web2（--link互联）

4.3 在接收容器web2中测试连接

4.4 Docker容器互联总结

Docker 命令无法补全解决方案

总结

前言

在容器化技术飞速发展的今天，Docker作为最主流的容器引擎，已经成为开发、测试和运维岗位的必备技能。但很多同学在使用Docker时，往往只停留在"拉取镜像、启动容器"的基础操作，对Docker的网络通信、资源限制、数据持久化以及镜像定制等核心功能理解不深，导致在实际项目中遇到各种"卡壳"问题。

本文将从实战角度出发，系统梳理Docker的六大核心模块：网络管理、资源控制、数据卷容器、端口映射、容器互联和镜像创建，每个模块都包含原理讲解、命令示例和注意事项，帮你打通Docker使用的"任督二脉"。无论你是刚接触Docker的新手，还是需要巩固基础的开发者/运维工程师，这篇文章都能为你提供实用的指导。

Docker网络管理

Docker容器的网络通信是容器化应用部署的核心环节------容器之间如何通信？容器如何被外部网络访问？不同场景下该选择哪种网络模式？这些问题都需要通过Docker的网络管理机制来解决

Docker网络实现原理

Docker的网络通信依赖于Linux桥接技术，其核心是宿主机上虚拟的docker0网桥。具体实现逻辑如下：

1. 虚拟网桥（docker0）：Docker启动时会在宿主机创建一个名为docker0的虚拟网桥，它相当于一个"虚拟交换机"，负责连接宿主机上的所有Docker容器。

Container-IP分配：启动容器时，Docker会从docker0的网段（默认通常是172.17.0.0/16）中分配一个唯一的IP地址（即Container-IP）给容器，并将docker0设置为容器的默认网关。

3.容器间通信：同一宿主机内的所有容器都接入docker0网桥，因此容器之间可以通过各自的Container-IP直接通信（无需经过宿主机的物理网卡）。

4.外部网络访问限制：docker0是宿主机虚拟的网络设备，并非真实的物理网卡，外部网络无法直接通过Container-IP访问容器。若需外部访问，需通过端口映射将容器端口映射到宿主机端口，再通过"宿主机IP:宿主机端口"访问容器。

Docker端口映射

容器内部的端口默认无法被外部网络访问（因docker0是虚拟网桥），需通过端口映射将容器端口映射到宿主机端口，实现外部访问。Docker支持两种端口映射方式：随机映射(-P)和指定映射(-p)。

随机端口映射

使用-P（大写）参数，Docker会自动从32768开始分配一个未使用的宿主机端口，映射到容器暴露的端口（如Nginx的80端口）。适用于无需固定端口的场景（如测试环境）。

实战示例：

1.2.2 指定端口映射

使用-p（小写）参数，手动指定"宿主机端口:容器端口"，适用于需要固定访问端口的场景（如生产环境的Web服务）。

实战示例：

Docker端口映射总结

注意：宿主机端口需未被占用，若端口冲突，容器启动会失败，需更换宿主机端口。

Docker的网络模式

使用docker run创建容器时，可通过--net或--network参数指定容器的网络模式，不同模式对应不同的网络隔离与通信能力。Docker支持5种核心网络模式，以下逐一解析。

host模式（与宿主机共享网络栈）

原理：类似VMware的"桥接模式"，容器不创建独立的Network Namespace（网络命名空间），而是与宿主机共享同一个网络栈。因此，容器不会虚拟自己的网卡、配置独立IP，而是直接使用宿主机的IP和端口。

特点：网络性能最优（无额外网络转发开销），但容器会占用宿主机的端口，存在端口冲突风险。

适用场景：需要高性能网络的应用（如数据库）

实战命令：

Container模式（与其他容器共享网络栈）

原理：新创建的容器不与宿主机共享网络，而是与已存在的某个容器共享同一个Network Namespace。两个容器共享IP、端口范围，但文件系统、进程列表等其他资源仍保持隔离；可通过lo回环网卡直接通信。

适用场景：需要两个容器紧密协作（如"应用容器+日志收集容器"），且希望避免端口映射的场景。

实战案例：

无网络模式（none）

原理：容器拥有独立的Network Namespace，但Docker不为其配置任何网络（无网卡、无IP、无路由），仅保留lo回环网卡（用于容器内部进程通信）。

特点：完全封闭的网络环境，无法联网，安全性极高。

适用场景：不需要网络通信的离线任务（如本地数据处理、加密计算）。

实战命令：

桥接模式（bridge）

原理：Docker的默认网络模式（不指定--net时默认使用），类似VMware的"NAT模式"。容器拥有独立的Network Namespace，并通过docker0网桥与宿主机通信，具体流程，如下：

1. Docker启动时创建docker0虚拟网桥；

2. 为每个容器分配Container-IP，并设置docker0的IP地址为容器的默认网关。

3. 在主机上创建一对veth pair（虚拟网卡对）(连接两个不同的网络命名空间)：一端作为容器内的eth0网卡，另一端放在主机中， 以 * 这样类似的名字命名，并将这个网络设备加入到 docker0 网桥；

4.通过iptables的nat表配置端口转发，实现容器与外部网络的通信。

补充说明：virbr0与docker0的区别------virbr0是Linux虚拟化技术（如KVM、VirtualBox）创建的虚拟网桥，用于虚拟机通信；docker0仅用于Docker容器。

总结：bridge网络模式中，容器运行在同一宿主机内的虚拟网桥上，可以通过容器互相通信，与宿主机网络隔离。

自定义模式

Docker允许用户创建自定义网络，支持三种驱动：

bridge：类似默认bridge模式，但增加了DNS解析（容器可通过名称通信）、网络隔离等功能。单机网络模式，适合在一台宿主机、内容器互联；

overlay：用于跨主机容器通信（Docker Swarm集群场景）；

macvlan：容器像一台物理机一样直接获取宿主机的所在的网络的IP(容器像物理机一样直接连接局域网)

实战：创建自定义bridge网络并指定IP

默认bridge模式不支持手动指定Container-IP，需通过自定义网络实现：

Docker网络模式总结

额外附加：

Overlay：这是Docker Swarm模式的网络，主要用于在多个主机上创建一个分布式网络。容器间即便在不同的主机也能完成通信，相当于在跨主机的容器之间创建了一个覆盖网络。

Macvlan：Macvlan模式可以让容器直接连接到主机的物理网络，每个Macvlan接口都有一个唯一的MAC地址，此模式使得容器看起来就像是网络上的物理设备。

Docker资源控制（Docker优化）

为避免单个容器占用过多宿主机资源（如CPU、内存），Docker基于Linux的cgroups（Control Groups）机制实现资源限制。

cgroups是Linux内核提供的资源管理工具，支持限制、统计、优先级分配等功能

cgroups 的 4 大功能（简要）

资源限制：限制任务使用的总资源量。

优先级分配：如通过 cpu 时间片和 IO 带宽分配优先级。

资源统计：统计 cpu 时长、内存用量等。

任务控制：对 cgroup 中的进程执行挂起/恢复等操作。

CPU资源控制

设置CPU使用率上限（--cpu-period / --cpu-quota）

原理：Linux使用CFS（完全公平调度器）调度CPU，通过两个参数控制容器CPU使用率：

--cpu-period：调度周期（单位：微秒，默认100000，即100ms）；

--cpu-quota：容器在一个周期内可使用的CPU时间（单位：微秒，默认-1，即无限制）；

计算公式：可用CPU核心数 = cpu-quota / cpu-period（如50000/100000=0.5，即50%的单核CPU）。

实战示例

注意：若宿主机有4个逻辑核，0.5个CPU相当于整机CPU能力的12.5%（0.5/4=0.125）。

最小值/范围：--cpu-period 有效范围通常 1000 ~ 1000000（单位 us）。--cpu-quota 必须 >= 1000（1 ms）或者 -1（不限制）。

设置CPU占用比（权重 --- --cpu-shares）

原理：--cpu-shares指定CPU使用的相对权重（默认1024），仅在CPU资源紧张（容器争用CPU）时生效，并非硬限制。例如：

容器A（--cpu-shares 512）与容器B（--cpu-shares 1024）争用CPU时，分配比约为1:2。

实战示例：

绑定指定CPU（--cpuset-cpus）

原理：将容器进程绑定到宿主机的指定CPU核心（硬亲和性），避免进程在不同核心间切换，提升性能稳定性。

CPU压力测试与验证示例

通过自定义脚本模拟CPU高负载，验证资源限制效果：

在容器内创建一个繁忙循环脚本：

在容器内运行 ./cpu.sh，在宿主机观察 top 与 docker stats：

分别进入容器，进行压力测试

修改 cgroups 手工测试（示例）：

2.1.5 CPU资源控制注意事项

1. --cpu-shares是权重，非硬限制（CPU空闲时，容器可使用超过权重的资源）；

2. --cpu-quota/--cpus是硬限制，容器无法突破设定的CPU上限（quota = -1 表示无限制）；

3. --cpuset-cpus适合对性能稳定性要求高的场景（避免与其他进程抢核）（如数据库容器）。

4. 在多核宿主机上理解 quota/period 的含义（单位是 "相对于 1 个 CPU 的份额"）。

内存使用限制

内存限制通过-m/--memory和--memory-swap参数实现，避免容器耗尽宿主机内存

--memory与--memory-swap规则

--memory：限制容器可使用的物理内存（如-m 512m表示512MB）；

--memory-swap：限制容器可使用的物理内存+交换分区（swap） 总量，需与--memory配合使用；

核心规则：

1. 示例-m 300m --memory-swap=1g：物理内存300MB，swap可用700MB（1G-300M）；

2. 不设置--memory-swap：默认swap为--memory的2倍（如-m 512m，swap默认1024MB）；

3. --memory-swap=-1：swap无限制（使用宿主机所有可用swap）；

4. --memory-swap=--memory：容器不可使用swap（物理内存用尽触发OOM）。

内存限制示例命令

内存限制验证与OOM行为

验证内存限制：

OOM行为：若容器内存超过限制且无swap可用，内核会触发OOM Killer杀死容器，可通过docker logs查看日志或者 dmesg 来确认 OOM 事件。

2.2.4 内存限制建议与注意

1. 生产环境必须为容器设置内存限制，避免单个容器把宿主机内存耗尽；

2. 内存敏感型应用（如Redis、MySQL）建议禁用swap（--memory-swap=--memory），避免swap导致性能下降；

3. 配合容器健康检查和重启策略（如--restart=on-failure），应对OOM后的容器恢复。

4. 在 cgroup v2 环境下内存控制文件名/行为可能与 v1 略有不同（检查 /sys/fs/cgroup 结构）。

磁盘IO（blkio/io）控制

Docker基于cgroups的blkio控制器（cgroup v1）或io控制器（cgroup v2）限制容器的磁盘读写速率和IOPS（每秒输入输出次数）。

常用Docker磁盘IO限制参数

实战示例：限制容器对/dev/sda（宿主机磁盘）的写速率为1MB/s

2.3.2 磁盘IO限制验证（dd测试）

通过dd命令（跳过文件系统缓存）测试写速率：

2.3.3 磁盘IO控制注意事项

1. 限制需指定具体块设备路径（如/dev/sda），路径错误会导致限制失效；

2. 云环境或虚拟化环境中，底层存储（如AWS EBS、阿里云云盘）可能有自身IO限制，容器层限制需结合底层限制配置；

3. cgroup v2环境中，IO限制参数不同（如使用--device-io-max），需参考对应Docker版本文档。

清理Docker占用的磁盘空间

Docker运行一段时间后，会积累停止的容器、未使用的镜像、网络和构建缓存，可通过以下命令清理：

2.5 Docker资源控制常见命令速查

Docker资源控制常见陷阱与建议

1. 权重vs限额：--cpu-shares是相对权重（争用时生效），--cpu-quota/--cpus是硬限额（强制限制）；

2. cgroup版本差异：CentOS 7默认用cgroup v1，CentOS 8+或新内核可能用cgroup v2，控制器名称和参数不同（如blkio→io）；

3. IO 限制依赖底层设备：在云/虚拟机上测试时，注意底层虚拟磁盘的行为。

4. 生产环境监控：建议搭配Prometheus+Grafana+cAdvisor监控容器资源，及时发现资源瓶颈；

5. 权限控制：修改/sys/fs/cgroup目录下的配置需root权限，优先使用docker run参数配置，避免直接修改系统文件。

Docker数据卷容器（Data Volumes Containers）

容器的文件系统是临时的------容器删除后，内部数据会丢失。Docker的数据卷（Data Volumes）机制解决了这一问题，实现数据持久化；而数据卷容器则进一步简化了多容器间的数据共享。

数据卷

数据卷是容器内的特殊目录，可与宿主机目录或其他容器共享，具备以下特性：

数据持久化：容器删除后，数据卷中的数据不会丢失；

双向同步：宿主机与容器对数据卷的修改实时同步；

跨容器共享：多个容器可挂载同一个数据卷。

创建与挂载数据卷

通过docker run的-v或--mount参数挂载数据卷，格式：-v 宿主机目录:容器内目录。

-v /var/www:/data1: 将宿主机上的 /var/www 目录挂载到容器中的 /data1 目录。这样容器内 /data1 的修改会同步到宿主机上的 /var/www。

--name web1: 给容器指定一个名称 web1。

-it centos:7 /bin/bash: 使用 centos:7 镜像启动容器并进入交互式 shell。

在数据卷中写入数据

进入容器后，在数据卷目录（/data1）中创建文件，数据会同步到宿主机：

此时，容器中的 /data1/abc.txt 文件与宿主机中的 /var/www/abc.txt 文件是同步的。即使容器退出，宿主机上的数据依然存在。

3.1.3 查看宿主机同步的数据

退出容器后，查看宿主机/var/www目录，数据已同步：

数据卷容器

数据卷容器是专门用于提供数据卷的容器，不运行应用程序，仅作为"数据载体"，供其他容器通过--volumes-from挂载其数据卷。适用于多容器共享数据的场景（如微服务中的配置共享、日志存储）。

3.2.1 创建数据卷容器

--name web2: 给容器命名为 web2。

-v /data1 -v /data2: 在容器内部挂载了两个数据卷 /data1 和 /data2。这些数据卷不依赖于宿主机，而是仅仅存在于容器内。

3.2.2 在数据卷容器中写入数据

3.2.3 使用--volumes-from共享数据卷

创建新容器web3，通过--volumes-from挂载web2的数据卷：

--volumes-from web2: 这表示将容器 web2 中的所有数据卷挂载到新容器 web3 中。

3.2.4 在新容器中验证共享数据

进入web3容器，查看/data1和/data2目录，可看到web2中写入的数据：

3.3 数据卷与数据卷容器总结

1. 数据卷 (Data Volumes)：解决"容器数据持久化"问题，通过-v挂载宿主机目录；

2. 数据卷容器(Data Volumes Containers)：解决"多容器数据共享"问题，通过--volumes-from继承数据卷，无需每个容器都挂载宿主机目录；

3. 注意：数据卷容器删除后，其数据卷（匿名卷）不会被删除，需手动清理（docker volume rm <卷ID>）。

Docker容器互联（使用CentOS镜像）

容器互联是指通过网络让两个或多个容器直接通信，Docker早期通过--link选项实现，适用于简单的单主机容器通信场景（复杂场景建议使用自定义网络）。

建并运行源容器web1

首先创建"源容器"web1，作为通信的发起方：

4.2 创建并运行接收容器web2（--link互联）

创建"接收容器"web2，通过--link选项连接web1，格式：--link 源容器名称:源容器别名。

4.3 在接收容器web2中测试连接

进入web2容器，通过ping命令测试与web1的通信（无需知道web1的Container-IP）：

4.4 Docker容器互联总结

1. 核心原理：--link会在接收容器的/etc/hosts文件中添加源容器的别名与Container-IP的映射，因此接收容器可通过别名通信；

2. 局限性：--link仅支持单主机容器互联，且不支持动态更新（源容器IP变化后，接收容器的/etc/hosts不会自动更新）；

3. 替代方案：复杂场景（如跨主机、动态容器）建议使用Docker自定义网络（如overlay），支持DNS自动解析和动态IP更新。