Api 我应该为共享Docker依赖项提供服务吗？

我有3个不同的服务，使用GraphicsMagick作为依赖项，我只是从Docker开始。所以我想知道，我是否应该为GraphicsMagick制作一个单独的LightAPI（可能使用PHP），并将其放在一个单独的Docker容器中？因为GraphicsMagick只是一个可执行文件

或者它会很慢，最好的方法是将GraphicsMagck安装为每个服务容器的依赖项

---

谢谢

正如您在评论和原始问题中提到的，这里有两种方法。一种是只在基本映像或单个服务映像中安装GraphicsMagick。另一种方法是构建一个特定于GraphicsMagick的独立服务（一种工作者或图像处理API）。我想答案将取决于目前对你最重要的利与弊

基础映像中的GraphicsMagick具有易于实现的优点。你不必做额外的事情。GraphicsMagick二进制文件的安装应该不会太麻烦，并且可能只会在最终生成的图像中添加几MB大小

使用GraphicsMagick构建单独的API服务映像会增加开发时间和服务复杂性。您可能还需要使用此模型实现某种服务发现，以便您的其他服务映像知道如何使用此新API。不过，今后这将是更具可扩展性的模型。根据负载的位置，这有助于单独扩展其他服务容器，如果需要，还可以在单独的主机上运行，特别是当图像处理可能会占用CPU并耗尽其他服务时

所以我会问你自己这些问题：

• 你能负担得起额外的开发时间吗
• 应用程序是否需要这种独立的可伸缩性
• 管理可能还需要一些服务发现的附加服务是否没有问题

---

如果您对所有这些问题的答案都是肯定的，那么您可能会为此构建一个单独的服务。Docker显然非常适合面向服务的体系结构，这可能是构建应用程序的更合适的方法。但是，对于“刚好有效”且现在实施所需时间最短的东西，可以说有很多，特别是如果它能在相当长的时间内正常工作的话。

GraphicsMagick是否作为一个单独的过程运行？这3个服务如何与之通信？@UsmanIsmail它只是一个可执行文件。由于它与所有这3个服务安装在同一台机器上，所以我可以在Java中执行类似的操作：processp=Runtime.getRuntime（）.exec（command）；我在考虑制作一个简单的RESTAPI，这样我就可以将其作为服务调用。为什么不将其安装到一个卷中，然后在3个容器之间共享该卷呢？或者更好的做法是在一个众所周知的位置创建一个基本容器，其中包含GraphicsMagick库，然后在3个DockerFile中使用

with base

。@UsmanIsmail“with base”可能是最好的主意。我只是想知道制作一个API并将其作为服务调用是否更好。谢谢我认为将其作为服务运行没有任何好处。