Docker的构build过程为javascript前端提供了大量的依赖关系

这不是“我的代码是错误的”，因为这是一个关于什么是最好的方法的问题。我正在构build一个基于Aurelia（使用jspm）和Flask-restful作为后端的小型webapp。我试图build立一个Docker容器的所有这一切（现在是一个包含前端和后端的单一容器）不同的东西。

我试过的两种方法：

执行容器外的所有依赖安装（npm / jspm），并使用Dockerfile的“COPY”语句将所有工件复制到容器中。这工作正常，但“构build神器”，甚至所有文件的列表是非常缓慢的。 Aurelia在文件数方面产生了巨大的影响，所以Docker构build完成需要花费很长时间。
在容器内执行所有依赖安装（在Dockerfile中使用RUN jspm install等）。这种方法的好处是主机不受影响，除git和Docker引擎外没有任何要求。问题是，jspm通常因为git速率限制而失败，因为大多数jspm包使用git而不是它自己的“回购”。为了解决这个问题，我必须在构build时将github证书发送到容器中，这会增加很多复杂性。
一个混合的方法，我configuration一个单独的“基本容器”使用包含“最”所需包的标签。这与＃2相结合，将允许我将我的每日构build基于至less大部分依赖关系已经满足的映像。我将不得不实施一个单独的构build过程，以保持基本容器的最新。

为了清楚起见：我的本地开发环境是好的，问题是（非常）缓慢build立在CI – 排队其他工作。

我只是感兴趣的人在做什么 – 我敢肯定，我不是唯一一个面临使用Docker过多构build时间的问题，特别是在文件繁重的前端框架中。

我喜欢“级联”的容器方法（这是Docker的一个重要特性） – 这与您的混合方法基本相同。虽然没有任何东西阻止你顺序使用几个图像，当然，而不是一个单一的基本容器。

您可以根据您的依赖关系的层次结构级联您的构build版本。您还可以减less链中每个docker图像的构build时间，加快连续构build。

不利的一面是，由于您需要为每个分离的图像build立一个新的构buildstream水线，因此会带来更多的复杂性

对于临时文件（如npm包），我也倾向于在容器中构build这些文件 – 这使得您的映像和构build设置更具可移植性，尽pipe我通常将git保留在容器之外，并让构build包装器处理它，这会使git更加安全。

你说你的构build速度很慢，但是为什么这个问题呢？一旦build立了环境，您不需要一直重build？只要使用批量装载来开发运行的容器，并让构build过程在任何合并（或任何）都由您的构build服务器处理的背景下启动。