Когда говорят про High Availability, довольно быстро получается классическая картина: три сервера, балансировщик, кластер PostgreSQL, распределённое хранилище, мониторинг и ещё несколько компонентов, про которые никто не вспоминал, пока всё работало на одной виртуалке.

У нас исходная ситуация была намного прозаичнее: была рабочая система на Totum, которую нужно было перенести в новую инфраструктуру и одновременно избавиться от единственной точки отказа.

При этом хотелось выполнить несколько условий:

1) падение одной основной VM не должно останавливать систему;

2) PostgreSQL должен автоматически переключаться;

3) приложение должно понимать, на какой ноде ему разрешено выполнять активные операции;

4) пользовательские файлы должны оставаться доступными после переключения;

5) переключение не должно требовать ручного изменения DNS;

6) всё должно разворачиваться и обслуживаться через Ansible;

7) покупать третью полноценную машину только ради кворума не хотелось.

Последний пункт в итоге и породил архитектуру, которую между собой я называл «HA для бедных». Спойлер: третья машина всё-таки появилась. Но это маленький witness, который практически ничего не делает с точки зрения бизнес-нагрузки.

----------------------------------------------------------------------------------------------------------------------------------

Что такое Totum и почему с ним вообще возник этот квест

Totum — self-hosted low-code платформа для создания внутренних web-приложений: ERP, учётных систем, личных кабинетов и других кастомных бизнес-систем. Приложения строятся вокруг таблиц и прикладной логики, а сама платформа может работать со сторонними системами через API и инициировать HTTP-запросы.

В современном мире ИИ развивается с бешеной скоростью, помогая реализовывать низкоуровневые задачи, где-то даже заменяя самого специалиста. Несколько месяцев назад ко мне пришел друг - у него свой бизнес, он начал жаловаться, что ему не хватает времени вести рабочие соц. сети. И тут меня осенило: а что, если попробовать автоматизировать процесс полностью? Уменьшить рутину, убрать человеческие ошибки и сделать ведение контента максимально лёгким.

Когда проектов в GitLab становится много, довольно быстро появляется одна и та же задача: найти, где используется конкретный API, URL, env-переменная или конфигурационный параметр.

Пока репозиториев мало, всё просто: открыл поиск, ввел строку, получил результат. Но когда проектов уже больше сотни, а нужные вхождения лежат не только в коде, но и в YAML-конфигах, Helm-чартах, .env и JSON-файлах, жизнь становится менее романтичной.

Первый лобовой вариант — просто скачать все проекты локально и искать по ним через grep, ripgrep или IDE. Работает, но тащить 100+ репозиториев на локальную машину ради одной проверки — идея так себе. Ноутбук, скорее всего, энтузиазма не разделит.

Мне хотелось искать прямо поверх GitLab, без локального зеркала всей группы репозиториев. Я начал с просмотра готовых вариантов, а в итоге пришёл к своему гибридному краулеру: код ищется через GitLab API, а конфиги добираются отдельным глубоким обходом файлов. В результате поиск по 100+ проектам сократился с часов до нескольких минут.