如何从另一个 Docker 容器访问安装在 Docker 容器中的应用程序？

Question

我有一个在 Python:alpine 容器中运行的 Python 服务器应用程序。服务器应用程序使用不同的生物管道，例如 BLAST 或 Bowtie 等（所有应用程序都是独立的，没有网络功能）。

在服务器端应用的 Python:alpine 容器中安装第三方软件会更好，还是每个应用都有单独的容器？我认为第二个更有意义。

但是，如果我的服务器应用程序、BLAST、Bowtie 等现在有 3 个以上的容器，我该如何从我的服务器应用程序访问这些第三方应用程序？

拥有多个容器的另一个优势是，我的服务器应用程序需要的所有应用程序的镜像都存在于 Docker 集线器上。

需要明确的是，这不是在容器之间共享数据（例如卷、绑定），而是直接调用其他容器中的应用。

Answer 1

让我谈谈我认为对你来说最重要的问题。

假设容器在同一台主机上运行，​​有 (>)2 种方式：

首选：docker --publish

使用这种机制，容器的端口被映射到主机端口

例如：

docker run --publish=8888:1111 service1
docker run --publish=9999:2222 service2

分别在 [localhost]:8888 和 :9999 上提供 2 项服务。

例如curl --request GET http://localhost:8888

<块引用>

注意这种方法的一个优点是即使容器使用相同的端口（例如两者都是 :1111），您也可以在主机上找到空闲端口

<块引用>

注意另一个优点是这种方法更加明确，您可以记录（使用 --publish 标志）哪些主机：容器端口被映射。

docker --net=host

使用这种机制，容器的端口直接绑定到主机的端口

例如：

docker run --net=host service1
docker run --net=host service2

提供 2 项服务。假设容器确实使用了 :1111 和 :2222，这些现在将直接映射到主机上的那些端口，即分别为 [localhost]:1111 和 :2222。

Answer 2

@DazWilkin's answer 只关注@RC1 问题的最后一部分（如何使特定端口上的主机提供 dockerized 服务）。

RESTful WS

当涉及到“dockerizing”应用程序时，第一部分与一个一般的、隐含的假设相关联：每个“后端”都应该通过 RESTful Web Services，也就是提供它的服务Web APIs。

总而言之，“前端”容器将依赖于“后端”容器，使用一些专用的 HTTP 请求（例如，HTTP GET 或 HTTP POST……如果需要，带有特定的负载）。

辅助工具

那么，如果您将应用程序拆分到多个容器中，如何使这种“dockerization”成为可能？

您需要确保这些“后端”容器中的每一个都是 HTTP 感知的；因此，您可以找到提供这种开箱即用的官方 Docker Hub 映像，或者您可能想要自己执行此任务（对应用程序的基于 CLI 的依赖项进行 dockerizing），依赖于这个项目的例子：

https://github.com/proycon/clam

<块引用>

使用 Web 应用程序前端快速将命令行应用程序转换为 RESTful Web 服务。您提供命令行应用程序及其输入、输出和参数的规范，CLAM 环绕您的应用程序以形成一个成熟的 RESTful 网络服务。

结束语

总而言之，这种策略（将 CLI 后端拆分到多个容器中）真的有必要吗？

一般的答案是：是的，一般来说这可能是一个非常好的策略，但不一定适用于您使用的每个 CLI 后端的特定情况，因此您可能需要权衡利弊，例如：< /p>

• Pro（可维护性）：每个镜像/容器（版本和配置）都可以独立于其他镜像/容器进行更新；
• Con（可维护性）：它会导致更多的簿记以 dockerize 和维护每个图像；
• Pro（可用性）：如果服务完成的计算成本很高，则它们可以分布在同一服务的多个副本中；
• Con（可用性）：与单个容器内的 CLI 系统调用相比，对另一个容器的 HTTP 请求速度较慢，而且“健壮性”较差；
• 等