Vitaly Karasik

Никто не заставляет использовать docker, systemd, ansible и вообще какие угодно системы оркестрации и оптимизации. Необязательно делать шаблоны конфигов или кластерные конфигурации сервисов, необязательно использовать библиотеки настраиваемого логгирования, возиться с балансерами и реприцируемыми базами. Но люди это делают, значит, смысл всё-таки есть?

Опытный администратор не должен задавать вопрос "нужно ли это вообще?" и исходить из идей вида "любому специалисто в области DevOps нужно вот конкретно это и не нужно конкретно другое". Он должен сам понимать, в какой момент сложность его инфраструктуры достигает того состояния, при котором ей нужно то или иное усложнение. Не рассуждать о том, что консул вообще не нужен или остро необходим, а принять решение о том, что и когда ему нужно для решения практических задач. Прекрасно, что в современном мире существует множество инструментов, которые позволяют достаточно быстро делать различные полезные вещи.

Консул - это тоже инструмент. Вряд ли хоть кто-то использует его возможности целиком и полностью, тем более что никто не заставляет. Кому-то достаточно того, что у него все сервисы зарегистрированы в одном месте и из коробки имеют автоматическое DNS-имя вида NAME.service.consul. Кто-то использует kv-хранилище для хранения параметров, а кто-то хранит в нём секреты и целые конфиги, настраивает токены с различными acl и скрещивает всё это с consul-template. Вообще, необязательно использовать именно консул, есть и другие инструменты для подобных задач. Например, zk/etcd.

Консул чаще используют совсем не с ансиблом, а с инструментами оркестрации, в которых сервисы могут расширяться и сворачиваться, перезагружаться и мигрировать. Скажем, пусть у нас есть условный сервис rabbitmq на три ноды. Тогда у нас может быть три контейнера rabbitm{1..3}, при запуске они регистрируются в консуле скриптом запуска вместе с проверками, а далее consul отдаёт их все три в виде имени rabbitmq.service.consul. Если какой-то из них вдруг упадёт, consul оперативно это обнаружит и исключит из DNS проблемный узел. Если вдруг управляющий всем этим администратор или автоматическая система оркестрации посчитает нужным добавить новые узлы или перенести их куда-то ещё в кластере, то consul также отразит все нужные изменения. При этом использующее rabbitmq приложение должно будет знать только адрес rabbitmq.

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

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

Для начала немного контекста - 2 важных примечания:
1) Описанная задача решается на любом упомянутом стеке, + еще десяток возможных вариантов (Java/Spring, питон, нода, дотнет, голанг и т.д.).
2) Быстродействие системы зависит от ее самой медленной части, и в 95% случаев самая медленная часть - БД, просто в силу специфики работы: много данных со сложными связями, выборки с сортировкой и фильтрацией из большого массива и вот это все, в то время как язык бэкенда в основном выполняет достаточно простые манипуляции с уже готовыми наборами данных (за редчайшими исключениями, которых в вашем кейсе нет, или они не описаны в вопросе).

В вашем случае:
- база можно сказать совсем небольшая, до 1 миллиона записей условный мускуль ворочает весьма шустро, если железо соответствует.
- задача сбора метрик достаточно тривиальная, особого ума в сохранении действий пользователя не надо, бОльшая часть работы - вывод в красивые графики и написание быстрых запросов с хитрыми выборками/агрегациями, немного пошаманить с формулами, возможно делать какие-то сводные выборки с денормализованными результатами для отчетов и прочие мелочи. Работа не сложная, но нудная, и ее много.

Насчет стоимости и условий:

полный самопис 150к+ (я это не тяну) или же сайт на Laravel +MySQL а дальше варьируется.

полный самопис - либо маркетинг, либо идиотизм, писать на голом языке не будет ни одна нормальная студия, в принципе в данном случае либо используется фреймворк и заказчику преподносится как "сделано вручную программистами девственниками под светом серебряной луны", либо разработчики идиоты, мнящие себя круче всех (нет). В первом случае это то же что и "сайт на Laravel +MySQL" (норма и стандарт для среднего уровня студий), во втором - развод на мани на пустом месте и попытка продать г**но в обертке "иксклюзивнасти".

По цене - на сегодняшний день, если я не ошибаюсь, 150к деревянных это +- 1000уе. Цена приемлемая за нормальную работу, если найдете дешевле "на Laravel" - думаю будет вообще ок. Опять же, цены штука такая, кто-то за копейки сделает хорошо, кто-то за дорого каку сляпает. Влияет так же регион, понятно что в Мск цена будет серьезно больше чем в условном Челябинске...

Важный момент - нормальное ТЗ в разы упрощает как поиск исполнителя, так и оценку работы. Я бы на вашем месте погрузился именно в тему создания качественного ТЗ, нежели в дебри современных технологий.

UPD:

проект планируется на 100 к+ посетителей в месяц...
предупреждают что если аудитория достигнет условных 100 тысяч в месяц Лара начнет потихонечку задыхаться от нагрузки,

ок, пусть будет 200к для наглядности.
В среднем, если это маркетплейс, то постоянных посетителей будет не много, думаю около 10%, так что ими можно пренебречь. Условно - 200к / 30 дней = 6600 в сутки, при активных 10-12 часах посещения это ~600 в час. Пусть на 1 посетителя будет 5 запросов страниц, это 600*5=3000 в час = 50 в минуту или менее 1 запроса в секунду.
Даже если умножить это на 30 (допустим такая пиковая нагрузка), 30rps вообще "ниачем". Не знаю кто там вам считал то это проблема, любое современное железо среднего уровня вытягивает без напряга.

1. API
2. Сервера могут общаться через базу данных
3. Сервера могут общаться через брокер очередей
4. Можно подумать насчет общего стораджа - S3, распределенная файловая система, просто сетевой диск замапленный на каждый сервер.

Вопрос не в том, чтобы "как связать", вопрос зачем вам это надо, как вы себе представляете "связывание" и какая у него цель?

Для pitr вам нужен:
- basebackup как основа, должно быть завершено его снятие до датывремени требуемого восстановления pitr
- непрерывный архив всех и абсолютно каждого сегмента wal без пропусков от момента checkpoint перед снятием используемого в восстановлении basebackup и до требуемой точки восстановления

database system was shut down at 2022-02-10 13:31:25 UTC
starting point-in-time recovery to 2022-02-10 07:00:00+00

Это, конечно, невозможно даже с корректным архивом WAL.
У postgresql REDO recovery, а не UNDO. Pitr только вперёд от текущей позиции. И не раньше достижения точки консистентности состояния (окончания снятия basebackup)

Чтобы не ходить по граблям консистентности ещё и файловой системы, basebackup предпочтительнее снимать с самого postgresql, а не снимком блочного устройства. Но в целом вариант предусмотренный, ничем неотличимый от обычного crash recovery вроде старта после пропадания электричества (лишь бы fsync работал на всех уровнях корректно и не игнорировался).

Можете отвечать этим выпендрёжникам, что computer science у всех в школе была.

Теоретически, это можно сделать, если хешировать/солить ваш пароль на клиенте и не передавать на сервер.
Практически, это все равно остается вопросом доверия между вами и сайтом - сегодня они не передают пароль при авторизации, завтра фронтенд Василий шото напутал, и пароль улетел не только в базу сайта, но и к кампании, которая предоставляет аудит пользовательских метрик.

в общем случае это невозможно
docker файл это список команд, которые необходимо выполнить на 'нулевой системе' чтобы приложение заработало

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

в некоторых случаях, пакетный менеджер linux предлагает вполне законченное описание того что нужно для того чтобы приложение заработало, к сожалению в реальности не все так просто, не все приложения корректно описаны, а для некоторых требуется ручная первоначальная настройка

Безопасность вещь комплексная и многое зависит от конкретной реализации. То что в одном месте закрывается (и то не факт, так как не известна реализация) один вектор мало влияет на общую безопасность.

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

Хотите комплексно подойти к вопросу? Копайте в сторону изучения материалов от OWASP. Например, https://owasp.org/www-project-web-security-testing... Там достаточно много материалов для чеклистов. Или смотрите готовые чеклисты что проверять. Например, https://github.com/0xRadi/OWASP-Web-Checklist (я не говорю что это прям лучший чеклист, но посмотрите на число пунктов для быстрой оценки).

Хотите подойти еще комплексней? Начните с книги для новичков по поиску узявимостей - Ловушка для багов. Полевое руководство по веб-хакингу | Яворски Питер https://www.piter.com/product_by_id/196618476

А далее например обратите внимание на более сложную книгу как строить защиту в приложениях
Безопасно by design | Берг Джонсон Д., Деоган Д., Савано Д. https://www.piter.com/product/bezopasno-by-design
Там уже более основательно доводится доводится мысль как выстраивать защиту на основании архитектуры.

Если по теории, то мне в свое время вот эта книга помогла:
https://www.litres.ru/robert-s-martin/chistaya-arh...

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

Через несколько месяцев прочел еще раз, анализируя все затупы, что записал за это время в блокнот. После прочтения начал потихоньку рефакторить в существующих проектах места, которые уж очень жить мешали.

Еще через пол года прочел третий раз, опять же с оглядкой на личный опыт. И тут я кажется уже совсем въехал. По крайней мере многие проблемы с организацией взаимодействия между компонентами стали разрешаться. И вообще появилось достаточно четкое понимание, как структурировать приложение и где разбивать его на компоненты.
Ну и после 3 прочтения еще помог момент: мне дали с нуля проектировать новое, достаточно крупное приложение на Rust. Притом заказчик кричал "микросервисы - это круто, хочу, хочу, хочу", а тимлид мне сказал "давай монолит, но так чтоб потом легко было распилить, а то все сроки про**ем". Вот тут прямо вообще понимание пришло. Ну и плюс в Rust архитектурные компоненты очень хорошо ложатся на отдельные крейты (это такая единица компиляции в Rust), а компилятор в принципе не дает делать циклические зависимости между крейтами.

Ну и недавно решил освежить память и перечитать еще раз. И на этот раз уже были мысли вроде "так если делать по другому, потом проблемы вылезут тут и тут".