Запускать базу данных как контейнер Docker или на голом металлическом сервере?
Базы данных предназначены для использования всей памяти, процессора и ввода-вывода, доступных для них. Есть ли хорошие / плохие причины, по которым Docker не следует использовать для рабочих баз данных?
Может быть, этот вопрос относится к другим инструментам, таким как MOM Apache Kafka, Apache ActiveMQ и т. Д.
2 ответа
Docker - это не полноразмерная виртуальная машина (по крайней мере, при запуске в Linux), это просто еще один процесс, работающий на том же ядре, что и хост-машина. Более того, все docker Контейнерные процессы можно увидеть на хост-машине с ps aux,
Единственная дополнительная нагрузка Docker дает загрузка другой ОС поверх вашего ядра, но на самом деле большинство контейнеров развернуто с очень легкими вещами, такими как alpine Linux, так что я не думаю, что это действительно нужно принимать во внимание.
С другой стороны, наличие базы данных (или любой другой службы с высокой нагрузкой) в контейнерах дает вам следующие преимущества:
- Масштабирование (контейнеры можно легко распределить между узлами с помощью инструментов оркестровки контейнеров, таких как
k8s) - Простота развертывания (все зависимости внутри)
- Простое обновление (просто замените контейнер)
- Простое тестирование (нет необходимости в процедурах очистки базы данных перед запуском тестов) и другие
Поэтому развертывание контейнерных сервисов сегодня - правильная практика.
Контейнеры предназначены для того, чтобы иметь возможность регулировать использование ресурсов с помощью cgroups, и поэтому, пока мы можем прогнозировать использование, у нас не должно быть проблем (с производительностью) при запуске его в контейнере. Однако есть и другие соображения, помимо использования ресурсов.
В такой архитектуре, как Kubernetes, становится сложнее управлять развертыванием баз данных, отчасти потому, что контейнеры теперь эфемерны. Если модуль выходит из строя на данном узле, нет никакой гарантии, что он будет восстановлен на том же узле, и поэтому необходимо учитывать особые соображения для приложений с состоянием (модуль должен быть подключен к тому же объему при повторном запуске и т. Д.), Вот где приходят такие конструкции, как StatefulSets. Итак, это работает, и решения и очень хорошо продуманы, но есть еще несколько рабочих циклов, через которые нужно перейти.
Существуют также такие вещи, как операторы, которые могут справляться со сложными потребностями при запуске и управлении приложением с состоянием, таким как база данных или распределенная очередь сообщений. Эти проекты иногда могут быть довольно зелеными, но есть много поведения, которое было бы сложно организовать на голом металле, которое мы получили прямо из коробки.
Более или менее, в конце концов, работает с сохранением состояния приложений, такими как базы данные или очереди сообщений на Kubernetes (или другого контейнер оркестраторах) является спорным вопросом. Как и все проектные решения, существуют компромиссы с отказоустойчивостью, сложностью и отладкой. Многие крупные компании делают это на производстве, так что это ни в коем случае не является необоснованным.