Dockerfile中的开发依赖关系或用于生产和testing的Docker文件
我不知道是否应该为我的Node.js应用程序创build不同的Dockerfile文件。 一个用于没有开发依赖项的生产，另一个用于包含开发依赖项的testing。
或者基本上是开发Dockerfile.dev一个文件。 那么这两个文件的主要区别在于npm install命令：
生产：
FROM ... ... RUN npm install --quiet --production ... CMD ...
开发/testing：
FROM ... ... RUN npm install ... CMD ...
出现这个问题是因为我想通过docker run命令在容器内运行我的testing。 因此，我需要testing依赖项（通常是我的开发依赖项）。
看起来有点奇怪把生产中不需要的依赖关系放到图像中。 另一方面，创build/维护第二个Dockerfile.dev只是微小的差异似乎也是不正确的。 那么这种问题有什么好的做法？
不，你不需要有不同的Dockerfile ，事实上你应该避免这种情况。
docker工作者的目标是将您的应用程序运送到一个不变的，经过良好testing的工件（docker图像），这对于生产和testing甚至开发都是一样的。
为什么？ 因为如果您为testing和生产构build不同的工件，那么您如何保证已经testing的产品也在生产中？ 你不能因为他们是两个不同的东西。
考虑到所有这一切，如果通过testing你的意思是unittesting，那么你可以将你的源代码安装在docker容器中，并运行testing，而无需构build任何docker镜像。 这很好。 记住，你可以为testing构build图像，但是速度非常慢，使开发安静困难和缓慢，这是不好的。 那么如果你的testing通过，你可以安全地build立你的应用程序容器
但是，如果你的意思是验收testing实际上需要运行在你正在运行的应用程序上，那么你应该为你的应用程序创build一个映像（只有一个），然后在另一个容器中运行testing（例如安装testing源代码）并对该容器运行testing。 这显然意味着你的应用程序的版本是不同的为您的testingnpm安装。
我希望这给你一些看法。
那么你将不得不支持几乎相同的几个Dockerfile 。 相反，我build议使用像生产configuration文件一样的NodeJSfunction。 另一个build议是关于
RUN npm install --quiet --production
最好创build单独的.sh文件，而不是像这样做：
ADD ./scripts/run.sh /run.sh RUN chmod +x /*.sh
也想想开始使用Gulp 。
UPD＃1
默认情况下， npm install安装devDependencies 。 为了解决这个问题 – 使用npm install --production或者将NODE_ENV环境variables设置为production值。
将脚本行放在单独的文件中是一个不错的做法， Dockerfile经常更改Dockerfile 。 如果您下次需要更改，则只需更新脚本文件即可完成。 将来你也可以做一些额外的工作。