По каким причинам Docker не следует использовать для баз данных?

У меня с другом обсуждается вариант использования Docker . Один парень в команде хочет использовать Docker для всего - как некая универсальная оболочка процесса Unix. Другой считает, что Docker следует использовать только для приложений без сохранения состояния, таких как микросервисы и приложения в стиле AWS Lambda .

Мы разработали доказательство концепций для обоих. В нашем докерном кластере у нас есть общий диск, который монтируется при монтировании хоста Docker, и если база данных в контейнере монтируется, он просто подключает том к общему диску.

Мой друг все еще придерживается своей позиции, несмотря на то, что ему показали противоположные доказательства. (Он также утверждает, что Docker добавляет ненужный риск, добавляя сложность в стек.)

Я пытаюсь выслушать и понять его точку зрения, как в акте эмпатии, так и в лучшем рассуждении с ним. (Мы все хорошо ладим, так что это смесь шутки и серьезного обсуждения).

Вид вопроса, который стоит за вопросом: являются ли базы данных скотом ? Этот комментарий предполагает, что хорошая стратегия автоматического резервного копирования и поиска для вашей базы данных неотличима от сервера крупного рогатого скота.

Мой вопрос: по каким причинам Docker не следует использовать для баз данных?

РЕДАКТИРОВАТЬ: Люди просили меня уточнить мою терминологию. Я предполагал, что приложение базы данных было в контейнере, а хранилище было в томе. Я имел в виду, что СУБД находится в контейнере, а хранилище базы данных - в томе.

Некоторые комментаторы полагают, что драйверы томов Docker не очень хорошо работают с записями в базе данных. (Или что-то в этом роде). Не могли бы вы рассказать об этом подробнее?

Когда люди говорят о запуске базы данных в Docker, они не имеют в виду хранить данные в контейнере; они говорят о том, чтобы иметь образ докера с программным обеспечением БД и монтировать данные в виде тома (том связывания, а не том контейнера).

Тома являются неотъемлемой частью Docker и не являются чем-то ненадежным или просто привязанным. Докер предназначен не только для (микро) услуг без гражданства.

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

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

• Упаковка самого программного обеспечения БД в контейнер дает вам обычные преимущества - везде одинаковая версия, избегая проблем с зависимостями / общей библиотекой, возможность раскручивать одну и ту же БД на ноутбуках разработчиков или там, где вам это нужно.
• Это несложно заставить его работать в любом месте; обновление тривиально и тд. Применяются все преимущества Docker. На Dockerhub есть образ Oracle, который позволяет вам раскрутить рабочую БД за минуту или три (и, конечно же, для остальных).
• Люди делали тесты производительности и не обнаружили различий ввода-вывода между томами и «голым металлом» ( https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/ , https: // stackoverflow .com / questions / 21889053 / контейнер "что такое скорость выполнения, производительность, стоимость докера" ).
• Под капотом все равно, что Docker каким-то образом не перехватывает все операции ввода-вывода. Он просто проявляет творческий подход со стандартными инструментами Linux (в этом случае bind mounts, искажение внутренних таблиц ядра, которые вообще делают возможной Docker-fu).
• Очевидно, это не означает, что вы можете запустить два экземпляра БД и просто заставить их работать с одними и теми же файлами, но никто не подразумевает этого. Docker не предоставляет вам автоматический одновременный и магически беспроблемный доступ к томам и никогда не претендовал на это. Остальные преимущества по-прежнему применяются. Если ваша БД сама по себе не обнаруживает конфликты, подобные этому, вам лучше добавить в образ сценарий CMD, который отказывается раскручивать второй контейнер, когда том уже используется.
• Вы должны быть немного более осторожны, раскручивая / закрывая контейнер (точно так же, как если бы вы не просто выключали сервер БД на «голом железе»), но это должно быть вполне управляемым.

Теперь, в зависимости от обстоятельств, могут быть мягкие причины не делать этого:

• Например, Oracle (компания), безусловно, не поддержит вас, если вы запустите их RDBMS в контейнере Docker. Но, возможно, вы используете докернизированные образы СУБД Oracle только для своих разработчиков и среды тестирования, где вам не понадобится их поддержка в любом случае, зарезервировав ее для чистого производственного сервера. (Но не забудьте оплатить свои лицензии ...).
• Если оперативники незнакомы с Docker, может быть, будет немного проще случайно все убить, уничтожить ваши файлы данных и т.д ..
• Если у вас есть большая выделенный металл DB машина уже с большим количеством очень быстро , посвященные хранений SAN, и не работают ничего другого в любом случае, то не было бы просто смысла в использовании Docker контейнеризации тех , как вы никогда и не только спину другого сервера, когда есть 100 ГБ или даже ТБ данных. В конце концов, для производства СУБД, такая как Oracle, очень, очень продвинута во всех аспектах репликации, целостности данных, отказоустойчивости при отказе и т. Д. Обратите внимание, что этот аргумент просто говорит: «Вам не нужно контейнировать свою СУБД». Он не говорит «вы не должны этого делать» - возможно, вы хотите сделать это, потому что вы хотите развертывать обновления баз данных через контейнеры или по любой другой причине, которую вы можете себе представить.

Итак, поехали. Во что бы то ни стало , докеризируйте вашу БД, по крайней мере, для ваших разработчиков (которые будут вечно благодарны) и ваших сред тестирования. На производстве, он сойдет на вкус, и там , по крайней мере, я бы тоже предпочел решение , которое сидит лучше со специализированным DBA / Ops - если они имеют многолетний опыт работы голого металл DB серверов, то все средства доверять им продолжать так. Но если вы являетесь стартапом, у которого в любом случае есть все ИТ-ресурсы в облаке, то контейнер Docker станет еще одним кусочком лука во всей картине.

Я написал об этом подробно, но вот резюме:

• Предотвращение разделения мозга (выбор более чем одного главного узла) должно быть решено. Невыполнение этого требования может привести к катастрофическим последствиям.

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

Когда вы говорите, что данные смонтированы в Docker-контейнере, не будет ли правильнее сказать, что «база данных» смонтирована в Docker-контейнере? Если вы сохраняете свои данные вне контейнера, тогда вы делаете «правильную» вещь, не помещая свою базу данных в контейнер.

Конечно, отправляйтесь в город, чтобы поместить СУБД в контейнер и позволить ей управлять данными, которые вы храните снаружи. Лично я считаю, что это просто хороший дизайн, поскольку он четко разделяет логику и данные. Но как только вы помещаете свои данные в контейнер, вы потенциально играете с огнем.

Хотя драйверы хранилища контейнеров прошли долгий путь, я лично пока не хочу погружаться и оставлять свои данные запутанными в контейнере.