2017-02-09 184 views
2

将dockerized node.js发布到生产时, 发布包含开发依赖关系的镜像是否正确?如何删除生产Docker镜像中的开发依赖关系

我不是在谈论发展依赖 不在packages.json列出的devDependencies,我的意思是海湾合作委员会,蟒蛇,节点GYP,一些其他的* -dev包,包含一系列的头,静态库的。 所有这些都需要编译一些节点依赖关系(如node-sass)

一个想法可能是两个阶段的构建,一个包含所有* -dev依赖关系的图像,在那里构建东西,然后将结果导出到另一个只有二​​进制文件的新图像。

  • 优点:最终的“生产”形象小
  • 缺点:没有标准的方式来构建图像

一般来说,任何编译sofware我想在泊坞窗图像分发,不应含有用于构建二进制文件的编译器,头文件和工具。

+0

'运送包含开发依赖项的图像是否正确? 我不是在谈论发展依赖'大声笑 – Conan

+0

这就是为什么括号解释我所指的是什么发展依赖关系,但是,大声笑 – Cesar

+0

另请参阅https://www.dajobe.org/blog/2015/04/ 18/making-debian-docker-images-smaller/and http://blog.xebia.com/how-to-create-the-smallest-possible-docker-container-of-any-image/ – user2915097

回答

0

如果您删除依赖项,图像不会更小,因为较早的图层包含它们。

使用Docker 1.13尝试使用docker-build的新(实验性)--squash选项。

+0

准确地说,我可以不只是删除后一层中的文件,这就是为什么一个想法可能是使用图像编译,另一个图像打包二进制文件,除了现在我应该有两个单独的,不可继承的Docker文件 – Cesar

3

如果您不想在最终图像中包含某些内容,则必须仅在一个图层中执行所有相关命令(一个RUN语句)。

类似下面的(伪代码):是为RUN语句创建

RUN install dev-dependencies && build your-project && uninstall dev-dependencies 

只有一层,它不包含开发的依赖。

1

OP问题的答案取决于OP /他的公司为生产需要维护多少图像。

有一些策略可能:

  1. 如果保持的图像的量是中低和系统体系结构不是很复杂,在不使用几十个图像中一旦发现最简单的,最简单的解决方案,以保持是最好的一个。您可以使用1个单一版本来处理它。或者如果你想使用编译后的源代码作为可以承载不同内容的容器的基础(在这种情况下,第二阶段甚至可以在docker-compose up(系统启动)期间完成)。

  2. 如果需要保留图像纤细/存在大量使用相同图像的运行容器/编译文件的大小很大,您可以删除仅用于开发的依赖关系(如其他答案所示)。这会增加构建过程的时间跨度,但会导致较小的图像。第三种方法是完全不同的 - 如果有编译过程,使用独立编译单独容器(CI runner进程)中的资源的CI管道,并提供版本化的工件 - 您可以在生产版本中使用它(甚至可以将其存储某处,在S3/CDN/private上,可以访问部署存储),然后从那里获取它,或者仅使用托管在那里的文件(在CDN的情况下)。