我有一个有意义的项目，我正致力于集装箱运输。它目前有足够的构建工具，前端开发人员可以（这就是它目前的工作方式）只需在项目根目录中运行gulp，在src /中编辑源文件，构建工具处理运行traceur，模板和libsass等等第四，将内容吐出到构建目录中。该构建目录由开发中的最小服务器提供，并由nginx在生产中处理。
我的目标是构建一个基于docker的环境，复制此工作流程。我的用户是开发人员，他们使用不同类型的盒子，因此在dockerfile中冻结构建依赖关系似乎是有意义的。
我已经足够接近这个 - docker安装主机卷，开发人员编辑本地磁盘上的文件，并且gulp build watcher在docker容器实例中运行并重建站点（并触发livereload等等）。
我遇到的问题是围绕文件系统层的工作方式。这个在容器的构建/前端目录中重建文件的过程是否会产生大量无关的保存层？这不是我真正喜欢的东西，因为我不会因为开发人员调整和重建，调整和重建而单调地增长这个实例。它只能在当地发展，但必须经历好的时间才能清理并重新开始＃34;过程似乎乏味。
答案 0 :(得分：2)
这个在容器的build / frontend目录中重建文件的过程是否会产生大量无关的保存层？
不，堆叠额外图层的唯一方法是提交一个容器，对新图像进行更改，然后使用该新图像创建下一个容器。冲洗，重复。
将容器提交到新映像（docker commit ...）时，将保存文件系统层。当容器运行时，顶部将有一个读/写层，其中包含自创建容器以来对容器所做的所有更改。
必须经历＆＃34;好的，是时候清理并重新开始了＃34;过程似乎乏味。
如果您使用docker run --rm ...运行构建容器，那么您将免费获得清理。每次都会从图像中重新创建构建容器。
此外，数据量会绕过联合文件系统，因此您很可能无法写入容器的文件系统。