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

Question

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

我看到有人建议，在像 MySQL 这样的情况下，正确的容器理论表明，如果您有两个单独的应用程序使用它们，则应该为两个单独的数据库准备两个单独的容器。

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

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

Answer 1

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

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

优势

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

缺点

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

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

结论

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