linux - 当 Redis 和弹性搜索等服务被多个其他服务使用时，是否应该为它们创建单独的 docker 容器？

Question

我的整个堆栈都在 docker compose 容器设置中。目前，负载是这样的，它可以全部在单个实例上运行。我有两个独立的应用程序，它们都使用 redis 和弹性搜索。

我看到有人建议在 MySQL 之类的情况下，适当的容器理论表明，如果您有两个单独的应用程序使用它们，那么您应该为两个单独的数据库使用两个单独的容器。

我认为这对 MySQL 来说很好，因为我的理解是，单独的 MySQL 实例并没有真正增加太多的内存或处理器开销。

我想知道同样的策略是否应该适用于 redis 和 elasticsearch。我的理解是，这两个应用程序都可能带来相当大的开销。因此，运行多个实例似乎效率低下。

标签： linuxdockerelasticsearchredis

Answer 1

这是一个有趣的问题，但我不确定是否有一个普遍的答案。这主要取决于您的情况。

但是，如果您将一个独特的容器用于多个应用程序，则必须了解其优点和缺点。例如，假设您只有 2 个应用程序容器：A和B，以及一个共享的DB容器，无论其背后的技术是什么。

优点

• 资源使用是有限的。尽管如此，正如您在问题中所说，如果数据库容器开销不是那么重要，那么它并不是真正的优势

缺点

如果A和B是独立的应用程序，那么共享DB的主要缺点是您打破了这种独立性并通过DB紧密耦合您的应用程序：

• 您不能独立更新数据库容器。需要为两个应用程序对齐DB版本。如果A需要新版本的DB（例如需要新功能），则必须升级DB ，可能会破坏B
• A和B的DB配置不能不同：如果A发出的写入多于读取，并且B正在密集读取数据，那么您可能找不到适合这两种用法的完美配置
• DB崩溃对两个应用程序都有影响：A甚至可以通过使DB崩溃来使B崩溃
• 安全问题：即使A和B在DB中有单独的数据库实例，A也可能访问B数据库实例，除非您设置不同的访问/角色；每个应用程序拥有一个容器可能更容易，并且如果它们在同一个网络上，则不必担心访问（当然，如果无法从外部访问DB ）
• 您必须将A、B和DB服务放在同一个 docker-compose 文件中

结论

如果A和B已经是紧密耦合的应用程序，那么您可能会选择 1 DB。如果资源不多，也可以共享DB。但是不要忘记，通过这样做，您可以耦合您的应用程序，而这可能是您不想要的。否则，最干净的解决方案是为每个应用程序使用 1 个DB 。