如何避免并发执行docker compose up命令引发的重复资源错误？

1. 基于文件锁的排他执行（最可靠的脚本级方案） #

直接写个shell脚本，用文件锁保证同一时间只有一个docker compose up在运行——比单纯检查进程名靠谱得多，因为进程名可能被其他同名进程干扰，而文件锁是基于文件系统的排他锁，不会误判：

#!/bin/bash
LOCK_FILE="/tmp/docker-compose-up.lock"

# 尝试获取排他锁，超时时间设为10秒（可按需调整）
if ! flock -x -w 10 "$LOCK_FILE" true; then
    echo "已有docker compose up命令在运行，退出当前执行"
    exit 1
fi

# 执行启动命令，即使脚本被中断，锁会自动释放
docker compose up -d

# 可选：如果需要等待服务就绪，可加健康检查逻辑
# docker compose wait

把原来执行docker compose up的地方换成执行这个脚本即可。flock是大多数Linux系统自带的工具，macOS用户需要先通过brew install flock安装。

2. 精准检查服务/容器的运行状态 #

比解析docker compose ls输出更准确，直接用Docker Compose的内置命令判断目标服务是否已经启动：

# 替换成你的服务名（比如web），检查该服务是否处于运行状态
if docker compose ps -q web | xargs docker inspect -f '{{.State.Running}}' | grep -q true; then
    echo "服务已运行，无需重复启动"
    exit 0
fi

docker compose up -d

如果要检查所有服务，也可以用docker compose ps --services --filter "status=running"，只要输出不为空就跳过启动流程。

3. 测试框架层面加进程锁 #

如果你的测试库是用代码（比如Python、Java）实现的，可以直接在调用docker compose up的逻辑里加跨进程锁。比如Python用filelock库：

from filelock import FileLock
import subprocess

lock = FileLock("/tmp/docker-compose-up.lock")
with lock:
    # 先检查服务是否已运行，避免拿到锁后重复启动
    result = subprocess.run(
        ["docker", "compose", "ps", "-q"],
        capture_output=True,
        text=True
    )
    if not result.stdout.strip():
        subprocess.run(["docker", "compose", "up", "-d"])

这种方案能从测试代码层面直接控制，不需要额外维护脚本。

4. 利用Docker Compose的幂等性做容错 #

其实docker compose up本身是幂等的，但并发执行时会因网络/容器创建冲突报错。可以先尝试执行，报错后再判断是否是重复启动导致的：

docker compose up -d || {
    # 启动失败后，检查是否服务已经运行
    if docker compose ps -q | grep -q .; then
        echo "服务已运行，启动冲突忽略"
        exit 0
    fi
    # 非重复启动的错误（比如配置问题），正常抛出异常
    exit 1
}

这个方案最简单，但依赖错误场景的判断，适合逻辑简单的测试场景。

内容的提问来源于stack exchange，提问作者Khaled