Как сделать субдомен, и отдельную БД для каждой пользователя с миграциями laravel, docker?
У меня возникла задача, а именно: как настроить субдомен и отдельную базу данных для каждого пользователя в Laravel с Docker и миграциями?
Необходимо, чтобы в проекте была основная база данных (например, mainDB), а для каждого пользователя, имеющего свой субдомен, создавалась отдельная база данных.
https://octobercms.com/plugin/initbiz-cumuluscore - Лара под капотом, готовая админка с пользователями и готовый же плагин кластеризации. На одной БД, без их бессмысленного размножения.
Вместо платного Октября можно взять его бесплатный форк WinterCMS, плагины совместимы.
Ну, или хотя бы использовать логику, уже кем-то проработанную, в своих велосипедах.
Домен настраиваете согласно документации на ваш веб-сервер, а так же DNS сервер/провайдера. Управление отдельной БД для каждого пользователя реализуете в рамках логики вашего приложения. Конкретный механизм реализации зависит от вашего проекта, его требований и особенностей. Докер - это часть инфраструктуры, каких-то специфических настроек не требует для реализации данной задачи. Вот миграции - тут несколько сложнее и зависит от структуры БД и логики вашего проекта. Может как повторять структуру основной БД так и иметь свою отдельную структуру. Соответственно и миграции - либо в всё в одной куче либо отдельные кучки.
Логикe я думаю будет примерно такой: после регистрации для пользователя создается отдельная база данных с названием его субдомена, и автоматически выполняются миграции для созданной БД .
создается отдельная база данных с названием его субдомена
звучит как какой-то костыль, вместо использование одной общей базы для всех пользователей с foreign key на юзера, но без описания задачи, конечно трудно судить
Иван Иванов, может быть посмотреть в сторону sqlite для каждого аккаунта? Amocrm вроде так делают. Но тогда имеет смысл не на каждого пользователя бд, а бд на компанию в которой может быть n пользователей.
Чем sqlite хорошо для crm, это то что каждый может установить разные плагины и создадутся нкобходимые поля для работы плагина. С 1 общей бд так не сделаешь, а писать универсальную структуру под любой плагин, это не производительно и тяжело потом будет с ней работать разрабам. Ну и с точки зрения безопасности, интеграторы/разрабы плагинов никогда не получат данные другой компании.
В самой срм есть какие то минимально базовые поля для любого проекта, а дальше все доп плагинами делается, соответсвенно структура бд у разных компаний будет разная. Предусмотреть всевозможные интеграции невозможно, это надо дать на откуп разрабам/интеграторам тогда получится нечто очень гибкое что можно заточить под любую задачу
может быть посмотреть в сторону sqlite для каждого аккаунта? Amocrm вроде так делают. Но тогда имеет смысл не на каждого пользователя бд, а бд на компанию в которой может быть n пользователей.
Чем sqlite хорошо для crm, это то что каждый может установить разные плагины и создадутся необходимые поля для работы плагина. С 1 общей бд так не сделаешь, а писать универсальную структуру под любой плагин, это не производительно и тяжело потом будет с ней работать разрабам
Отдельная бд для каждого пользователя - очень плохая идея. Отдельный субдомен тем более.
Одна бд может обслуживать миллионы пользователей.
Спасите себя: сделайте всё в одной бд и на одном домене.
С БД да, нужно иметь основания для разделения.
А чем отдельный субдомен плох? типа name.crm.ru ? Это ведь на уровне nginx решается и выглядит как минимум красиво.
Dmitry Bay, возникает необходимость автоматизировать обновление конфигураций nginx, SSL, логики установки куков. Как минимум, это дополнительные точки отказа, которых можно избежать.
Средний
