Какова наилучшая практика для обмена базами данных между контейнерами в докере?

Кто-нибудь знает, какая наилучшая практика для обмена базами данных между контейнерами в докере?

Я хочу создать несколько контейнеров в докере. Затем эти контейнеры будут выполнять CRUD в той же базе данных с одинаковым идентификатором.

Пока у меня есть две идеи. Один из них создает отдельный контейнер для простого запуска базы данных. Другой - это установить базу данных непосредственно на хост-машине, где установлен докер.

Какой из них лучше? Или, есть ли другая лучшая практика для этого требования?

Спасибо

Ответ 1

Трудно ответить на вопрос "лучшей практики", потому что это вопрос мнения. И мнения не в тему о переполнении стека.

Поэтому я приведу конкретный пример того, что я сделал в серьезном развертывании.

Я запускаю ELK (Elasticsearch, Logstash, Kibana). Он контейнер.

Для моих хранилищ данных у меня есть контейнеры для хранения. Эти контейнеры хранения содержат локальную файловую систему:

docker create -v /elasticsearch_data:/elasticsearch_data --name ${HOST}-es-data base_image /bin/true

Я также использую etcd и confd, чтобы динамически перенастроить мои службы, указывающие на базы данных. etcd позволяет хранить ключевые значения, поэтому на упрощенном уровне:

CONTAINER_ID=`docker run -d --volumes-from ${HOST}-es-data elasticsearch-thing`
ES_IP=`docker inspect $CONTAINER_ID | jq -r .[0].NetworkSettings.Networks.dockernet.IPAddress`
etcdctl set /mynet/elasticsearch/${HOST}-es-0

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

Я использую haproxy для этого иногда, и nginx, когда мне нужно что-то более сложное. Оба они позволяют вам указать наборы хостов для "отправки" трафика и иметь некоторые основные механизмы доступности/нагрузки.

Это означает, что я могу быть довольно ленив о перезапуске/перемещении/добавлении узлов elasticsearch, потому что процесс регистрации обновляет всю среду. Механизм, подобный этому, используется для openshift.

Чтобы конкретно ответить на ваш вопрос:

DB упаковывается в контейнер, по тем же причинам другие элементы.
Объемы для хранилища БД - это контейнеры для хранения, проходящие через локальные файловые системы.
"поиск" базы данных выполняется с помощью etcd на родительском хосте, но в остальном я минимизировал свой размер установки. (У меня есть общий шаблон "install" для хостов докеров, и старайтесь не добавлять к нему что-либо дополнительное, когда это возможно).

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

(Приведенный выше пример - я буквально перестроил все это за 10 минут, и большинство из них было docker pull, переносящим изображения)

Ответ 2

Это зависит. Полезная вещь - сохранить URL-адрес базы данных и пароль в переменной среды и предоставить Docker при запуске контейнеров. Таким образом, вы сможете свободно подключаться к базе данных, где бы она ни находилась. Например. работающий в контейнере во время тестирования и на выделенном сервере в процессе производства.

Ответ 3

Лучшей практикой является использование докеровских томов.

Официальный документ: управление данными в контейнерах. В этом документе подробно описывается, как обращаться с БД и контейнером. Обычный способ сделать это заключается в том, чтобы поместить БД в контейнер (который фактически не является контейнером, а томом), тогда другие контейнеры могут получить доступ к этому контейнеру DB (тому) к CRUD (или более) данным.

Случайная статья "Объяснение объемов докеров"

изменить. Я не буду подробно останавливаться на другом ответе.