我刚好碰到过类似的多仓库Docker Compose共享场景，给你几个实用的方案，帮你彻底摆脱绝对路径的困扰：

1. 利用Docker Compose的--project-directory参数（最直接的方案） #

Docker Compose本身就提供了专门解决这类路径问题的参数：--project-directory。它可以指定所有Compose文件解析相对路径时的基准目录，完全不需要修改你现有的基础设施docker-compose.yml，只需要调整启动命令即可：

docker-compose --project-directory /path/to/your/infrastructure-repo \
  -f /path/to/your/infrastructure-repo/docker-compose.yml \
  -f /path/to/your/business-component-repo/docker-compose.yml \
  up -d

这里的核心逻辑是：--project-directory会强制让基础设施Compose文件里的所有相对路径（比如working_dir、挂载卷的相对路径）都基于基础设施仓库的根目录解析，而不是业务组件的目录。完美适配不同开发者的本地环境！

你可以把这个命令封装成一个简单的Shell脚本（比如start-stack.sh）放在基础设施仓库里，开发者只需要传递业务组件的Compose文件路径就能启动，不用手动记复杂参数：

#!/bin/bash
# start-stack.sh
INFRASTRUCTURE_DIR=$(dirname "$0")
BUSINESS_COMPOSE_PATH=$1

docker-compose --project-directory "$INFRASTRUCTURE_DIR" \
  -f "$INFRASTRUCTURE_DIR/docker-compose.yml" \
  -f "$BUSINESS_COMPOSE_PATH" \
  up -d

开发者使用时只需要执行：

/path/to/infrastructure-repo/start-stack.sh /path/to/business-repo/docker-compose.yml

2. 使用环境变量动态注入基准路径 #

如果不想依赖--project-directory参数，可以在基础设施的docker-compose.yml里用环境变量替代硬编码的绝对路径，比如：

# infrastructure/docker-compose.yml
services:
  cassandra:
    image: cassandra:latest
    working_dir: ${INFRASTRUCTURE_BASE_DIR}/cassandra/scripts
    volumes:
      - ${INFRASTRUCTURE_BASE_DIR}/cassandra/data:/var/lib/cassandra/data

然后启动时通过-e参数传递环境变量，或者在启动脚本里自动获取基础设施仓库的路径：

INFRASTRUCTURE_BASE_DIR=/path/to/infrastructure-repo
docker-compose -f $INFRASTRUCTURE_BASE_DIR/docker-compose.yml \
  -f /path/to/business-repo/docker-compose.yml \
  -e INFRASTRUCTURE_BASE_DIR=$INFRASTRUCTURE_BASE_DIR \
  up -d

这种方式更灵活，适合需要动态调整路径的场景，但需要修改基础设施的Compose文件。

3. 用模板渲染工具生成适配的Compose文件（进阶方案） #

如果你的配置逻辑更复杂，可以把基础设施的Compose文件做成模板（比如docker-compose.template.yml），使用envsubst或者专门的模板工具（比如jinja2-cli）在启动前渲染出适配当前环境的文件：

模板示例：

# infrastructure/docker-compose.template.yml
services:
  kafka:
    image: confluentinc/cp-kafka:latest
    working_dir: {{ infrastructure_base_dir }}/kafka/config
    volumes:
      - {{ infrastructure_base_dir }}/kafka/logs:/var/log/kafka

然后用jinja2-cli渲染：

jinja2 docker-compose.template.yml -D infrastructure_base_dir=/path/to/infrastructure-repo > docker-compose.yml

之后再和业务组件的Compose文件一起启动。这个方案适合有大量动态配置的场景，但会增加一点维护复杂度。

推荐最佳实践 #

• 优先选择--project-directory方案，因为它不需要修改现有配置，最简洁高效。
• 用启动脚本封装所有复杂命令，避免开发者手动输入出错，同时统一维护启动逻辑。
• 如果团队有统一的开发环境脚本，可以把基础设施仓库的路径配置在全局环境变量里，进一步简化操作。

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