如何合理架构存在公共代码依赖的两个Docker容器？

我更推荐对方案2做简单变通实现，在不调整目录结构、不违反Docker最佳实践的前提下解决公共代码依赖问题，是当前场景下性价比最高的选择。

各方案评估 #

• 方案1：完全不推荐，多份公共代码副本会导致一致性问题，后期迭代维护成本极高。
• 方案2（优化版）：首选方案，仅需调整docker-compose的构建配置即可解决「COPY源路径不在上下文内」的问题，不需要改动现有目录结构，Dockerfile仍然和对应业务代码存放在同一目录，完全符合最佳实践。
  配置示例如下：

  # docker-compose.yml
  version: '3'
  services:
    image1:
      build:
        context: . # 构建上下文设为项目根目录
        dockerfile: ./image1/Dockerfile1 # 指定Dockerfile的实际路径
    image2:
      build:
        context: .
        dockerfile: ./image2/Dockerfile2
  

  对应修改Dockerfile1的COPY逻辑即可：

  # image1/Dockerfile1
  FROM python:3.8-slim-buster
  WORKDIR /app
  # 直接从根目录下的common目录拷贝公共代码
  COPY ./common/ ./common/
  # 拷贝当前镜像的业务代码
  COPY ./image1/ ./
  

  可以配合根目录的.dockerignore文件排除不需要的内容，避免构建上下文体积过大。
• 方案3：技术上可行但不推荐，Dockerfile集中放在根目录会导致项目结构混乱，镜像数量增加后维护成本会显著上升。
• 方案4：适合公共代码需要跨多个项目复用的场景，如果仅在当前项目的两个镜像内使用，额外的公共镜像构建、推送、版本管控流程会增加不必要的复杂度。
• 方案5：适合公共代码迭代成熟、需要跨团队/跨项目共享的场景，小项目使用确实属于过度设计，打包、发布、依赖管理的流程成本过高。

其他实现思路 #

如果后续公共代码需要独立做版本管控，也可以采用git子模块的方式，将common仓库分别导入image1和image2目录，既避免了代码重复，也不需要调整构建配置，只需注意子模块的更新规则即可。

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