时间戳

首页 > 解决方案 > 如何为 PostgreSQL 支持的 Spring、Angular 和 Django 微服务编写 Docker 容器

angular - 如何为 PostgreSQL 支持的 Spring、Angular 和 Django 微服务编写 Docker 容器

问题描述

使用复杂的解决方案（Kubernetes、Docker Swarm）部署一些使用 Spring Boot、Angular 和 Django 项目开发的微服务（由 PostgreSQL 数据库支持）的最佳方法是什么以及有什么好处？

考虑一下我有以下微服务：

每个微服务都包含一个 Dockerfile 来构建它。

这种平台的基于生产的部署的最佳方法是什么？

  1. 我可以很容易地使用 docker-compose 部署它，但是在这样的场景中使用复杂的解决方案（如 Kubernetes 或 Docker Swarm）的真正优势是什么？
  2. 我应该创建多少个 PostgreSQL 数据库容器？每个微服务一个 PostgreSQL 容器还是为所有使用 PostgreSQL 的微服务共享一个？

标签： angularspringdockerkubernetesmicroservices

解决方案

就像大多数关于部署的问题一样，“这取决于”，但让我试着回答一下。以免首先看到差异：

Docker compose vs（Docker swarm 或 Kubernetes）

您需要承认的最重要的区别是 docker compose 只能在单个主机上运行您的多容器应用程序。它不能在计算机集群上运行您的应用程序。如果您必须在集群上运行您的应用程序，您可以删除使用 docker compose 的选项。为此，您需要使用 Docker swarm 或 Kubernetes。您可以在此处和此处阅读有关它的更多信息。

Docker 群与 Kubernetes

简而言之，它们都是容器编排解决方案。这意味着您将使用它们来编排集群中的容器。他们都倾向于以不同的方式解决相同的问题。它们都用于：

  • 跨集群的容器编排
  • 缩放容器
  • 负载均衡容器
  • 容器之间的通信
  • 还有很多。在此答案中，您可以看到它们比较的摘要。

如果您决定使用 docker swarm，其中一个好处是用于 docker swarm 的 CLI 工具将与标准 Docker cli 非常相似，并带有一些附加选项。因此，如果您熟悉 docker 命令行，则设置和使用会容易得多。您也可以使用 docker compose yaml 文件直接在 swarm 上运行。你可以在这里和这里阅读。

另一方面，Kubernetes 非常强大，并得到所有主要云提供商的支持，例如：AWS、Azure 和谷歌云。这是：

  • 开源
  • 由云原生计算基金会 (CNCF) 支持
  • 有一个大社区支持它
  • 可以与其他容器解决方案一起使用（不仅是 docker）

如果您要使用 Kubernetes，请记住，您需要学习一个单独的工具来管理它，包括 kubectl CLI。

使用这两种方法各有利弊，但我的建议是使用 Kubernetes，如果你在云上部署你的解决方案并尽可能地与云无关。

这种平台的基于生产的部署的最佳方法是什么？

只知道你在这里给我们的信息我会说这也取决于你计划在哪里部署它：

  • 在 AWS、Azure、Google Cloud 或其他一些云提供商上？
  • 在非云提供商上，但仍然有多个服务器或某些服务器集群？
  • 在一台专用服务器上为您的所有组件？

在 AWS、Azure、Google Cloud 或其他一些云提供商上？

如果您正在使用某个云提供商并计划在那里部署它，那么我建议您使用 Kubernetes，因为主要的云提供商对它有很好的支持，如果需要，您可以将其移植到另一个云提供商。我还建议查看一些针对您正在使用的特定云提供商的容器编排的特定解决方案。我使用 AWS ECS 进行部署，并且我有很好的经验。请记住，与使用 Kubernetes 或 Docker swarm 相比，这种方式将更多地绑定到特定的云提供商。

在非云提供商上，但仍然有多个服务器或某些服务器集群？

在这里，您再次需要使用 Kubernetes 或 Docker swarm 来将您的解决方案部署到多个服务器。

在一台专用服务器上为您的所有组件？

通过在技术上部署在一台服务器上，您还可以使用 docker-compose。您用于开发设置的相同配置具有一些不同的配置。如果您在某个时候决定在集群上部署，这当然会限制您，因为您稍后需要迁移到 docker swarm 或 Kubernetes。

我可以很容易地使用 docker-compose 部署它，但是在这样的场景中使用复杂的解决方案（如 Kubernetes 或 Docker Swarm）的真正优势是什么？

我认为在上面的部分中，我解释了使用 docker compose 进行生产部署的优点和缺点。通常我个人的做法是我有 3 个环境：

  1. 使用 docker-compose 设置开发环境
  2. 使用 Kubernetes 设置生产环境并部署到 AWS 上的集群
  3. 使用 Kubernetes 设置暂存环境（生产副本）并部署到 AWS 上的集群，但使用较少的服务器（资源）

因此，对于 Staging，我使用相同的 Kubernetes 配置，但服务器更少（它很贵 :)）。通过这种方式，您可以确保您的设置在使用相同配置但资源较少的情况下正常工作，因为您的登台不需要像客户使用的生产那样多的资源。

我应该创建多少个 PostgreSQL 数据库容器？每个微服务一个 PostgreSQL 容器还是为所有使用 PostgreSQL 的微服务共享一个？

我不建议在生产环境中使用容器作为数据库。为什么？为什么不这样做的原因有很多。只是有太多的风险，一些人这样做是错误的。当然它可以适用于非常小的应用程序，但我仍然建议不要在生产环境中使用 docker 进行 Postgres。你可以在这里阅读更多关于它的信息。这是帖子中的一段话：

这是一个非常糟糕的反模式，即使你只是在做一个小项目，也会给你带来很多麻烦。您不应在为无状态应用程序构建的编排工具中运行有状态应用程序。

如果您使用的是云提供商，我建议将内置服务用于数据库即服务等数据库或 AWS 上的 RDS 等数据库。在这里你可以阅读它。对于 Azure，这将是 Aurora，其他云提供商也有类似的解决方案。另一方面，对于您的开发设置，可以在 docker 容器中使用数据库。

结论

根据您的偏好和需求，对除数据库之外的所有服务使用 Kubernetes 或 Docker swarm。由于您正在使用使用 Kubernetes 的微服务开发解决方案，因此您可以与云无关。这意味着您将能够使您的基础架构设置可移植，以便您可以轻松地将其移动到另一个云提供商。当然，如果这对你很重要？您甚至可以将其部署在标准托管服务提供商上，该服务提供商不是一台或多台服务器上的云提供商。

推荐阅读