Архитектура сервера многозадачных приложений Docker в отношении базы данных

У меня есть сервер с 5 или 6 небольшими приложениями Rails. Все их прикрепленные файлы находятся на S3, и все они используют MySQL в качестве базы данных. Каждое приложение имеет своего собственного пользователя и выполняет некоторые тонкости. Существует сервер nginx, выполняющий балансировку нагрузки и маршрутизацию домена.

Я планирую заменить этот сервер установкой Docker: один сервер с одним контейнером для каждого приложения, с nginx спереди.

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

В основном я вижу 4 возможности:

1) Один сервер Mysql внутри каждого контейнера приложения. Думаю, это швы не являются философией докеров. Это потребует, чтобы каждая информация контейнера была подкреплена индивидуально.

2) Уникальный контейнер MySQL для всех приложений.

3) Стандартная установка MySQL на сервере-докере хоста.

4) Отдельный сервер MySQL для всех приложений.

Что бы вы сделали?

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

Ответ 1

Это зависит от нескольких факторов. Вот несколько вопросов, которые помогут вам решить.

Являются ли приложения с 5-6 очень похожими (то есть, в терминах Docker, вы можете основывать их на общем изображении), и вы думаете о развертывании большего количества из них и/или переносе некоторых из них на другие серверы?
- ДА: тогда имеет смысл встраивать сервер MySQL в каждое приложение, потому что оно будет "придерживаться" с помощью приложения с минимальным усилием настройки.
- НЕТ: тогда нет веских причин для внедрения сервера MySQL.
Вы хотите иметь возможность масштабировать эти приложения (например, запросы баланса нагрузки для одного приложения в нескольких контейнерах) или масштабировать сервер MySQL (например, реплицированную настройку ведущего/ведомого)?
- ДА: тогда вы не можете встроить сервер MySQL, иначе масштабирование одного уровня будет масштабировать другой уровень, что приведет к головным болям.
- НЕТ: ничто не мешает вам встраивать сервер MySQL.
Как вы думаете, будет ли значительная загрузка базы данных хотя бы одним из этих приложений?
- ДА: тогда вы можете использовать отдельные серверы MySQL, потому что одно приложение может помешать другим.
- НЕТ: тогда вы можете использовать один сервер MySQL.

Встраивание сервера MySQL в норму, если вы хотите установить супер-простое развертывание, где вам не нужна масштабируемость, но вы хотите легко развернуть новые экземпляры, и вы хотите быть в состоянии для беспрепятственного перемещения экземпляров.

Самая гибкая настройка - это та, где вы развертываете один контейнер приложения + один контейнер MySQL для каждого приложения. Если вы хотите это сделать, я бы предложил дождаться Docker 0.7, который будет реализовывать ссылки, что позволит вам создать базовый механизм обнаружения сервисов, чтобы каждый контейнер приложения мог легко обнаружить хост/порт своего контейнера базы данных.

Я бы не размещал MySQL на хосте; если вы хотите установить одну MySQL, вы можете добиться того же результата, запустив один контейнер MySQL и запустив его с помощью -p 3306:3306 (он будет маршрутизировать хост 3306/tcp в порт контейнера MySQL 3306/tcp).

Ответ 2

Поскольку 5 или 6 приложений невелики, как вы описали, я определенно исключил бы возможность установки отдельного MySQL для каждого контейнера по двум причинам:

Это трата ресурсов сервера, это почти эквивалентно установке MySQL 5 или 6 раз на том же сервере.
Он менее гибкий (не может масштабировать DB независимо от приложений) и сложнее для резервного копирования.

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

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