假设我正在构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理念冲突太强烈，我会愿意改变我对这种方法的看法或寻找不同的工具。
简单地用多个“独立”容器来devise，其中一些通过远程API依赖于其他人。
没有必要有“容器运行容器”。 你只需要一个容器接受ImageMagick的处理请求，而这只是等待不断处理请求。 如果您需要分别升级该容器，请执行此操作。 这个持续运行的过程类似于你的“包装和粘合”点。
请注意，您可以将其构造成只是将ImageMagick作为批处理运行的结构。 这可能是所有你需要的。 但是，在容器中构造ImageMagick使您能够连接ImageMagick容器的不同实例，运行不同版本的ImageMagick，以便同时进行比较和testing。
关于从其他图像组装图像，是的，没有一个直接的方法来做到这一点，但有一些DockerHub的图像组成的基础图像（如tomcat和JDK）可能是两个不同的框架，和整合额外的更改以在映像中安装和configuration另一个特定的框架只需要从可能的公共Dockerfile中摘录出来，以显示如何执行此操作。