在 Compose v2 中如何声明一个隔离的自定义网络
解读
国内一线企业在落地微服务时,普遍要求“网络平面隔离”以满足安全合规与灰度测试需求。Compose v2(docker compose,CLI 插件形态)虽然常被当成本地开发工具,但在中小集群或边缘场景下同样承担“准生产”职责。面试官抛出本题,核心想验证两点:
- 候选人是否理解 “隔离”= 与默认 bridge 断开、与外部 swarm/overlay 不互通、可控 IPAM”;
- 能否熟练写出 v2 推荐语法(YAML 顶层 networks 字段 + name/driver/labels/ipam 等),并解释与 docker network create 命令的映射关系。
知识点
- Compose v2 网络模型:project 级“默认网络”自动创建,名为 <project>_default;自定义网络需显式声明。
- 隔离手段:
– driver 选 bridge(单机)或 overlay(Swarm 集群),并关闭 external: true 避免复用现有网络;
– 通过 internal: true 关闭外部网关,阻断出网流量;
– 用 ipam.config.subnet 设定私有网段,防止与公司内网冲突;
– 加 labels 标记业务组,方便企业级 CMDB 对接。 - 作用域:Compose v2 文件顶层 networks 与 services.{service}.networks 两级联动,未引用的网络不会被创建。
- 生命周期:docker compose down 默认会删除声明的网络,除非标记 external: true 或 docker compose --volumes 之外再加保护标签。
答案
在 docker-compose.yml 中,用顶层 networks 字段声明即可实现“隔离的自定义网络”。下面给出生产环境可直接落地的模板,并逐行解释关键字段:
services:
app:
image: myrepo/app:1.2.0
networks:
- isolated_net
ports:
- "8080:8080"
networks:
isolated_net:
name: proj_isolated_net # 固定名称,避免 project 前缀导致重建
driver: bridge # 单机隔离;Swarm 场景改为 overlay
internal: true # **关闭外部网关,实现网络隔离**
ipam:
config:
- subnet: 172.30.100.0/24 # **私有网段,与公司内网不重叠**
gateway: 172.30.100.1
labels:
- "biz=payment" # 方便审计与工单系统对接
attachable: false # 禁止 docker run --network 手动挂载,增强隔离
执行 docker compose up -d 后,Compose v2 会:
- 先检查名为 proj_isolated_net 的 bridge 是否存在;
- 不存在则按声明创建,并关闭 ICC(inter-container communication)之外的出网能力;
- 把 app 服务接入该网络,与默认 bridge、host 及其他项目网络完全隔离。
若需彻底禁止项目级默认网络,可再加:
networks:
default:
external: false
name: none
拓展思考
- 多环境一致性:把上述 networks 片段拆成 override 文件(compose.prod.yml、compose.test.yml),结合 COMPOSE_FILE=compose.yml:compose.prod.yml 实现“同一份代码、不同隔离策略”,满足国内金融客户“测试网段与生产网段物理隔离”的合规要求。
- 安全加固:在 overlay 场景下,开启 --opt encrypted 或 driver_opts.encrypted=true,对跨宿主机流量做 AES-GCM 加密,防止东西向流量被内网镜像抓包。
- 灰度发布:利用 labels 标记版本号,配合自研脚本调用 Docker API,按 label 批量踢掉旧容器,实现“网络平面不变、仅替换容器”的平滑灰度。
- 与 Kubernetes 衔接:Compose v2 的隔离网络可整体迁移为 NetworkPolicy;面试时可主动提及“后续用 Helm 把 subnet 转为 Cilium 的 CIDR 规则”,展示云原生全景视野,容易拉高技术面评分。