docker - Docker上下文中已使用文件的列表

Question

假设我有一个包含多个结构如下的项目的存储库:

Root
 ├── bar
 │   ├── Dockerfile
 │   └── index.js
 ├── baz
 │   ├── Dockerfile
 │   └── index.js
 ├── foo
 │   ├── Dockerfile
 │   └── index.js
 └── shared
     └── utils.js
     └── shared.js

Foo， Bar和 Baz项目共享 shared文件夹中的一些库。当前，我将根文件夹作为 context发送，以构建这三个Docker镜像以包括 shared文件夹。

为了增加构建时间并减少Docker镜像的部署时间，我需要获取发送到这些镜像的 context的最小大小。

为此，我计划为每个图像创建一个临时文件夹，以用作 context。问题是，我需要知道每个图像使用哪些共享文件。

在此示例中，它非常简单，因为共享文件很少，项目也很少。但是实际上，有数百个共享文件和大约20个项目，我不想检查哪个项目使用了哪些共享文件。

这是我的 Dockerfile的示例:

FROM node:boron

RUN mkdir /app
WORKDIR /app

COPY package.json package.json
RUN yarn

COPY . .

RUN yarn release

CMD node release/server.js

我使用以下命令构建Docker镜像:

docker build -t foo:latest ..

注意指向 ..文件夹的 Root。这将导致所有共享文件发送到上下文，即使不需要的文件也是如此。

有没有一种简单的方法可以知道发送给Docker的 context的哪些文件被使用，哪些不使用？

Answer 1

在开始之前，请允许我清除一些误解并为新老用户定义一些术语。首先， docker image 或多或少是容器配置的快照。从文件系统到网络配置的所有内容都包含在镜像中，并可用于快速创建该镜像的新实例(容器)。

容器在运行特定图像的实例，这就是所有魔术发生的地方。可以将Docker容器视为微型虚拟机，但是与虚拟机不同，系统资源是一致共享的，并且具有VM不具备的其他一些功能。 You can get more information about this in another stack overflow post.

通过保存容器(docker commit *container* *repoTag*)或通过从 Dockerfile 进行构建来完成图像，这是自动构建说明，就像您自己对容器进行更改一样。它还为最终用户提供了使您的应用程序运行所需的所有命令的正在运行的“事务”。

To decrease build time ... of my Docker images

如果我错了，请纠正我，但是似乎您正在尝试为每个新容器构建镜像。只需使用Docker镜像即可启动一个容器。是的，构建它们确实需要花费一些时间，尤其是对于dockerfile而言，但是构建它们之后，用所需的应用程序来启动一个容器确实需要花费很少的时间，而这正是您所需要的。再次， docker镜像是以前容器配置的保存状态，并且加载保存状态不会也不应占用很多时间，因此您实际上不必担心dockerfiles构建时间。

~~~~~~~~~~~~~~~~~~~~~~~~~~

尽管如此，减少Dockerfiles的构建时间和容器最终文件的大小仍然是一个有效的问题，而转向自动依赖项解析是一种常见的方法。实际上， I asked a similar question nearly 2 years ago，因此它可能拥有一些有助于此工作的信息。
然而...

To decrease build time and reduce deployment time of my Docker images, I need to get the minimum size of context sent to these images.

回答我之前的问题的人Taco会对此回答

Docker isn't going to offer you painless builds. Docker doesn't know what you want.

是的，如果Docker从一开始就知道您想要什么，肯定会比较麻烦，但是事实仍然是，如果您想要以最大的尺寸和最佳的目标构建，就需要准确地告诉它 时间。但是，有多种方法可以获得最佳的构建时间和/或构建大小。

一个很明显的例子，正如Andreas Wederbrand在
这个相同的帖子，您可以从以前的版本中获取应用程序日志
运行以验证它需要或不需要什么。假设您确实建造了一个
将所有可能的依赖项转储到项目应用程序中。
您可以系统地删除所有依赖项，运行应用程序，
检查其日志中的故障，添加依赖项，检查输出
区别。如果输出相同，则删除失败的依赖项，
否则保持依赖关系。

如果我在dockerfile中写了这个特定命令，则可能会像这样，假设容器是从linux系统构建的:

#ASSUMING LINUX CONTAINER!
...
WORKDIR path/to/place/project
RUN mkdir dependencyTemp
COPY path/to/project/and/dependencies/ .
#Next part is written in pseudo code for the time being
RUN move all dependencies to dependencyTemp \
   && run app and store state and logs\
   && while [$appState != running]; do {\
   add dependency to folder && run app and store state and logs \
   if [$logsOriginal == $logsNew]; then remove dependency from folder \
   else keep dependency && logsOriginal = logsNew fi}

但是，这非常低效，因为您在内部启动和停止应用程序以查找应用程序所需的依赖项，从而导致构建时间非常长。没错，这会在一定程度上抵消您自己查找依赖项并减小某些大小的问题，但它可能无法100％地起作用，并且可能会花费更少的时间让您查找运行应用程序所需的依赖项设计代码以消除这种差距。

尽管更复杂，但另一个解决方案/替代方法是linkcontainers via networking。网络容器仍然是
对我来说是挑战，但在您想要的方面却很简单
完成它。假设您旋转了3个容器，其中2个是
项目，另一个是依赖项容器。通过网络，一个
容器可以引用依赖项容器并获得与当前设置类似的所有必需的依赖项。但是，与您的依赖项不同的是，依赖项不在应用程序上，这意味着您可以用最少的大小和时间来构建其他应用程序。

但是，如果依赖项容器出现故障，那么其他应用程序也会发生故障，这从长远来看可能不会导致系统稳定。另外，每次需要添加新的依赖项或项目时，您都必须停止并启动每个容器。

最后，如果要将容器保存在本地，则可以
看看volumes。卷是挂载文件系统的一种好方法
到 Activity 容器，以便容器内的应用程序可以
参考文件未明确存在。这意味着
更加优雅的Docker构建，因为所有依赖项都可以合法地
“共享”，而不必明确包含在内。

由于它是实时挂载，因此您可以添加依赖项和文件来更新同时需要它们的所有应用程序，以此作为额外的奖励。但是，当您希望将项目扩展到本地系统之外时，卷不能很好地工作，并且会受到本地篡改。

~~~~~~~~~~~~~~~~~~

底线是docker无法为您自动解决依赖关系，并且解决方法太过复杂和/或费时甚至无法远程考虑可能所需的解决方案，因为如果您找出并指定自己依赖。如果您想自己制定策略，那就继续吧。