Как я решил проблему бардака в инфраструктуре в рабочих и личных проектах

Три часа ночи. 
Прод лежит.
А где у нас, собственно, что?

Моя боль

На работе я пришёл вести один Rails-проект, а через полгода у меня было уже два бэкенда (новый бренд и старый), сайт-документация, пара мобильных приложений и прошивка для умного замка. Репозитории разбросаны по разным местам, DNS в трех разных местах, CI, CDN, Docker Registry, аппсторы, SSL, трекинг ошибок, тикеты, логи.

В среднем 10 мест на проект на 7 проектов на 2 окружения (staging + production). Когда прод падает, первые полчаса ты просто пытаешься понять, куда бежать и что вообще мониторить.

В хобби-проектах казалось бы должно быть полегче — их пять штук, некоторые открываю раз в месяц. Но тут те же головняки: репа, DNS, трекинг ошибок, аналитика, SEO-инструменты… и иногда я днями не могу исправить баг, потому что не помню, где лежат исходники — в Lovable, Replit или Cursor?

Итог: проектов и сервисов море, всё в голове не удержать, каждый раз тратить минуты на “куда же я это записал?” — бесит и крадёт время.

Понятные готовые решения

1. Закладки браузера. Да, но теряются когда переезжаешь на другой браузер + неудобно, когда реально много всего + и не поделиться с командой.

2. Confluence. Который всех бесит. И который тоже сначало надо найти. А потом в нем найти куда что в каком виде записать.

3. GitLab. Неплохо разогнался в свое время, натолкал в себя CI, Docker Registry, тикеты, канбан досок, инциденты, security audit и прочего, но увы, так и не стал сервисом единого окна. В общем, ссылки две-три четыре, он вам способен сократить, но на этом все.

4. Terraform. Увы, для девопсов, а не для обычных людей, все туда не затолкать, описывать там приходится даже то что тебя мало интересует (все эти policies и subnets), все это со временем разъезжается. В большинстве случаев получается из пушки по воробьям.

Увы, ни один из этих вариантов ни достаточно минималистичен, ни минимально достаточен :(

Мое решение

Yaml-файл в git-репозитории каждого проекта, в который по ходу дела докидывается инфа типа ip-адреса, где у нас зарегана почта, где управляем DNS-записями:

makefile.site:
  registrar: gandi
  dns: Route 53
  hosting: https://carrd.com
  mail: zoho

Я добавляю даже не ссылки, а просто названия сервисов, когда это все что я знаю. Уходит на это три секунды, но в следующий раз будет ясно куда бежать. И когда я в следующий раз доберусь до AWS, я не поленюсь, и докину прямую ссылку на настройку DNS вместо текстового "Route 53".

Следующий логичный шаг - рендерить мини-дэшборду со ссылками и заметками чтобы она всегда была под рукой. После нескольких попыток остановился на таком варианте:

Это для конфига выше и еще одного посложнее

Особенности формата

Данные лежат под корневым ключем. Несколько корневых ключей - несколько карточек.

Корневой ключ может быть именем домена как в моих примерах, а может быть просто production/staging - здесь полная гибкость.

Ниже я привел базовые структуры, и как они рендерятся:

1. Ключ+ссылка и ключ+значение:

   

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

2. "Хэш" со ссылками:

   

   ссылки рендерятся в виде pills, принадлежат своей секции

3. "Хэш" со значениями:

   

   по клику копируется в буфер обмена

4. Список:

   

   просто список, без постобработки

Формат максимально простой и гибкий. Сейчас нет никакого фиксированного, или даже требуемого набора ключей. Все отдается на откуп автора.

card:
  hetzner: 12.43.21.123

А можно и эдак:

card:
  hosting:
    provider: hetzner.com
    ip: 12.43.21.123
    managed_by: easypanel

Скорее всего подъедет пара зарезервированных слов project и tags для удобной группировки и навигации по большому кол-ву карточек, но пока полная свобода.

Как попробовать

1. Установить: curl -sL get.sitedog.io | sh

2. Закинуть в папку проекта sitedog.yml с вашими заметками (ну или sitedog init сгенерит пустой файл для вас).

3. Дальше sitedog live пока реадктируете файл и хотите живые обновления карточек, и sitedog render, когда закончили, у нужен финальный html-файл.

Исходники утилиты и установщика в открытом доступе здесь: github.com/sitedog-io/sitedog-cli. Open Source, MIT, все дела.

Как попробовать если лень

Если хочется потыкать формат, не устанавливая ничего — вот live editor.
Редактируйте YAML — и сразу смотрите, как рендерятся карточки.
Никакой регистрации, просто интерфейс.

Идеи по использованию

Хоть тулза и называется SiteDog, она позволяет хранить информацию не только о сайтах.

Тип проекта	Описание	Примеры данных	Кому подойдет
Веб-сайты	Отслеживание основной инфраструктуры сайтов	DNS, хостинг, SSL, CDN, аналитика, домены	Веб-разработчики, агентства
Внутренние сервисы	Учёт корпоративных инструментов и API	Внутренние API, базы данных, мониторинг, логи	DevOps, системные администраторы
Серверная инфраструктура	Управление серверами и их компонентами	IP-адреса, кому выдан доступ, бэкапы, мониторинг ресурсов	Системные администраторы
Мобильные приложения	Отслеживание релизного цикла мобилок	App Store, Google Play, Firebase, push-уведомления, аналитика	Мобильные разработчики
SEO-аудит	Централизованный контроль SEO-метрик	Google Search Console, Яндекс.Вебмастер, семантика, позиции	SEO-специалисты, маркетологи
Домены и поддомены	Управление доменным портфелем	Регистраторы, DNS-записи, сроки продления, редиректы	Владельцы больших доменных портфелей
API и интеграции	Каталог используемых API и сервисов	Инфа об API-ключах, лимиты, документация	Backend-разработчики

Все это естественно можно комбинировать в любых комбинациях под собственные нужды.

Ключи/токены/сертификаты

Если у вас глаз зацепился за упоминание API-ключей, то я не имею в виду сами ключи. Речь идет о вспомогательной информации такого рода:

api_key: stripe-prod #(название/алиас)
api_key_expires: 2028-06-30
api_token: github-deploy-token-kirill
ssh_access_shared_to: ivan, kirill
ssl_cert_expires: 2025-12-01

Для самих ключей/токенов есть специализированные инструменты - там им и место.

Итого

В своем текущем виде - это симпатичная маленькая command line утилита:

• почти не требует внимания;

• даёт быстрый доступ к (часто критически важной) информации “где у нас что”;

• встраивает в процесс разработки актуализацию инфраструктурной инфы;

• можно добавить в Git hooks и CI/CD, чтобы рендерить и заливать HTML версию.

Сейчас допиливается простой бэкенд, чтобы можно было собирать "карточки" со всех проектов в одном месте — с поиском, фильтрацией, группировкой по тегам и окружениям.

Планы по развитию

Некоторые фичи напрашиваются сами собой:

1. Авто-энричмент - чтобы по неполным данным, например hosting: hetzner, оно бы само догадывалось достать ссылку и иконку

2. Авто-дискавери - подключаешь свой гитхаб/гитлаб, даешь доступ до репозиториев, и изменения оно добирает само.

3. Сделать так чтобы оно буквально всегда было под рукой:

   • Экстеншн для Chrome (чтобы встраивалось в UI Github/GitLab),

   • Экстеншн для VS Code (и других редакторов?)

   • +Наверняка вылезет еще куча вариантов куда это можно встроить

Все из этого я придумал еще на этапе проработки идеи, но когда дело дошло до кода - возникло несколько затруднений.

Технические подробности

На самом деле довольно неочевидно на каком языке разрабатывать такую штуку.

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

Из интересных вариантов: писать все на Node – тогда можно будет переиспользовать код и в CLI-утилите, и в live-editor, и в экстеншнах. Но, честно говоря, душа не лежит.

Опять же, в плане доставки cli-утилиты, завязываться на Node - не лучший вариант.

Вариант "летим в космос": писать все на Clojure, и из Clojure-кода же генерить имплементацию на других языках, и сами экстеншны 😀. Звучит заманчиво, но такими экспериментаи я займусь когда выйду на пенсию.

Если не понятно какое решение принимать, то лучше его отложить (до появления новой информации. И делать минимально необходимое с учетом текущей реальности. Реальность:

1. Для live-editor в браузере по-любому нужно решение на JS.

2. CLI доставлять лучше всего бинарником.

3. Хорошо бы чтоб работало под все операционки.

Текущее решение: рендерилку оставить на JS, а CLI сделать на Go, для удобства дистрибуции. Облако - на Ruby, потому что one love!

Процесс > Инструмент

На самом деле хочется конечно не ещё одну "волшебную" тулзу, а ощущение, что где-то есть порядок, который мне подчиняется.

В этом смысле SiteDog — это не решение “всё и сразу”. Это решение 20/80, когда буквально "what you see is what you get".

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

Философия решения:

• Less in More: не втаскиваем тяжеловесные IaC-решения пока реально не нужно → когда втаскиваем, sitedog все еще полезен для вещей которые не хэндлятся такими решениями

• Не напрягаемся: на поддержание актуальности тратим микроусилия по ходу дела → пользуемся накопительным эффектом

• Лучше неидеально, но прямо сейчас: накидываем буквально все что вспоминается, пофиг в каком виде → всегда можно будет проапдэйтить позже

"We eat our own dogfood":

Вот как выглядит колода карточек самого Sitedog:

Даже в таком небольшом проекте накапливается много сущностей, про которые легко забыть

Спасибо что дочитали!

Если вы узнали в моем рассказе свою боль — попробуйте.
Если не узнали — расскажите, как у вас устроено.

Баги, идеи, фидбек — welcome в issues или прямо в комменты.

⭐️ GitHub: github.com/sitedog-io/sitedog-cli
☁️ Бета-доступ в облако — через форму в репозитории проекта.