Как правильно реализовать архитектуру CMS для распространения по модели SaaS?
Добрый день, написал CMS и хочу распространять по модели SaaS.
С помощью CMS можно делать сайты визитки, лендинги, магазины.
Как правильно и лучше организовать архитектуру? Насколько критично изолировать друг от друга клиентов docker-контейнерами?
В качестве БД использую Mongo Atlas, у каждого клиента своя БД(настройки, шаблоны, все хранится в базе), основной вопрос заключается в следующем: Насколько целесообразно использовать одну копию CMS для всех сайтов? Хотелось бы использовать именно такой подход, т.к. я полагаю, что обновлять и поддерживать систему так будет проще, чем если разворачивать под каждого клиента отдельное окружение.
Дмитрий, все уникальное в т.ч. дизайн хранятся в БД. Потому и интересует критика подхода при котором одна CMS обрабатывает все сайты.
sim3x, Вы же про теги? Согласен на счет монги, но докер это инструмент для изоляции окружения, если я правильно понял его предназначение, а вопрос глобально сводиться к тому, изолировать или нет и если изолировать, то каким образом. Хотя вот пока печатал, понял, что наверное не следовало их вписывать, видимо хотел большего охвата для того, чтобы быстрее получить ответ.
For example, CVE-2014-3519, CVE-2016-5195, CVE-2016-9962, CVE-2017-5123, and CVE-2019-5736 can all lead to container breakout.
изолировать или нет
изолировать
каким образом
начать с изоляции в виде пользователей, отдельных пулов пхп-фпм, отдельный диск для статики, логирование и тд и тп
Ака вам нужен админ с опытом работы в большом хостинге, где он занимался проектированием систем защиты
Есть еще вот такая штука https://github.com/google/gvisor
Но опять же - без понимания векторов угроз у вас 0 шансов защититься от злоумышленников
изоляции окружения, но не для изоляции пользователей друг от друга
Не уверен, что правильно понял, не могли бы конкретизировать? Разве пользователи не будут изолированы друг от друга, если каждый будет в отдельном докер окружении т.е. для каждого по сути свой nginx + php-fpm, а БД в Mongo Atlas или в отдельном контейнере? UPDATE
После обновления вашего комментария (CVE-2014-3519, CVE-2016-5195, CVE-2016-9962, CVE-2017-5123, and CVE-2019-5736), понял о чем вы. Спасибо.
изолировать
Могли бы аргументировать, почему не стоит использовать одну копию CMS для всех клиентов? Чем такой подход плох?
начать с изоляции в виде пользователей, отдельных пулов пхп-фпм, отдельный диск для статики, логирование и тд и тп
Ака вам нужен админ с опытом работы в большом хостинге, где он занимался проектированием систем защиты
Есть еще вот такая штука https://github.com/google/gvisor
Но опять же - без понимания векторов угроз у вас 0 шансов защититься от злоумышленников
Мне бы для начала стартануть бы проект, чтобы понять целесообразность, а с увеличением кол-ва клиентов и соответственно денежного потока, все можно будет заняться модернизацией и улучшениями. На данный момент основными угрозами я вижу XSS, SQL inj, CSRP, DDoS. Я полагаю, целенаправленная попытка взлома сайтов клиентов не представляет какого-либо интереса.
На самом деле, мой вопрос это не попытка поиска защищенной архитектуры, а отсутствие понимания как строить приложения работающие по SaaS; Действительно нужно\целесообразно под каждого клиента устанавливать отдельную копию CMS? Все что уникально для клиента, находиться в БД т.е. на уровне CMS - ядро одинаковое для любого сайта, а единственный экземпляр приложения проще поддерживать и обновлять.
Дмитрий, Если использовать один экземпляр CMS для всех клиентов и на каждого клиента отдельная БД, я решил целесообразно использовать именно такой подход. К тому же я уже встречал такое решение в других CMS(vBulletin, XenForo); К тому же, в Mongo есть GridFS который позволяет хранить там файлы. ( https://habr.com/ru/post/192390/ )В итоге получится, что все что относится к конкретному клиенту находится в отдельной базе данных,
Доступ к исходникам шаблона (html\css\js) есть через редактор в панели администратора, а исходники самой CMS распространять не планирую т.к. решение не коробочное, а SaaS.
Докер это не про saas. И база должна быть одна, есть сущность пользователь, а у пользователя проект, который может быть визиткой, лендингом еще какой-то хренью. База одна, если будешь все делить, то ты в одиночку окажешься неспособен поддерживать эту систему.
Почему база должна быть одна? Я правильно понимаю, что ты предлагаешь хранить данные от всех клиентов в одной базе? В таком случаи, в случаи взлома пострадают все клиенты сервиса, зачем использовать такой подход?
NinjaNickName, потому что легко поддерживать, легко выкатывать апдейты, легко поддерживать, делать бэкапы и проч, это просто и дешево. А если чел вскроет твою систему, то его не остановит никакое деление на разные бд. Да и ради клиентов никто не ломает такие системы, тебя максимум кто ломанет, это автоматический сканер, зальет дор и присоединит твои тачки к ботнету. А чтобы целеноправленно ломали, этот saas должен стать чем-то.
Sanes, а в чем тебе поворотливость нужна? Пилить решение под каждого клиента чтоли? Ну дак цель saas уйти от этого всего, иначе решение очень быстро скатывается в неподдерживаемый кусок говна, и чем оно сложнее, чем сложнее деплоить, тем все херовее будет.
Sanes, ну например потому что киленту нужна фича и у него есть деньги на нее, либо потому что он хочет развернуть все внтури своей корп сети, и пользоваться ad и прочими радостями.
Ты скорее всего и так от этой идеи с разными бд откажешься после первого аналитического запроса.
Честно говоря пока не понимаю минусов этого подхода и какие сложности могут возникнуть с поддержкой. Более того, вот пример, возьмем интернет магазины, это получается нужно в одной базе в одной коллекции хранить товары для всех интернет магазинов? Разве это правильных подход?
NinjaNickName, ну элементарно, есть куча товаров и все тормозит, ты зашел в базу, понял косяк, добавил индекс, и все полетело. А так у тебя 3 тысячи баз, ты кучу времени потратишь пытаясь сначала понять где затык, а потом на то, чтобы это все задеплоить с изменениями. Это и в команде сложно, а тут ты один.
Можно и как обычный хостинг с доступом только к экземпляру CMS. Я бы так сделал.
Это я понимаю, но а лучше то как?)) Мне думается, что с одним экземпляром приложения на продакшене всяко проще обновлять и поддерживать, поправьте, если ошибаюсь.
Перестаньте пихать Docker в стек Lamp. Там на уровне пользователей всё прекрасно разруливается с правами.
Согласен, но если на каждого клиента отдельный экземпляр, то и максимальная изоляция клиентов друг от друга это типа бест практик в екомерс чтоли, по крайней мере так мне думается.
Средний
