Docker Compose文件存储最佳实践咨询：是否采用Git子模块？

直接复制重复的docker-compose.yml和service文件夹确实会带来不少问题：重复维护成本高、不同项目间配置版本不一致、更新时需逐个项目修改易出错。针对这类场景，有几种成熟的最佳实践，同时Git子模块也是可选方案之一，具体分析如下：

一、可行的最佳实践方案 #

1. 提取公共配置为独立仓库，通过Git子模块引入 #

将共享的docker-compose.yml和service文件夹单独放到一个Git仓库中，然后在每个项目仓库中通过git submodule add命令引入这个仓库。这种方式的优势是：

• 公共配置的变更可以集中维护，一次更新后，各项目可自主选择是否同步最新版本
• 每个项目能锁定特定版本的公共配置，避免上游变更直接影响业务项目

操作示例：

# 在项目仓库中添加子模块
git submodule add https://your-repo/shared-docker-config.git docker-shared

注意事项：使用子模块需要团队成员熟悉相关操作，比如克隆项目时要加--recursive参数，切换分支后需同步子模块版本，避免出现配置缺失或版本不一致的问题。

2. 使用Git子树替代子模块 #

如果觉得子模块维护成本过高，可以选择Git子树。子树会把共享仓库的内容直接合并到主仓库的某个目录下，无需额外的子模块依赖管理，更新公共配置时直接从上游仓库拉取合并即可。

操作示例：

# 添加子树
git subtree add --prefix docker-shared https://your-repo/shared-docker-config.git main

# 同步上游更新
git subtree pull --prefix docker-shared https://your-repo/shared-docker-config.git main

这种方式更适合希望公共配置与项目代码紧密绑定，不想处理子模块复杂操作的场景。

3. 利用Docker Compose的extends功能拆分配置 #

如果只是docker-compose.yml存在大量重复，可以把公共服务配置抽成docker-compose.base.yml放到共享仓库，每个项目的docker-compose.yml通过extends引用基础配置，只保留项目独有的部分。

示例：

# 项目中的docker-compose.yml
version: '3.8'
services:
  backend:
    extends:
      file: ./docker-shared/docker-compose.base.yml
      service: base-backend
    environment:
      # 项目独有环境变量
      APP_ENV: production

这种方式无需额外的Git依赖管理，只需要确保各项目能访问到基础配置文件即可。

4. 将service内容打包为基础Docker镜像 #

如果service文件夹里是通用的服务依赖（比如基础运行环境、通用工具），可以把这些内容构建成一个基础Docker镜像，推送到私有镜像仓库，每个项目的Dockerfile直接基于这个基础镜像构建，避免重复复制文件。

示例：

# 项目Dockerfile
FROM your-registry/base-service-image:v1.0
# 项目独有构建步骤
COPY ./app /app

二、Git子模块是否适合你的场景？ #

Git子模块适合以下情况：

• 公共配置有独立的版本迭代节奏，需要与业务项目解耦
• 不同项目可能需要使用公共配置的不同版本（比如部分项目停留在稳定版，部分项目尝鲜新版本）
• 团队成员熟悉Git子模块的操作流程

如果你的场景不符合上述情况，比如公共配置更新频率低、所有项目需要保持统一版本，那么Git子树、Docker Compose extends或基础镜像方案会更简单易维护。

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