Docker build遇文件/WORKDIR变更不更新镜像及ECR技术问询

示例Dockerfile #

################# Pulling Pre-Built Tensorflow Image ####################

ARG REGION=us-east-1
FROM 763104351884.dkr.ecr.${REGION}.amazonaws.com/tensorflow-training:2.10.0-gpu-py39-cu112-ubuntu20.04-ec2

ENV PYTHONUNBUFFERED=TRUE
ENV PYTHONDONTWRITEBYTECODE=TRUE

COPY packages/xbox_pkg/ /opt/packages/xbox_pkg/
WORKDIR /opt/packages/xbox_pkg/
RUN python setup.py build && python setup.py install


######################### Install Python Code ###########################

COPY game_module/requirements.txt /opt/ml/code/requirements.txt
RUN pip install --requirement /opt/ml/code/requirements.txt --no-cache-dir

COPY game_module/code/ /opt/ml/code/
### TEST-1
WORKDIR /opt/ml/code/
### TEST-2
#WORKDIR /opt/ml/


########################### SageMaker section ################################

# The directory within the container in which the Python script for training is located.
ENV SAGEMAKER_SUBMIT_DIRECTORY /opt/ml/code

# The Python script that should be invoked and used as the entry point for training.
ENV SAGEMAKER_PROGRAM xbox_main.py

问题描述 #

• 问题1.1：将WORKDIR从/opt/ml/code/改为/opt/ml/后执行构建，预期最后3层会重建，运行容器后应进入/opt/ml/目录，但实际未生效。
• 问题1.2：在game_module文件夹添加新源码文件后，容器中无法看到该文件。
• 问题2：推测是Docker缓存问题，但推送镜像到ECR时所有层均显示“Already Exists”，运行容器后变更仍未体现；使用--no-cache会全量重建6GB镜像，耗时过长。

核心原因 #

这是Docker的层缓存机制导致的：Docker会根据每一步指令的内容和上下文哈希判断是否复用缓存。如果前面的层未发生变化，后续依赖该缓存的层会直接复用旧内容，不会重新执行。

• 修改WORKDIR时，由于前面的COPY game_module/code/层缓存未失效，Docker会复用包含旧WORKDIR的缓存层，导致变更不生效。
• 添加新文件到game_module/code/时，若该目录的整体哈希未被Docker检测到变化（比如缓存未失效），COPY指令会复用旧层，新文件不会被复制到容器中。

无需全量重建的解决方案 #

1. 针对性破坏指定层的缓存 #

通过添加一个可变的构建参数，触发目标层之后的缓存失效，仅重建需要更新的部分：

• 在Dockerfile中，需要重建的层之前添加一个空的构建参数：

  # 在WORKDIR修改处之前添加
  ARG CACHE_BUST=1
  COPY game_module/code/ /opt/ml/code/
  ### TEST-2
  WORKDIR /opt/ml/
  

• 构建时传入随时间变化的参数，破坏后续层的缓存：

  docker build -t xbox_main . -f Dockerfile --build-arg REGION=us-east-1 --build-arg CACHE_BUST=$(date +%s) --progress=plain
  

  此方法只会从ARG CACHE_BUST之后的层开始重建，前面的TensorFlow基础镜像、pip依赖安装等大层会继续复用缓存，大幅缩短构建时间。

2. 调整Dockerfile层顺序（预防措施） #

将频繁变更的操作（如WORKDIR修改、源码COPY）放到更靠后的位置，同时将稳定不变的操作（如基础镜像拉取、依赖安装）放到前面。这样后续变更时，只有后面的小层需要重建，避免影响前面的大层缓存。

3. 使用--no-cache-from精准跳过缓存 #

如果知道需要跳过的旧镜像层，可以指定--no-cache-from参数，仅重建该镜像之后的层：

docker build -t xbox_main . -f Dockerfile --build-arg REGION=us-east-1 --no-cache-from xbox_main:old --progress=plain

其中xbox_main:old是之前构建的旧镜像标签，此命令会跳过该镜像的缓存，从对应位置开始重建后续层。

相关问题解答 #

问题1：推送至AWS ECR时，Docker是否会检查层哈希值，仅推送更新的层？ #

是的。Docker和ECR均基于SHA-256内容哈希识别镜像层：本地层的哈希与ECR中已存在的层哈希匹配时，会显示“Already Exists”并跳过推送；只有哈希不一致的新层才会被上传。

问题2：能否无需拉取到本地机器，直接向ECR中的Docker镜像提交变更？ #

不行。Docker镜像的构建依赖本地上下文，无法直接在ECR上修改现有镜像层。但可以使用AWS CodeBuild等云端构建服务，在云端完成镜像更新，无需本地拉取大基础镜像，构建完成后直接推送到ECR，节省本地带宽和时间。

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