在开发过程中使用docker运行前端构build过程是不是一个好主意？
我有一个angular色项目，我正在集装箱化。 它目前有足够的构build工具，前端开发人员可以（现在这是如何工作的）只是在项目根目录下运行gulp，在src /中编辑源文件，构build工具处理运行的traceur，模板和libsass等将内容分散到构build目录中。 该构build目录是在开发中提供的最servlets器，并由nginx在生产中处理。
我的目标是build立一个复制这个工作stream程的基于docker的环境。 我的用户是在不同种类的盒子上的开发人员，因此在dockerfile中冻结构build依赖关系似乎是有道理的。
我已经足够接近这个 – docker挂载主机卷，开发人员编辑本地磁盘上的文件，吞吐构build观察器正在docker容器实例中运行，并重build站点（并触发livereload等）。
我遇到的问题是围绕文件系统层如何工作。 在容器的build / frontend目录中重build文件的过程是否会生成大量无关的保存图层？ 这不是我真正喜欢的，因为我并不是疯狂的单调增长这个实例，因为开发人员调整和重build，调整和重build。 它只会在当地发展，但不得不经过“没关系，清理和重新开始”的过程似乎很乏味。
在容器的build / frontend目录中重build文件的过程是否会生成大量无关的保存图层？
不，叠加额外图层的唯一方法是提交一个容器，对新图像进行更改，然后使用该新图像创build下一个容器。 冲洗，重复。
当一个容器被提交到一个新的图像（ docker commit ... ）时，文件系统图层被保存。 当一个容器运行时，顶部会有一个单独的读/写层，它包含了容器自创build以来所做的所有更改。
不得不经过“好的，时间清理，重新开始”的过程似乎很乏味。
如果你使用docker run --rm ... run来运行构build容器docker run --rm ...那么你将得到免费的清理。 每次都会从图像中新build构build容器。
另外，数据卷绕过了union文件系统，所以很有可能你根本不会写容器的文件系统。