Comments 39
Скорее docker туториал на примере postgresql.
Спасибо за материал, очень полезно!
А здесь DBA и контрибьютор постгреса пишет, что контейнеризация СУБД - это плохая идея. Что на это скажите?
Я не уверен на счет использования бд в контейнере на проде, но контейнеризация бд очень удобна во время разработки. В частности, можно сделать образы баз с уже заполненными тестовыми данными и не стесняясь - ломать их (потому что развернуть контейнер снова - быстрее чем заполнять базу из csv или какими бы то небыло скриптами.) Или например после тестирования автоматически удалять контейнеры и так далее.
Вот именно.
В статье вроде и указано, что для дев или тест.
И да, на мой взгляд, для разработки и тестов контейнеры божественны. В проде иногда тоже использую, но не для СУБД.
Я плотно использовал БД на проде в docker контейнерах, правда mysql и mongodb. Проблем вообще нет, полет нормальный. Да, есть небольшие отличия от простой установки, но если знать основные команды работы с docker, привыкаешь и через неделю забываешь обо всех отличиях. Спасибо за статью!
Могу подтвердить так как испольшовнаие ктнтейнера на проде привело один раз к разрушению базы данных, после этого больше нет желания повторить опыт.
А можете поподробнее? В статье указано, что файлы самой бд пишутся в расшаренные папки. Ну допустим бд упала. Что мешает поднять заново контейнер и приатачить эти же папки туда? Спрашиваю потому что сам использую бд, да и вообще все сервисы в докерах на пет проектах и инцидентов пока не было. Но я разработчик, а не DBA и мне просто любопытно
У нас был жёсткий human error: надо было создать ещё одну базу на Postgres. Решили поднять ещё один инстанс (это же docker, новая БД должна была быть маленькой и нетребовательной к ресурсам, типа docker-way), а не просто создать новую БД в существующем СУБД (как бы мы сделали на StanAlone), И один человек увлёкся копипастом в docker-compose и замонтировал один и тот же volume и на новую БД, и на старую. И обе БД в итоге пострадали.
Поэтому надо быть осторожнее.
Абсолютно поддерживаю: зачем вообще запускать RDBMS в контейнерах, ведь единственное что можно получить - снижение производительности и падение fault tolerance?! Сколько раз приходилось сталкиваться с ситуацией, когда кто-то запускал RDBMS в каких-нибудь условных кубах, и потом жаловался, что приложение (использующее базу) работает очень медленно и нестабильно, посколько время выполнения SQL-запросов падает даже не в разы, а на порядок-два
Удивительно, что не видать нигде ни в открытом доступе, ни в виде коммерческого решения связи из какой-нибудь хорошей RDBMS вроде Postgres и DPDK (Home - DPDK), чтобы запускать базу сразу на нативном сетевом интерфейсе без огромного оверхеда на TCP/IP-стек ядра и тонны системных вызовов с переключением контекстов - на основе так называемого Poll Mode Driver
Откуда вы это берёте? В кубах на СУБД не используются PVC и Ceph. Волюмы пробрасывают на хосты. Получаются отличные HA FT кластера СУБД с быстрой автоматической раскаткой.
С 2016 года использую разные СУБД в докере и кубере, все отказы которые встречали - никак не были связаны с докером. Не было и нету никаких оверхедов (я готов не считать до 3% на оверхед, за такие удобства) при нормальной настройке кластеров / хостов.
На самом деле здесь нет правильного ответа. И категорично что-то утверждать будет неправильно. Как и всегда, всё зависит от вашей специфики и нагрузки.
Если у вас большая нагруженная БД, то тащить её в контейнер не очень разумно.
Если у вас микросервисы и вам требуется небольшая БД на 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
Почитал ответ dba постгреса про минусы контейнеризации бд в проде. Но что делать, если на одной машине надо запустить несколько проектов с несколькими бд? В одном постгресе создавать несколько баз с разными юзерами и правами?
Вообще вопрос "почему докеризация бд в проде - плохая идея" сидел в голове, но пока я на практике не дошел до решения этого вопроса, то и не гуглил, так что спасибо за комменты выше
Вы так говорите, будто разные юзеры с разными правами, это что-то сложное или плохое.
Для полноты картины (я не девопс) - изучаю для себя деплой двух разных пет проектов на сервере хетцнера через ansible и автоматизировать добавление новых контейнеров с новой бд мне пока видится легче, чем автоматизировать добавление новых бд и юзеров
добавление БД и юзера это 3-4 консольных команд
https://www.a2hosting.com/kb/developer-corner/postgresql/managing-postgresql-databases-and-users-from-the-command-line
и еще одна, чтобы залить схему или дамп в эту БД.
Можно поднять еще один кластер postgres, возможно даже другой версии, если требуется
Использую майскл на проде в докере. После перезагрузки vps сервера база умерла. не разбирался с причиной, просто восстановил из полного ежедневного архива. База маленькая и пополняется не очень часто. База в докере - это возможность держать несколько проектов на одном вэпээс сервере, мне очень нравится такой подход. В случае большой базы, да можно подумать прежде чем так делать.
Спасибо за статью. Но хочется ещё пример с добавление реплики
В качестве игрушки пойдет. Но не более. Регресс тестирование тоже на контейнерах проводите?
А можете сказать, почему не лучше замонтировать postgres.conf внутрь контейнера, чем городить такую "простыню" в docker-compose с передачей опций запуска БД (-c)?
Размещение СУБД вне контейнера представляется разумным, но вот как теперь "достучаться" до этой СУБД из приложения, запущенного в контейнере? интересны варианты как для СУБД, запущенной на том же хосте, что и Docker, так и на другом хосте... В документации и Инете прямых ответов пока не нашел, хотя данный кейс представляется очень актуальным...
Подскажите нубу, пожалуйста.
Блин))
Когда искал кок раз таки, как настроить конфиг и засунут в контейнер, а тут пишут "Оставлю это в качестве домашнего задания"
Разумеется, можно указать свой postgresql.conf. Оставлю это в качестве домашнего задания.
Когда открыл статью только ради того, чтобы посмотреть пример проброски конфига...
На этапе инициализации указываю директорию с файлами .sql где создаются нужные таблицы, но наблюдаю ошибки Error response from daemon '/Users/user/Desktop/projects/horses/horsebot/table/init': mkdir /Users: file exists.
Хелп
Запускаем PostgreSQL в Docker: от простого к сложному