Запускаем PostgreSQL в Docker: от простого к сложному

Я не уверен на счет использования бд в контейнере на проде, но контейнеризация бд очень удобна во время разработки. В частности, можно сделать образы баз с уже заполненными тестовыми данными и не стесняясь - ломать их (потому что развернуть контейнер снова - быстрее чем заполнять базу из csv или какими бы то небыло скриптами.) Или например после тестирования автоматически удалять контейнеры и так далее.

Абсолютно поддерживаю: зачем вообще запускать RDBMS в контейнерах, ведь единственное что можно получить - снижение производительности и падение fault tolerance?! Сколько раз приходилось сталкиваться с ситуацией, когда кто-то запускал RDBMS в каких-нибудь условных кубах, и потом жаловался, что приложение (использующее базу) работает очень медленно и нестабильно, посколько время выполнения SQL-запросов падает даже не в разы, а на порядок-два

Удивительно, что не видать нигде ни в открытом доступе, ни в виде коммерческого решения связи из какой-нибудь хорошей RDBMS вроде Postgres и DPDK (Home - DPDK), чтобы запускать базу сразу на нативном сетевом интерфейсе без огромного оверхеда на TCP/IP-стек ядра и тонны системных вызовов с переключением контекстов - на основе так называемого Poll Mode Driver

@Hivemaster

На самом деле здесь нет правильного ответа. И категорично что-то утверждать будет неправильно. Как и всегда, всё зависит от вашей специфики и нагрузки.

Если у вас большая нагруженная БД, то тащить её в контейнер не очень разумно.

Если у вас микросервисы и вам требуется небольшая БД на 5-10 TPS, то почему нет?

У меня нет готового примера/кусочка кода, который можно было бы показать, но себя в Kubernetes/OpenShift мы используем следующий подход:
1) в deployment добавляем соответствующий init-container, в котором дожидаемся доступности БД (цикл, ограниченный по времени и числу итераций);
2) в readiness пробе проверяем доступность БД (select 1, например).

Сначала стартует init-контейнер и проверяет доступна ли БД, если нет то уходит в ожидание на какое-то время, после чего снова повторяет проверку. И так несколько раз (все параметры настраиваются).

Затем уже приложение у себя в readiness пробе проверяет доступность БД (перестраховка по сути, можно отказаться от этого).

Можно делать зависимые сервисы в докер комповз. Это как пример из многих.

version: '3.5'

services:
  cnm:
    image: cnm:latest
    depends_on:
      - kafka
      - cnm-redis

  zookeeper:
    image: zookeeper

  kafka:
    image: kafka
    depends_on:
      - zookeeper

  cnm-redis:
    image: redis

Вы так говорите, будто разные юзеры с разными правами, это что-то сложное или плохое.

Можно поднять еще один кластер postgres, возможно даже другой версии, если требуется

Использую майскл на проде в докере. После перезагрузки vps сервера база умерла. не разбирался с причиной, просто восстановил из полного ежедневного архива. База маленькая и пополняется не очень часто. База в докере - это возможность держать несколько проектов на одном вэпээс сервере, мне очень нравится такой подход. В случае большой базы, да можно подумать прежде чем так делать.

Согласен, что такой подход получается многословным, но он наглядный. Для учебных целей подходит гораздо лучше.

С другого хоста нет разницы докеризирован постгри или нет, подключаешься как обычно к базе, по айпи:порту (настраивай файервол, если нужно)

С того же самого хоста, автор в тексте привёл пример с pgAdmin, используй networks:

Рабочий пример

https://gist.github.com/MauricioMoraes/87d76577babd4e084cba70f63c04b07d?permalink_comment_id=4337127#gistcomment-4337127

В общем разобрался сам:

    volumes:
      - ./postgresql.conf:/var/lib/postgresql/data/postgresql.conf