Should you create separate docker containers for services like redis and elastic search when they are being used by more than one other service?

user_10824404 0
Viewed 981

I have my entire stack in a docker compose container setup. Currently, load is such that it can all run on a single instance. I have two separate applications and they both use redis and elastic search.

I have seen people suggesting that in cases like MySQL, proper container theory suggests that you should have two separate containers for two separate databases, if you have two separate applications using them.

Which I think is fine for MySQL because my understanding is that separate instances of MySQL doesnt really add much memory or processor overhead.

I'm wondering if this same strategy should apply to redis and elasticsearch. My understanding is that both of these applications can come with considerable overhead. So it seems like it might be inefficient to run more than one instance of them.

elasticsearch docker redis linux
2 Answers

It's an interesting question, but I'm not sure there is an universal answer to this. It mostly depends on your situation.

However, there are advantages and drawbacks you must know if you are using a unique container for multiple applications. As an example, let's say you have only 2 applications containers : A and B, and a shared DB container, whatever the technology behind.

Advantages

  • resource usage is limited. Nonetheless, as you states in your question, if DB container overhead is not that important, then it's not really an advantage

Drawbacks

If A and B are independent applications, then the main disadvantage by sharing DB is that you break that independency and tightly couple your applications via DB :

  • you cannot update independently the DB container. Version of DB needs to be aligned for both applications. If A requires a new version of DB (new features needed for example), then DB must be upgraded, potentially breaking B
  • configuration of DB cannot be different for A and B : if A is issuing more writes than read, and if B is intensively reading data, then you probably won't find a perfect configuration for both usages
  • crash of DB have impacts on both applications : A could even crash B by crashing DB
  • security concerns : even if A and B have separate database instances in the DB, A could possibly access B database instance, unless you're setting up different access/roles; it's probably easier here to have one container per application, and don't worry about access if they are on the same network (and if DB cannot be accessed from outside, of course)
  • you have to put A, B and DB services inside the same docker-compose file

Conclusion

If A and B are already tightly coupled apps, then you can probably go for 1 DB. If you don't have many resources, you can also share DB. But don't forget that by doing this, you couple your apps, which you probably doesn't want. Otherwise, the cleanest solution is to go for 1 DB per application.

user_78040580

The main benefit I see which comes from having all linked services in the docker compose stack is that docker will then ensure that all required services are up. However with services like redis and elastic it is fine to have them installed stand-alone with the application just pointing to them via environment variables passed in the docker compose file.

e.g.

 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

In the future if you decide you want to have these services hosted, for example, you just need to point the URL in the right direction.

user_58664470
Related