Когда я только начинал работу над своим проектом, всю информацию об инфраструктуре (серверы и их роли, хостинги, даты следующих оплат, 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. Так что можете себе сделать бесплатный домен третьего уровня на время работы стенда (но мы за него ответственность не понесем?)

Исходный код

доступен тут по AGPL-3.0-only