Я могу понять преимущества поддержки докетирования служб без состояния, таких как веб-серверы, серверы приложений, балансировки нагрузки и т.д. Если вы используете эти службы на кластере машин, очень легко перемещать эти контейнеры с низким накладные расходы. Что я не понимаю, но является ли целью контейнеризации баз данных? базы данных подключаются к тому данных, который является постоянным на конкретном жестком диске. Из-за состояния это непросто и неэффективно фактически перемещать контейнер базы данных. Так может ли кто-нибудь понять, почему приклеивание базы данных может быть полезно вообще?
Имеет ли смысл докерезировать (контейнеризовать) базы данных?
Ответ 1
"И может ли кто-нибудь понять, почему докинг-базы данных могут быть полезны вообще?"
Хороший вопрос Кито. Одной из основных причин контейнеризации ваших баз данных является то, что вы можете иметь одну и ту же согласованную среду для всего приложения, а не только части без гражданства, через dev, постановку и производство. Согласованная среда является одним из promises докеров, но когда ваша база данных живет за пределами этой модели, существует большая разница, которая не может быть учтена при тестировании. Кроме того, путем контейнеризации вашей базы данных, а также остальной части вашего приложения, вы, скорее всего, сможете перемещать все ваше приложение между хостинг-провайдерами (скажем, от AWS до Google Compute). Если вы используете Amazon RDS, например, даже если вы можете переместить свои веб-узлы в Google, вы не сможете переместить свою базу данных, а это значит, что вы сильно зависите от своего поставщика облачных вычислений.
Еще одна причина для контейнерных услуг передачи данных - производительность. Это особенно справедливо для поставщиков услуг (все базы данных как предложения услуг, например облачные базы данных rackspace - работают в контейнерах), поскольку контейнеры позволяют предоставлять гарантии обслуживания, которые возможно использование виртуализации, и запуск одной базы данных на физическую машину не является финансово жизнеспособным. Скорее всего, вы не используете службу хостинга баз данных, но эта аналогия имеет схожесть, если вы работаете на голом металле и хотите использовать контейнеры для изоляции процессов вместо виртуальных машин. Вы получите более высокую производительность для своих баз данных из-за известного эффекта ввода-вывода, который вы используете при работе db в виртуальной машине.
Я не говорю, что вы должны контейнеризировать свою базу данных, но это некоторые из причин, почему это имеет смысл.
Полное раскрытие, я работаю в clusterhq, этот новый проект, о котором упоминал Марк О'коннор в своем ответе. У нас есть проект с открытым исходным кодом Flocker, который упрощает миграцию баз данных и их томов между хостами, поэтому преимущества, о которых я говорил выше, не полностью перевешиваются негативами, которые вы подняли в своем вопросе.
Ответ 2
Не уверен, что я согласен с вашим комментарием об эффективности... Намного проще загружать и запускать контейнер базы данных по сравнению с его установкой. Документация docker описывает, как реализовать чистое логическое разделение между контейнером с состоянием и его данными:
Но... вы правы, что контейнер с сохранением состояния будет привязан к нему хост-сервером, если только не существует механизма для переноса данных вокруг.
Одним из очевидных решений является монтирование общего тома хранилища на всех хостах, на которых может работать ваша база данных.
В следующей статье обсуждается очень инновационное решение, в котором клиент с биторрентом используется для репликации контейнера данных между хостами.
Наконец, новый проект flocker пытается решить эту проблему, управляя контейнерами с сохранением состояния и связанными с ними томами ZFS:
Ответ 3
Это хороший поток, и недавний прогресс в клонировании SQL Server добавит дополнительные возможности для использования Контейнеров с клонами. Это решает некоторые проблемы работы с большими наборами данных. Полное раскрытие, я работаю для Windocks, где мы выпустили 2.0 с контейнерами SQL Server со встроенным клонированием базы данных.