docker buildkit，新的 - 安装命令在构建过程中和上下文中的大文件
如果我有一个仅在构建时间期间需要的很大文件，并且如果我使用以下命令：
docker buildx build Dockerfile .
然后在Dockerfile中的某个地方进行一行：
RUN --mount=type=bind,target=/target_path,readonly,source=large_dir_or_file
该非常大的文件仍会被发送到Docker Daemon吗？我想知道-mount命令在这里是否为大文件提供任何优势？
另外，如果Docker上下文和守护程序在同一台计算机上，是否仍将所有上下文文件发送/复制到Docker Daemon可以看到它们的位置？
谢谢你， 丹尼尔
If I have a very large file that I only need during build time, and If I use the following commands:
docker buildx build Dockerfile .
and then a line somewhere in the Dockerfile:
RUN --mount=type=bind,target=/target_path,readonly,source=large_dir_or_file
would that very large file still got send to the docker daemon? I am wondering if the --mount command offers any advantage here for the large files?
Also, if the docker context and daemon are on the same machine, are all the context files still sent/copied to a location where docker daemon can see them?
Thank you,
Daniel
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
的优点
过度
是，大文件不会在您的Docker映像的层中膨胀。
但是，是的，它必须在上下文中，即使是本地的，它也会发送到Docker守护程序。
The advantage of
over
is that the big file will not bloat the layers of your docker image.
But yes, it must be in the context and it will be sent to the docker daemon even if it is local.
即使您在本地工作，
docker build命令始终将上下文目录的副本发送给Docker守护程序。如果您的构建环境非常大（尤其是在大小上的千兆字节上），这是在构建序列开始时打印出百分比进度的步骤。构建上下文是您传递给
docker build的目录中的所有内容，更少，.dockerignorefile 。无论给出的任何给定文件实际上是复制，这总是将其发送到本地或远程码头守护程序。我猜想您显示的BuildKit绑定装置选项可能会机械起作用。您需要确保大文件也位于
.dockerignore文件中，以免将其复制为构建上下文的一部分。如果您或您的CI系统会这样做，这将有效地阻止您使用远程Docker守护程序来构建，并且不是典型的模式，但是它应该在构建性能上有明显的差异，更具体地是在初始“复制”中。构建上下文“步骤”。您在一个问题中注意到，此文件仅在您的初始构建顺序中使用，我猜您使用多阶段构建，因此您的图像要小得多。我过去的经验是，诸如
docker push和docker pull之类的操作是不可靠的，因此，如果您无法从最终图像中删除此文件，则可能需要以其他方式将其注入容器中。Even if you're working locally, the
docker buildcommand always sends a copy of the context directory over its socket to the Docker daemon. If you have a very large build context (especially over a gigabyte in size) this is the step that prints out a percentage progress at the very beginning of the build sequence.The build context is everything in and underneath the directory you pass to
docker build, less anything that's in the.dockerignorefile. This will always get sent to the Docker daemon, local or remote, whether or not any given file is actuallyCOPYed into the image.I'm guessing the BuildKit bind-mount option you show probably will work mechanically. You need to make sure the large file is also in the
.dockerignorefile so it's not copied as part of the build context. This will effectively prevent you from using a remote Docker daemon to build, if you or your CI system will ever do this, and it's not a typical pattern, but it should have a visible difference in build performance and more specifically in that initial "copying the build context" step.You note in the question that this file is only used during your initial build sequence, and I'm guessing you copy the result of the build out using a multi-stage build so you have a much smaller image. My past experience has been that operations like
docker pushanddocker pullare unreliable with very large images, so if you can't remove this file from the final image you might need to inject it into the container in some other way.