服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

将Docker同时用于长时间运行和短时间运行的进程是否合适?

假设我正在构build一个调整和优化图像文件的微服务。 这是一个长时间运行的守护进程,它提供了一个HTTP API来响应标准的GET / POST响应。 根据我对Docker的了解,这是一个集装箱化的完美用例 – 一个进程(HTTP服务器守护进程)无限期地运行在专用容器中。 对我来说,事情变得模糊的是,如果我们更深入地考虑这个服务的可能的构build方式。 比方说,对于每一个进来的请求,服务都会产生一个ImageMagick进程来调整图像的大小,然后是另一个pngquant或类似的进程来减小文件的大小。 由于这些程序将处理可能不可靠的用户提供的图像数据,所以一旦这些新版本发布,就能够将每个组件更新到最新的可用版本,这一点很重要。 但是,我如何根据Docker镜像和容器来分解这些组件呢? 我已经提出了一些不同的方法,但似乎仍然缺less一些东西: 一个大容器 在构buildHTTP API容器时,同时安装/编译ImageMagick / pngquant实用程序。 至于API守护进程知道,就像在任何其他计算机上运行。 要更新一个二进制文件,重build整个容器(即使API守护进程本身没有改变)。 如果需要独立testing/开发ImageMagick,可能会很尴尬,因为这不是这个容器布局的重点。 2.容器运行容器。 HTTP API是它自己的容器,ImageMagick是它自己的容器,pngquant是它自己的容器,等等。 当API处理需要调用这些实用程序之一的请求时,API代码会启动一个容器来转换一个图像文件,并且一旦转换完成,该容器就会被销毁。 据我所知,HTTP API代码需要一些非常高的权限才能创build一个新的容器; 从安全的angular度来看,这可能不是合理的做法。 3.包装和胶水。 将ImageMagick和pngquant包装在自定义的长时间运行的守护程序代码中,这样这些容器永远不必退出。 根据需要让HTTP API容器通过Dockernetworking与其他人进行通信。 似乎有许多毫无意义的间接和复杂性,没有真正的好处。 4.关于图像构图的东西,我失踪了。 它看起来并不像一个干净的方式,可以从多个可独立replace的图像中“拼凑”出一个容器。 如果有一种方法可以将包含ImageMagick,pngquant和HTTP API之一的多个图像组合到一个容器中,这将会很有趣。 根据我所看到的,replace/修改图像也会改变在其上面构build的所有图像,使得这种方法与#1没有什么不同。 我最关心的是能够独立开发/构build/testing/部署容器软件堆栈的组件,而不用重build或重新安装没有改变的部分。 如果这与Docker的devise理念冲突太强烈,我会愿意改变我对这种方法的看法或寻找不同的工具。