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

Question

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

我尝试过的两种方法:

1. 在容器“外部”执行所有依赖项安装 (npm/jspm)，然后使用 Dockerfile 的“COPY”语句将所有工件复制到容器中。这工作正常，但“构建工件”甚至所有文件的列表都非常慢。 Aurelia 生成的文件数量巨大，因此 Docker 构建需要很长时间才能完成。

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

3. 一种混合方法，在这种方法中，我使用包含“大部分”所需包的标签配置单独的“基本容器”。这与 #2 相结合将允许我将我的日常构建基于至少已经满足大部分依赖关系的图像。我将不得不实现一个单独的构建过程来使基础容器保持最新。

为了清楚起见:我的本地开发环境很好，问题是 CI 中的构建(非常)缓慢 - 这会排队其他作业。

我只是对人们在做什么感兴趣 - 我敢肯定，我不是唯一一个遇到过使用 Docker 构建时间过长问题的人，尤其是文件密集型前端框架。

Answer 1

我赞成“级联”容器方法(这是 Docker 的一大特色)——这与您的混合方法基本相同。当然，没有什么可以阻止您按顺序使用多个图像，而不仅仅是一个基本容器。

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

缺点是这会带来更多的复杂性，因为您需要为每个单独的图像创建一个新的构建管道。

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

您说您的构建速度很慢，但为什么这一定是个问题？设置环境后，您不需要一直重建吗？只需使用卷挂载来针对正在运行的容器进行开发，并在构建服务器处理所有合并(或其他)时让构建过程在后台启动。