具有大量依赖项的javascript前端Docker构建过程

这与其说是“我的代码错了”，不如说是一个关于最佳方法是什么的问题。我正在为后端构建一个基于Aurelia（使用jspm）和Flask restful的小型Web应用程序。当涉及到为所有这些构建Docker容器时，我正在尝试不同的事情（目前它是一个包含前端和后端的单一容器）

我尝试过的两种方法：

在容器“外部”执行所有依赖项安装（npm/jspm），并使用Dockerfile的“copy”语句将所有工件复制到容器中。这很好，但是“构建工件”甚至所有文件的列表都非常慢。就文件数量而言，Aurelia产生了巨大的占用空间，因此Docker构建需要永远的时间才能完成

在容器内执行所有依赖项安装（在Dockerfile中使用RunJSPM安装等）。这种方法的好处是，主机保持不变，除了git和Docker引擎之外，没有任何要求。问题是jspm经常因为git速率限制而失败，因为大多数jspm包都使用git，而不是“自己的”repo。为了解决这个问题，我必须在构建时将github凭据发送到容器中，这增加了大量的复杂性

一种混合方法，其中我使用包含“大多数”所需包的标记配置一个单独的“基本容器”。这与#2相结合，将允许我将每日构建建立在至少满足大多数依赖关系的映像上。我必须实现一个单独的构建过程，以使基本容器保持最新

为了清楚起见：我的本地开发环境很好，问题是CI中的构建（非常）慢——这会让其他作业排队

---

我只是对人们正在做的事情感兴趣——我确信我不是唯一一个在使用Docker时，特别是在使用大量文件的前端框架时，面临过多构建时间问题的人。

我支持“级联”容器方法（这是Docker的一个重要特性）——这与您的混合方法基本相同。当然，没有什么能阻止您按顺序使用多个图像，而不仅仅是一个基本容器

您可以根据依赖项的层次结构级联构建。您还可以缩短链中每个docker映像的构建时间，从而加快连续构建

缺点是，这会引入更多的复杂性，因为您需要为每个分离的映像创建一个新的构建管道

对于诸如npm包之类的临时文件，我也倾向于在容器中构建这些文件-这使您的图像和构建设置更具可移植性，尽管我通常将git放在容器之外，并让构建包装器处理这些文件，这使您的git信誉更安全

你说你的构建速度很慢，但为什么这一定是个问题？一旦设置好环境，就不需要一直在重建？只需使用卷装载来针对正在运行的容器进行开发，并让构建过程在后台启动，只要合并（或其他）都由构建服务器处理