Как организовать работу с mongodb и докером на локалке и сервере?

Возможно банальный вопрос, но не пойму как разрабатывают приложения docker+node.js+mongodb.

Хочется запускать докер композ на локалке, делать что нужно, а потом пушить все на сервер. Но что делать с данными mongodb которые монтируются при помощи volumes. Неужели их тоже нужно туда-сюда с локалки на сервер и наоборот гонять? Или я что-то не так задумал?)

Только начал тыкать монгу и ноду, не судите строго. Направьте на пусть истинный)

Если есть хороший пример такой сборки, был бы благодарен ссылочке.
  • Вопрос задан
  • 214 просмотров
Решения вопроса 1
trapwalker
@trapwalker
Программист, энтузиаст
Ни в коем случае не пушить туда-сюда.
  • В идеальном случае ваш проект должен поддерживать миграции:
  • Каждая ревизия кода, которая нарушает совместимость с БД относительно предыдущей, должна содержать скрипт миграции. В этом скрипте создаётся структура, модифицируются старые данные, переименовываются поля и т.д. Иногда такие скрипты делают двунаправленными, чтобы поддерживать обратные миграции.
  • В БД нужно хранить версию или номер ревизии, которой соответствует текущее состояние БД.
  • При запуске приложения нужно проверять версию и выполнять цепочку миграций, необходимых для приведения версии к требуемому состоянию.

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

Монга - это schema less БД, которая толерантно относится структуре коллекций и не валится при запросе несуществущих полей. Нужно стараться писать код максимально толерантно к отсутствию наполнения БД.

В любом случае у вас в БД есть обычно:
  1. структура (в случае монги, как я уже сказал, это не так важно)
  2. справочники
  3. пользовательские данные
  4. производные данные (кэш), которые можно безболезненно удалить, а затем они перегенерятся сами по мере запросов.

Нужно писать код так, чтобы он всю структуру и технические справочники, отсутствующие в предоставленной БД и необходимые для работы, умел инициализировать сам. Или, на худой конец, сделайте команду или скрипт init_db.

Если какие-то тестовые данные нужны для тестов или отладки, то можно сделать скрипт, который заполнит БД ими. Это называется фикстуры.

Никогда не храните код в БД. Всякие хранимые процедуры и прочее в БД - это зло. Код должен быть в системе контроля версий, а БД к этому не приспособлены. Если уж нужны хранимки, то храните их в системе контроля версий и заливайте их в БД при инициализации или миграциями.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы