Следует ли вам создавать отдельные Docker-контейнеры для сервисов, таких как Redis и Elastic Search, когда они используются более чем одним сервисом?

Question

У меня есть весь стек в настройке контейнера докера.В настоящее время загрузка такова, что она может работать на одном экземпляре.У меня есть два отдельных приложения, и они оба используют Redis и эластичный поиск.

Я видел людей, которые предполагали, что в таких случаях, как MySQL, правильная теория контейнеров предполагает, что у вас должно быть два отдельных контейнера для двух отдельных баз данных, если у вас есть два отдельных приложения, использующих их.

Что, на мой взгляд, подходит для MySQL, потому что, насколько я понимаю, отдельные экземпляры MySQL на самом деле не увеличивают нагрузку на память или процессор.

Мне интересно, должна ли эта же стратегия применяться к redis иasticsearch.Насколько я понимаю, оба этих приложения могут иметь значительные накладные расходы.Таким образом, кажется, что может быть неэффективно запускать более одного их экземпляра.

Answer 1

Это интересный вопрос, но я не уверен, что есть универсальный ответ на это.Это в основном зависит от вашей ситуации.

Однако, есть преимущества и недостатки, которые вы должны знать, если вы используете уникальный контейнер для нескольких приложений.В качестве примера, скажем, у вас есть только 2 контейнера приложений: A и B , а также общий контейнер DB , независимо от технологии.

Преимущества

• использование ресурсов ограничено.Тем не менее, как вы заявляете в своем вопросе, если DB издержки контейнера не так важны, то это не является действительно преимуществом

Недостатки

Если A и B являются независимыми приложениями, поэтому основным недостатком совместного использования DB является то, что вы нарушаете эту независимость и плотно связываете свои приложения с помощью DB :

• вы не можете самостоятельно обновлять контейнер DB .Версия DB должна быть согласована для обоих приложений.Если для A требуется новая версия DB (например, необходимы новые функции), то DB необходимо обновить, что может привести к поломке B
• конфигурация DB не может отличаться для A и B : если A выдает больше записей, чем прочитано, иесли B интенсивно читает данные, то вы, вероятно, не найдете идеальную конфигурацию для обоих случаев.
• сбой DB повлияет на оба приложения: A может даже аварийно завершить работу B из-за сбоя DB
• из соображений безопасности: даже если A и B имеютотдельные экземпляры базы данных в DB , A могут иметь доступ к B экземпляру базы данных, если вы не настраиваете другой доступ / роли;здесь, вероятно, проще иметь по одному контейнеру на приложение и не беспокоиться о доступе, если они находятся в одной сети (и, конечно, если к DB нельзя получить доступ извне)
• вы должны поместить службы A , B и DB в один и тот же файл docker-compose

Заключение

Если A и B уже тесно связаны между собой, то вы, вероятно, можете выбрать 1 DB .Если у вас мало ресурсов, вы также можете поделиться DB .Но не забывайте, что, делая это, вы объединяете свои приложения, которые, вероятно, вам не нужны.В противном случае самое чистое решение - 1 DB на приложение.

Answer 2

Основное преимущество, которое я вижу от наличия всех связанных сервисов в стеке компоновки Docker, заключается в том, что Docker затем гарантирует, что все необходимые сервисы работают.Однако с такими сервисами, как redis иastic, можно установить их автономно, а приложение просто указывает на них через переменные среды, передаваемые в файл компоновки docker.

например,

 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-адрес в правильном направлении.