docker compose 容器内自动化故障注入需组合设计：compose 定义拓扑 + 容器预装 tc/iptables + 脚本触发；推荐 dockerfile 预集成工具，用 init 脚本管理网络策略，支持环境变量驱动多阶段故障，配合验证与可观测性确保效果。
用 Docker Compose 做容器内自动化故障注入，核心不是“加个插件就完事”，而是靠组合设计：用 Compose 定义服务拓扑 + 在容器里嵌入故障工具（如 tc、iptables）+ 通过脚本或健康检查触发动作。它不依赖外部平台，本地就能跑出接近生产环境的抖动、断连、脑裂等真实场景。
选对故障注入工具并预装进镜像
别在运行时临时安装 tc 或 iproute2——容易因权限、路径或 Alpine/Debian 差异失败。推荐在 Dockerfile 中提前集成：
- Alpine 基础镜像：RUN apk add --no-cache iproute2 iptables
- Debian/Ubuntu 镜像：RUN apt-get update && apt-get install -y iproute2 iptables net-tools && rm -rf /var/lib/apt/lists/*
- 若需更精细控制（如模拟带宽限制+丢包），可额外加入 netem 模块支持（默认已包含在 iproute2 中）
用 init 脚本统一管理网络策略
把故障规则写成可复用的 shell 脚本，挂载进容器并在启动时执行。例如，在服务目录下新建 fault-inject.sh：
#!/bin/sh # 启用网络控制 tc qdisc add dev eth0 root handle 1: prio # 模拟 200ms 延迟 + 5% 丢包 tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 200ms loss 5%
然后在 docker-compose.yml 中调用：
services:
mongo-node1:
image: mongo:6.0
command: bash -c "chmod +x /scripts/fault-inject.sh && /scripts/fault-inject.sh && mongod --replSet rs0"
volumes:
- ./scripts/fault-inject.sh:/scripts/fault-inject.sh
按需启停故障，支持多阶段测试
硬编码故障不够灵活。建议把故障开关做成环境变量或配置文件驱动：
- 定义 FAULT_MODE 环境变量（如 none / delay / partition / crash）
- init 脚本根据该变量执行对应 tc 规则，或直接跳过
- 配合 docker compose exec 手动切换：docker compose exec mongo-node1 sh -c "tc qdisc del dev eth0 root"
- 也可用 curl 触发容器内轻量 API（如 /health/fault?mode=delay）实现动态注入
验证与可观测性不能少
注入后得确认效果是否生效，否则就是“以为坏了，其实没坏”：
- 在容器内用 ping -c 3 target-host 测延迟，用 mtr 或 iperf3 测带宽和丢包
- 日志中输出 tc status：tc qdisc show dev eth0
- 搭配 Prometheus + cAdvisor 抓取容器网络指标，或用 haproxy stats 页面观察节点连接状态变化
- MongoDB 副本集场景下，重点观察 rs.status() 中 member.stateStr 和 lastHeartbeatRecv 时间戳是否异常
