Docker 正在推送所有层而不是最后一层

Question

昨天，我为我的应用程序推送了基础镜像层，其中包含运行所需的环境my_app。

\n

这一推动是巨大的，但它已经完成并在我的仓库中完成。

\n

这是目前我本地机器上的图像情况：

\n

\xe2\x9e\x9c  docker images                          \nREPOSITORY               TAG                 IMAGE ID       CREATED          SIZE\ndr_prof_patrick/my_app   my_app_v0           7e4cb75b4735   22 minutes ago   5.36GB\ndr_prof_patrick/my_app   my_app_base_image   b1cccd87e4f7   37 hours ago     5.35GB\npython                   3.8                 67ec76d9f73b   8 days ago       909MB\npython                   3                   f48ea80eae5a   8 days ago       917MB\n\n

\n

我对图像进行了一些细微的更改，如下所示：

\n

\xe2\x9e\x9c  docker history dr_prof_patrick/my_app:my_app_v0\nIMAGE          CREATED          CREATED BY                                      SIZE      COMMENT\n7e4cb75b4735   22 minutes ago   /bin/sh -c #(nop)  CMD ["python3" "main.py"]    0B        \n55fe27affa9a   22 minutes ago   /bin/sh -c pip install -r requirements.txt      16.1kB    \n3eba19411e42   22 minutes ago   /bin/sh -c #(nop) WORKDIR /my_app            0B        \n54249235bcba   22 minutes ago   /bin/sh -c #(nop) COPY dir:7f9da91b4e3f9ed60\xe2\x80\xa6   6.03MB    \nb1cccd87e4f7   37 hours ago     /bin/sh -c pip install -r requirements.txt      4.04GB    \n<missing>      37 hours ago     /bin/sh -c #(nop) COPY file:8e879a6a889ff22f\xe2\x80\xa6   305B      \n<missing>      37 hours ago     /bin/sh -c apt-get install ffmpeg libsm6 lib\xe2\x80\xa6   385MB     \n<missing>      37 hours ago     /bin/sh -c apt-get update                       17.7MB    \n<missing>      8 days ago       /bin/sh -c #(nop)  CMD ["python3"]              0B        \n<missing>      8 days ago       /bin/sh -c set -ex;   wget -O get-pip.py "$P\xe2\x80\xa6   8.31MB    \n<missing>      8 days ago       /bin/sh -c #(nop)  ENV PYTHON_GET_PIP_SHA256\xe2\x80\xa6   0B        \n

\n

它会尝试再次推动基础层，这大约需要 2 小时。

\n

\xe2\x9e\x9c  docker push dr_prof_patrick/my_app:my_app_v0    \nThe push refers to repository [docker.io/dr_prof_patrick/my_app]\n548f7bc62c43: Layer already exists \nfa5433c54740: Layer already exists \nf09b381b1d57: Pushing  1.102MB/4.041GB\na0f39ee33d3d: Layer already exists \na1e799af3370: Pushing  8.842MB/384.5MB\nc93f6a714096: Pushing   1.77MB/17.7MB\ne9df9d3bdd45: Layer already exists \n1271cc224a6b: Layer already exists \n740ef99eafe1: Pushing   5.42MB/48.56MB\nb7b662b31e70: Pushing  6.628MB/18.47MB\n6f5234c0aacd: Waiting \n8a5844586fdb: Waiting \na4aba4e59b40: Waiting \n5499f2905579: Waiting \na36ba9e322f7: Waiting \n\n

\n

我不知道我的工作流程如何阻止 docker 仅上传最新更改 - 任何帮助将不胜感激。

\n

编辑

\n

认为用于创建的 docker 文件my_app_v0可以提供帮助：

\n

FROM dr_prof_patrick/my_app:my_app_base_image\n\nCOPY . /my_app\n\nWORKDIR /my_app\n\nRUN pip install -r requirements.txt\n\nCMD ["python3", "main.py"]\n\n

\n

Answer 1

一旦上下文发生变化， Docker 就会使COPY层失效——无论接下来的步骤实际上取决于什么。在最后一刻复制文件——就您的情况而言，requirements.txt先复制，然后再复制其余的。像这样：

FROM dr_prof_patrick/my_app:my_app_base_image

WORKDIR /my_app

COPY requirements.txt .

RUN pip install -r requirements.txt

COPY . .

CMD ["python3", "main.py"]

还要看看你的文件.dockerignore，不要复制无用的文件。我看到使用的最佳策略是用作.dockerignore白名单，而不是黑名单，首先忽略所有内容，然后取消忽略您需要的文件：

*
!requirements.txt