当多个其他服务正在使用Redis和Elastic Search之类的服务时，是否应该为它们创建单独的Docker容器？

Question

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

我见过有人建议，在类似MySQL的情况下，正确的容器理论建议，如果您有两个使用它们的独立应用程序，则应该为两个独立的数据库拥有两个独立的容器。

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

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

Answer 1

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

但是，如果您将唯一的容器用于多个应用程序，则必须了解其优缺点。 举个例子，假设您只有两个应用程序容器： A和B ，以及一个共享的DB容器，无论使用哪种技术。

好处

• 资源使用受到限制。 但是，正如您在问题中指出的那样，如果数据库容器开销不是那么重要，那么这并不是真正的优势。

缺点

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

• 您不能独立更新数据库容器。 需要针对两个应用程序调整数据库版本。 如果A需要新版本的DB （例如，需要新功能），则必须升级DB ，从而可能破坏B
• 对于A和B ， DB的配置不能不同：如果A发出的写操作多于读取的操作，并且如果B密集地读取数据，那么您可能找不到两种用法的理想配置
• 数据库崩溃对两个应用程序都有影响： A甚至可能通过使数据库崩溃而崩溃B
• 安全问题：即使A和B具有在数据库单独的数据库实例中，可能可能进入菜单B数据库实例，除非您设置不同的访问/角色; 在这里，每个应用程序只有一个容器可能更容易，并且如果它们位于同一网络中，也不必担心访问（当然，如果不能从外部访问数据库 ）
• 您必须将A ， B和DB服务放在同一个docker-compose文件中

结论

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

Answer 2

我看到的主要好处是，泊坞窗组成堆栈中具有所有链接的服务，然后泊坞窗将确保所有必需的服务正常运行。 但是，使用redis和elastic之类的服务时，最好将它们与应用程序一起独立安装，仅通过泊坞窗组成文件中传递的环境变量指向它们。

例如

 myapp:
    image: myawesomerepo/myapp:latest
    depends_on:
     - someother_svc_in_same_docker_compose
    environment:
      - DB_HOST=172.17.2.73
      - REDIS_HOST=172.17.2.103
      - APP_ENV=QA
      - APM_ENABLE=false
      - APM_URL=http://172.17.2.103:8200
      - CC_HOST=cc-3102
    volumes:
      - /opt/deploy/cc/config:/server/app/config
      - /opt/deploy/cc/slogs:/server/app/logs
    command: node ./app/scheduler/app.js

例如，将来如果您决定要托管这些服务，则只需将URL指向正确的方向即可。