将多个应用程序作为群集中的Docker容器,处理MySQL的方法

前端之家收集整理的这篇文章主要介绍了将多个应用程序作为群集中的Docker容器,处理MySQL的方法 前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

在线上有关设置Docker容器的大多数文章似乎都是围绕将应用程序分解为微服务并将其分配到各种容器中并将它们部署到集群中的想法而编写的.

我想找出处理多个不相关应用程序的数据库(例如MysqL)的最佳方法,这些应用程序是为不同的客户端编写的,部署在同一群集中.

假设我有10个不相关的小型应用程序(如wordpress),都需要访问MysqL数据库.我可以:

>将应用程序作为容器部署到群集中,仅包含应用程序代码,并设置专用的MysqL服务器或Google Cloud sql实例,并要求每个应用程序容器作为第三方服务连接到数据库.
>将应用程序作为容器部署到集群中.对于每个应用程序,还将一个单独的数据库容器部署到群集中并链接两者.
>将单独的数据库容器部署到集群中,并将该容器链接到集群中的各种应用程序容器.

这些解决方案中哪一个是最好的应用程序体系结构设计,哪个是最好的计算机资源使用?我的感觉是,在部署多个mysql容器(每个应用程序一个)时,也许是最佳设计,但它可能不是最有效的资源,因为我们将运行一堆MysqL容器.

最佳答案

Containerising db for each app seems to be “the docker way” and provide better isolation and portability

docker方式不是每个应用程序一个数据库,而是每个容器一个服务.
当您不在MysqL容器中运行另一个服务(app / ssh / monitoring …)时,MySQL便是一项服务.

因此,由每个应用程序分配一个数据库还是为所有数据库分配一个数据库取决于您.

我个人的选择是第三个:

  1. Deploy a separate database container into the cluster and link this container to the varIoUs application containers in the cluster.

我正在将kubernetes与postgres容器一起使用,该容器用作所有应用程序的数据库服务器.

我更喜欢这种选择,因为从OP的角度来看,备份/复制/应用维护比拥有30个不同的db服务器30 *从属30 *外部池30 *监视工具等更容易.
同样在我的情况下,我有更好的硬件资源使用率.

但是,我保留了将数据库移动到另一个专用的db-server容器的可能性,以防应用程序使用过多资源或太多应用程序已在使用数据库.

猜你在找的Docker相关文章