大佬教程收集整理的这篇文章主要介绍了如何列出构建上下文中影响图像内容的所有文件？，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
是否可以列出从构建上下文复制到映像中的所有文件，或以任何其他方式影响映像的最终内容？
我需要这个来进行依赖跟踪；我正在为一个项目雕刻一个构建系统，该项目涉及构建多个图像并在本地开发环境中从它们运行容器。我需要针对快速的代码构建调试周期进行优化，因此我需要能够尽可能避免调用 docker build。了解构建上下文中最终影响映像的确切文件集将允许我将这些文件指定为调用 docker build 的构建步骤的跟踪依赖项，并避免不必要的重建。
我不需要提前生成这个文件列表，尽管这是最好的。如果不存在提前生成它的工具，但是有一种方法可以从构建的映像中获取它，那么也可以；我使用的构建工具能够记录构建后步骤发现的动态依赖项。
我敏锐地意识到的事情，并且我仍然做出明智的决定认为走这条路是值得的：
docker build 之外的依赖项来解决。与构建上下文中的文件不同，这些依赖项的数量要少得多（即 Dockerfile 的 RUN 命令显式从 Internet 获取的文件），或者已经解决了获取此类依赖项的详尽列表的问题（例如使用 apt-get 之类的包管理器获得的依赖项单独建模，安装的 RUN 会从模型生成到 Dockerfile 中）。除非您特别说明，否则不会将任何内容复制到图像中。因此，检查您的 Dockerfile 中的 COPY 语句，您就会知道构建上下文中的哪些文件被添加到图像中。
请注意，如果您有 COPY . .，则构建上下文中可能会有一个 .dockerignore 文件，其中包含您不想复制的文件。
我认为即使可能，您正在寻找的内容也没有用处。先前构建的映像中所有文件的列表不会影响新文件，并且很难区分影响构建的新文件和会被忽略的新文件。
您可以解析 Dockerfile，提取每个 COPY 和 ADD 命令，通过散列过程运行当前文件以识别它们是否从图像历史记录中的散列更改（您需要匹配 docker 的散列算法，其中包括文件所有权和权限等详细信息），然后当该哈希不匹配时，您就会知道构建需要再次运行。您可以考虑创建自定义 buildkit 语法解析器，或重用低级 buildkit 代码来构建您自己的上下文处理器。
但是在您花太多时间尝试实现上述代码之前，请意识到它已经存在，如docker build。我不会试图避免运行构建，而是专注于让构建利用构建缓存，以便新构建跳过所有未更改的步骤，可能生成完全相同的图像 ID。
以上是大佬教程为你收集整理的如何列出构建上下文中影响图像内容的所有文件？全部内容，希望文章能够帮你解决如何列出构建上下文中影响图像内容的所有文件？所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。