Vitaly Karasik

Клонируете с gitlab:
git clone %gitlab_url%
Создаете репозиторий в github и меняете remote url:

git remote set-url origin %github_url%
git push

Все ваши коммиты в github.
PS
Само собой gitlab/github аккаунты должны быть настроены.

Присутсвует ли LDAP сервер в решении Samba DC? Подходит ли Samba для организации централизованной аутентификации?

Да, присутствует. Более того - он и в AD присутствует :) Любой контроллер домена можно открыть любым LDAP-браузером и ldapsearch работает прекрасно.
Да, подходит.

Samba AD DC несовместима с OpenLDAP?

В смысле? openldap - часть самбы (в том смысле, что используется в ней, а не часть проекта). Вы совместимы со своей рукой?

Прочитал что Samba AD DC функционирует на уровне контроллера доменов Windows 2008 R2. Что это значит с точки зрения возможного функционала?

Что домен MS увидит в самбе контроллер домена уровня w2k8

Например из документации гитлаба, в перечне поддерживаемых служб каталогов, Samba DC отсутствует

Самба не является отдельной уникальной службой каталогов, это просто AD не на Windows. Причем AD, лишенная многих виндовоспецифичных фишек и поэтому довольно бесполезная. Годится только с голодухи для импортозамещения
Единственное, известное решение кроме самбы - это IPA.
Все, кто поддерживает AD - поддерживает и самбу (а вот причем тут openvpn - я не понял)

Я прошу прощения что не-про-лайкал, но за темой следил. Утонули в работе. Хочу ответить к чему все пришло, кому будет интересно

Еще как тема создалась, мы сразу пробовали различные варианты которые тут советовали.

Clickhouse – не зашел, кажется что он слишком простой, но он требует инженерить. Это все не так просто оказалось как 1,2,3.
Да, быстро читает
Да, чуть сэкономил место на тестовом стенде (2%)
Но: кучу геморроя с настройкой и потребуется вложить время в переделку всего (ч.к деньги). А у нас никто им не владеет

Kafka Немного не под эту задачу, но взяли её в оборот на будущие доработки внутри микросервисов

Далее отвлеклись, а когда вернулись к вопросу с холодной головой оказалось что купить Б/У сервера с новыми NVME дисками (нет перезаписи - нет проблем с ресурсом) выгоднее, чем тратить время на оптимизацию. Провели работу над соединениями, основному софту mysql теперь нужно только чтоб сделать старт. Далее база не нужна, а данные читают как читались большими выборками
Поработали над буфером, добавили mysql серверов и вот нагрузка уже не такая печальная.

Вот несколько фактов, которые помогут понять как работает Git.

• Файл .gitignore предназначен для описания того, что мы не хотим СЛУЧАЙНО добавить в репозиторий. Либо не хотим случайно удалить переключив ветку.
  
• Мы можем ПРИНУДИТЕЛЬНО добавить в репозиторий ЛЮБОЙ файл, даже если он описан в .gitignore.
  
• Добавление файла в .gitignore не удалит сам файл из репозитория. Если файл УЖЕ в репозитории, то он продолжит отслеживаться, независимо от наличия .gitignore.
  
• Если больше не хотим отслеживать какой-то файл, то просто удаляем его из репозитория. Ключ --cached позволит оставить файл в рабочем каталоге текущего репозитория если он нужен.
  

git rm --cached -- '.DS_Store'
git commit

Но последний рецепт сработает только на одном компьютере. Если коллеги переключатся на этот коммит, то файл удалится у них из рабочего каталога.

Делегат позволяет ослабить связность кода, а рассматривать их стоит вместе с событиями.
Я объясню на примере игростроя.
Популярный в сети пример: во врага попала пуля. Должно случиться сразу много вещей - нужно снять здоровье врага, выяснить, не погиб ли он, проиграть анимацию, уничтожить пулю, начислить очки игроку и еще что-то.
Если мы будем всё это вызывать напрямую, то быстро запутаемся и ошибемся. А когда будем переделывать, сломаем всё окончательно.
Вот тут нас выручат делегаты и события. Мы определим событие, которое срабатывает (вызывает свой делегат) в момент попадания пули. И соответственно, определим делегат для этого события.
Теперь каждый метод, которому это событие интересно, может подписаться на его делегат (внести себя в список вызываемых делегатом методов - их может быть больше одного).
И теперь мы можем переделывать что угодно. Главное, не забывать подписываться и отписываться.
Делегат, это как автолавка в деревне: приезжает и сигналит. Кому надо - выходит. При этом ни автолавке ни покупателям не интересно, что происходит у каждой из сторон в отдельности.

Никто не заставляет использовать 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 работал на всех уровнях корректно и не игнорировался).