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

Моя боль

На работе я пришёл вести один 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, принадлежат своей секции
    ссылки рендерятся в виде 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
☁️ Бета-доступ в облако — через форму в репозитории проекта.

Комментарии (6)


  1. Uranic2
    19.06.2025 09:54

    Вот это велосипед!
    Освойте уже obsidain + пару плугинов


    1. nem Автор
      19.06.2025 09:54

      Спасибо за идею! Плагин для Obsidian надо тоже запилить!


  1. m1skam
    19.06.2025 09:54

    Для меня странный подход.

    ИМХО единым окном вполне может быть мониторинг. Обогатить метрики данными в виде кто делал последний коммит, url репозитория, кто главный мейнтейнер и тд и вот у вас вся информация на дашборде приложения. Прошли по ссылке на репозиторий, вот вам README.md который сразу отображается и в котором все расписан что, где, кто использует.

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

    Если при наличии тераформа, вы позволяете себе и коллегам вносить в инфраструктуру правки, через веб интерфейс, то вы сами себе злобный буратино, инструмент тут не виноват.


    1. nem Автор
      19.06.2025 09:54

      В мониторинг ты не положишь ссылку на настройку DNS, когда истекает GitLab токен, и где у нас CDN. В ридми можно, да. А вы что для мониторинга используете?

      Про терраформ было скорее в обратную сторону у меня идея - что не надо втаскивать терраформ в хобби проект, пока можно обойтись yaml-файлом


      1. m1skam
        19.06.2025 09:54

        В мониторинг ты не положишь ссылку на настройку DNS, когда истекает GitLab токен, и где у нас CDN. В ридми можно, да. А вы что для мониторинга используете?

        Технически возможно, но насколько это имеет смысл? Мы использовали в начале пути связку Prometheus + Grafana, сейчас чуть сложнее, а именно prometheus с remote-write в mimir и в него уже смотрит Grafana, рядом Loki, Tempo. Дополнительно в каждом кластере крутитися OpenTelemetry Collectors, Promtail, Events Exporter и тд. Смотрим в сторону Alloy, на тестовом кластере планируем заменить им Prometheus. Тестировали VictoriaMetrics, но отказались от нее.

        Про терраформ было скорее в обратную сторону у меня идея - что не надо втаскивать терраформ в хобби проект, пока можно обойтись yaml-файлом

        Прошу прощения, из это было не совсем понятно.


  1. serafims
    19.06.2025 09:54

    Осталось запомнить, где лежит конфиг файл и утилита к нему)