4、Docker网络模式：从单机到跨主机的通信实战
聊到Docker网络，我脑子里第一个蹦出来的场景是：刚接触容器那会儿，部署了一个Web应用，数据库在另一个容器里，结果死活连不上。折腾了半天，才发现是网络模式没搞对。说白了，Docker的网络就是解决「容器怎么找到彼此、怎么跟外界通信」的问题。
今天咱们就把Docker的几种网络模式掰开揉碎，从最常用的bridge，到跨主机的overlay，再到自定义网络的那些坑。嗯，跟着我走一遍，你也能成为容器网络的老司机。
4.1 Bridge网络：默认的「小局域网」
你装好Docker后，什么都不配，默认就是bridge模式。它会在宿主机上创建一个虚拟网桥（docker0），每个容器都会拿到一个私有IP，比如172.17.0.2。
我个人习惯把bridge网络想象成一个「小交换机」。所有连到这个交换机上的容器，都能互相通信。但注意，它们跟宿主机外部是隔离的——除非你做了端口映射。
核心特点：
- 容器间通过IP通信（默认）
- 宿主机外部只能通过映射端口访问容器
- 每个容器独立网络栈
举个例子，启动两个容器：
# 启动一个Nginx容器
docker run -d --name web1 nginx
# 启动另一个容器，测试连通性
docker run -it --name tester busybox ping web1你会发现，直接用容器名ping不通。为什么？因为默认的bridge网络不支持DNS解析。我曾经在这个坑里趴了半小时，后来才知道，要么用IP，要么用自定义网络。
小技巧：用 docker network inspect bridge 可以查看所有连到bridge网络的容器IP。我排查网络问题时，这招百试百灵。
4.2 Host网络：跟宿主机「穿一条裤子」
Host模式就简单粗暴了——容器直接使用宿主机的网络栈。没有虚拟网桥，没有私有IP，容器里的端口就是宿主机上的端口。
你想想看，这有什么好处？性能！少了一层NAT转换，网络延迟更低。我在做高并发压测时，经常用host模式来榨干网络性能。
docker run -d --name web_host --network host nginx启动后，直接访问宿主机的80端口就能看到Nginx页面。但代价是什么？端口冲突。如果你宿主机上已经有个服务占了80端口，那容器就起不来了。
注意：Host模式只适合Linux环境。在Mac和Windows上，Docker Desktop是通过虚拟机跑的，host模式的表现跟Linux不一样。我吃过这个亏，在Mac上调试得好好的，一上Linux生产环境就翻车。
4.3 None网络：完全隔离的「孤岛」
None模式，说白了就是不给容器配任何网络。没有网卡，没有IP，连localhost都访问不了。你可能会问：这有什么用？
我在项目中遇到过一种场景：跑一些离线计算任务，或者安全要求极高的容器，不希望有任何网络暴露。这时候none模式就是最佳选择。
docker run -it --network none busybox
# 进去后执行 ip addr，你会发现只有一个lo回环接口嗯，这种模式用得不多，但关键时刻能救命。比如处理敏感数据的容器，用none模式可以彻底杜绝网络泄露的风险。
4.4 Overlay网络：跨主机的「魔法隧道」
前面讲的都是单机场景。但微服务架构下，容器往往分布在多台机器上。怎么让不同宿主机上的容器互相通信？Overlay网络就是干这个的。
Overlay网络基于VXLAN技术，在宿主机之间建立一条「隧道」。容器看到的IP是虚拟的，实际数据包会被封装后通过物理网络传输。说白了，就是给容器们造了一个「跨主机的虚拟局域网」。
使用Overlay网络需要先初始化Swarm集群：
# 在管理节点初始化
docker swarm init
# 创建overlay网络
docker network create -d overlay my_overlay
# 启动服务，连接到overlay网络
docker service create --name web --network my_overlay --replicas 3 nginx我曾经帮一个客户排查过Overlay网络的性能问题。他们发现跨主机的容器通信比同主机慢很多。后来定位到是VXLAN封装导致的CPU开销。解决方案？要么升级网卡支持硬件卸载，要么改用Macvlan模式。
Overlay vs Bridge 对比：
| 特性 | Bridge | Overlay |
|---|---|---|
| 适用场景 | 单机 | 跨主机 |
| 性能 | 高（无封装） | 中（有封装开销） |
| 配置复杂度 | 低 | 中（需Swarm） |
| DNS解析 | 默认不支持 | 支持 |
4.5 自定义网络：生产环境的标配
说实话，我几乎不用默认的bridge网络。为什么？因为自定义网络有几个杀手级特性：
- 自动DNS解析：容器名就是域名，直接ping名字就能通
- 网络隔离：不同自定义网络之间不通，安全可控
- 动态加入/离开：运行中的容器也能切换网络
创建自定义网络很简单：
# 创建bridge类型的自定义网络
docker network create my_net
# 启动容器时指定网络
docker run -d --name app1 --network my_net nginx
docker run -d --name app2 --network my_net nginx
# 现在可以直接用容器名通信
docker exec app1 ping app2 # 能通！你想想看，这比记IP地址方便多了吧？而且微服务架构下，服务名就是域名，天然适合服务发现。
我的习惯：每个微服务项目都创建一个独立的自定义网络。比如 order_net、user_net。这样不同服务之间天然隔离，只有需要通信的服务才连到同一个网络。
4.6 容器间通信实战：一个完整的例子
光说不练假把式。咱们来一个完整的实战：部署一个Web应用+Redis缓存，用自定义网络实现通信。
# 1. 创建自定义网络
docker network create app_net
# 2. 启动Redis容器
docker run -d \
--name redis \
--network app_net \
redis:alpine
# 3. 启动Web应用（假设有个Python Flask应用）
docker run -d \
--name web \
--network app_net \
-p 8080:5000 \
-e REDIS_HOST=redis \
my_flask_app
# 4. 验证连通性
docker exec web ping redis # 应该能ping通
# 5. 查看网络详情
docker network inspect app_net这里有个关键点：REDIS_HOST=redis。因为自定义网络支持DNS解析，所以Web应用里直接用主机名redis就能连上Redis容器。不用写死IP，容器重启后IP变了也不怕。
避坑指南：我曾经犯过一个错误——把数据库和Web应用放在同一个容器里。后来要扩容，发现数据库也跟着复制了，数据全乱套。记住：每个容器只跑一个进程，数据库单独一个容器，通过网络连接。
4.7 网络模式选择指南
讲了这么多，到底该用哪种？我总结了一个简单的决策树：
- 单机开发测试：用自定义bridge网络，方便DNS解析
- 单机高性能场景：用host模式，但注意端口冲突
- 跨主机集群：用overlay网络，配合Swarm或K8s
- 安全隔离需求：用none模式，彻底断网
- 生产环境：永远用自定义网络，别用默认bridge
嗯，Docker网络这块内容不少，但核心就几个模式。你只要理解了bridge是「小局域网」、host是「共享网卡」、overlay是「跨主机隧道」，剩下的就是多动手实践。
我记得刚开始学Docker网络时，总觉得概念抽象。后来在项目里踩了几个坑，才真正理解每种模式的适用场景。所以，别怕犯错，多折腾几次就熟了。
下一章咱们聊聊Docker存储，那又是另一个精彩的世界。