Когда я только начинал работу над своим проектом, всю информацию об инфраструктуре (серверы и их роли, хостинги, даты следующих оплат, DNS-записи...) я хранил в файлике на рабочем столе. Сначала это был обычный текстовый документ, чуть позже — таблица в LibreOffice Calc.
Пока серверов было меньше десятка, а хостингов — от силы два, мне было несложно раз в неделю сверять информацию в таблице с DNS-серверами, хостингами и собственным бэкендом.
Проблемы начались, когда количество серверов и хостингов стало стремительно расти. Поддерживать информацию в актуальном состоянии становилось всё сложнее, а при работе в команде появились и дополнительные трудности...
Основная идея
В какой-то момент мне пришла идея сделать небольшой веб-сервис, который будет выступать в роли единого источника информации об инфраструктуре (Source of Truth).
По сути, всё та же табличка, только с веб-интерфейсом, возможностью связывать между собой серверы, IP-адреса, домены и их роли. При этом хотелось не просто хранить информацию, но и управлять DNS-записями. В дальнейшем планирую добавить REST API для написания различных модулей и интеграции с другими околоинфраструктурными системами (например, мониторинг и CI/CD)
Для хранения информации выбрал SQLite. База данных нужна исключительно самому SINVER, взаимодействие с ней других сервисов не предполагается. Поэтому разворачивать отдельную СУБД не видел смысла. К тому же SQLite не требует дополнительной настройки, а вся база хранится в одном файле.
Ранее для обслуживания DNS-зон я использовал BIND9, но в процессе работы над SINVER решил перейти на PowerDNS. Одним из главных аргументов стала его поддержка PostgreSQL в качестве бэкенда. Это позволяет централизованно управлять DNS-записями нескольких серверов через общую базу данных, в отличие от BIND9, где управление зонами преимущественно осуществляется через конфигурационные файлы.
SINVER управляет DNS-записями в PostgreSQL, но изменения применяются не автоматически, а по нажатию кнопки Push. Перед отправкой можно посмотреть DIFF (см изображение ниже) между текущими записями на DNS-сервере и теми, которые предлагает SINVER. Также предусмотрены дополнительные проверки, позволяющие выявить возможные ошибки до применения изменений. Такой подход снижает риск случайно нарушить работу сервисов из-за неправильно указанного IP-адреса или DNS-записи.
Поддержку BIND9 я тоже решил оставить. SINVER умеет генерировать файл зоны, который впоследствии можно использовать для настройки BIND9. Правда, признаюсь честно, этот функционал я пока основательно не тестировал, поэтому гарантировать корректность генерируемых файлов не могу. Сейчас особой необходимости в нём не вижу, но, возможно, в дальнейшем доработаю.
От костыля до MVP
Ранее я не занимался веб-разработкой, а получить работающий инструмент хотелось побыстрее. Поэтому проектирование, архитектуру и составление ТЗ взял на себя, а написание кода поручил ИИ-агенту.
В качестве фреймворка агент предложил Flask. ИИ аргументировал выбор Flask следующим образом:
SINVER не требует сложной серверной архитектуры. Основные задачи приложения — CRUD-операции, работа с SQLite и управление DNS-записями. Flask предоставляет всё необходимое для реализации веб-интерфейса: маршрутизацию HTTP-запросов, шаблонизатор Jinja2 и обработку форм. При этом не навязывает использование ORM, определённую структуру проекта или дополнительные компоненты, в которых сейчас нет необходимости. Это позволяет минимизировать зависимости и упростить развёртывание. А при дальнейшем развитии приложения код можно разделить на независимые модули с помощью Blueprints.
Изначально SINVER вообще задумывался как небольшой костыль под конкретные задачи. В результате весь код приложения оказался в одном файле, о чём я сейчас сильно жалею. По мере развития проекта поддерживать такую структуру становится всё сложнее, поэтому перед полноценным релизом планирую провести рефакторинг и разделить код на отдельные модули.
Отдельное внимание пришлось уделить обновлениям. Не хотелось, чтобы с выходом очередной версии пользователям приходилось пересоздавать базу данных и заново вносить информацию. Поэтому предусмотрел версионирование схемы БД, историю миграций и создание резервных копий перед изменением её структуры.
На данный момент опубликована версия 0.0.0, которую я позиционирую как MVP. Несмотря на это, SINVER уже используется для управления инфраструктурой в моем проекте. Правда, вместе с дополнительной обвязкой и автоматизацией, которые не вошли в публичный репозиторий, поскольку имеют смысл только в рамках моего проекта.
Над чем предстоит поработать дальше
В первую очередь планирую заняться рефакторингом. Разделить код на модули, привести структуру проекта в порядок и избавиться от накопившегося технического долга.
Затем разобраться с известными проблемами, часть из которых уже описана в документации.
Также в планах:
Реализовать встроенную аутентификацию и разграничение прав доступа. Сейчас авторизация осуществляется средствами NGINX.
Оформить приложение как полноценный Python-проект с возможностью установки через pip, а также подготовить контейнерный образ.
Разработать REST API и систему модулей для интеграции с внешними сервисами, в первую очередь системами мониторинга и CI/CD.
Пока это основные задачи, которые хотелось бы решить перед полноценным релизом. По мере развития проекта список наверняка будет пополняться.
Попробовать без установки
А вот тут развернут демонстрационный стенд
логин: admin
пароль: habr
Но перед этим лучше полистать руководство и ознакомиться с текущими проблемами.
Кстати, на стенде обслуживается реальный домен sinver.tech. Так что можете себе сделать бесплатный домен третьего уровня на время работы стенда (но мы за него ответственность не понесем😁)
