使用 docker-compose 部署的好处

Benefits of deploying using docker-compose

如果我在下面有任何错误,请纠正我。

假设我有简单的前端应用程序(React、Vue、Angular,等等),然后是后端(Node.js 或任何 RestAPI 提供程序)。

我可以 运行 将它们分开(不使用 docker),或者两者 docker 使用 docker-compose 进行处理。

方法 1: 当不使用 docker 时,我需要将我的应用程序部署到 2 个独立的服务器。

方法 2: 使用 docker-compose 时,这允许我将所有内容部署到单个服务器(如 heroku)。前端将在默认的 http 端口 80 下,后端将在端口 81 下。

我已经看到方法 2) 的巨大好处是我不需要为 2 次托管付费。

我的问题是:

  1. 从前端到后端的两种请求方法的速度比较是多少(我的意思是服务器端渲染,如 Nuxt.js 或 Next.js)。方法 2 是否会更快,因为它在同一台服务器上?
  2. 我缺少的其他优点和缺点是什么?

谢谢

无论是否使用 Docker 和 Docker Compose,都没有理由不能将前端和后端部署到同一台服务器。

使用容器提供了一种机制,您可以通过该机制打包应用程序并将它们发布到注册表,然后将它们部署到其他机器,并且非常有信心它们将 运行 在其他机器上不做任何更改,现在和将来。

如果没有 Docker,您需要提供脚本或某种其他形式的部署来将应用程序安装在其他机器上,除非这些其他机器是您的开发主机的完美克隆,否则您可能需要还要安装其他 OS 和软件依赖项。

因此,Docker 促进了应用程序的分发和打包,它有助于确保多个应用程序 运行 在单个主机上没有应用程序之间的(意外)交互。

如果您使用容器而不是 DockerCompose,您需要提供描述您的应用程序(组件:前端|后端)如何交互和组合的脚本(或类似脚本):它们使用哪些端口,它们的环境环境(变量)等。Docker Compose 促进了这一点,并提供了一种方便的机制来描述如何将各个部分组合成一个连贯的整体。

有 Docker 和 Docker Compose 的全功能替代品,但 Docker 和 Docker Compose 被广泛使用,您可以假设平台提供商和潜在用户您的应用程序,愿意|能够同时使用它们。

Docker 和 Docker Compose 都不会给您的应用增加性能开销。两者主要是控制平面(所谓的东西向)而不是应用程序的数据平面(所谓的南北向)的程序员。

运行 您的应用程序在单个服务器上的性能几乎总是比 运行在多台服务器上的性能更高——无论您是否使用容器——因为您可以避免网络延迟这对性能有重大贡献。