Комментарии 15
Вот это велосипед!
Освойте уже obsidain + пару плугинов
Для меня странный подход.
ИМХО единым окном вполне может быть мониторинг. Обогатить метрики данными в виде кто делал последний коммит, url репозитория, кто главный мейнтейнер и тд и вот у вас вся информация на дашборде приложения. Прошли по ссылке на репозиторий, вот вам README.md который сразу отображается и в котором все расписан что, где, кто использует.
4. Terraform. Увы, для девопсов, а не для обычных людей, все туда не затолкать, описывать там приходится даже то что тебя мало интересует (все эти policies и subnets), все это со временем разъезжается. В большинстве случаев получается из пушки по воробьям.
Если при наличии тераформа, вы позволяете себе и коллегам вносить в инфраструктуру правки, через веб интерфейс, то вы сами себе злобный буратино, инструмент тут не виноват.
В мониторинг ты не положишь ссылку на настройку DNS, когда истекает GitLab токен, и где у нас CDN. В ридми можно, да. А вы что для мониторинга используете?
Про терраформ было скорее в обратную сторону у меня идея - что не надо втаскивать терраформ в хобби проект, пока можно обойтись yaml-файлом
В мониторинг ты не положишь ссылку на настройку DNS, когда истекает GitLab токен, и где у нас CDN. В ридми можно, да. А вы что для мониторинга используете?
Технически возможно, но насколько это имеет смысл? Мы использовали в начале пути связку Prometheus + Grafana, сейчас чуть сложнее, а именно prometheus с remote-write в mimir и в него уже смотрит Grafana, рядом Loki, Tempo. Дополнительно в каждом кластере крутитися OpenTelemetry Collectors, Promtail, Events Exporter и тд. Смотрим в сторону Alloy, на тестовом кластере планируем заменить им Prometheus. Тестировали VictoriaMetrics, но отказались от нее.
Про терраформ было скорее в обратную сторону у меня идея - что не надо втаскивать терраформ в хобби проект, пока можно обойтись yaml-файлом
Прошу прощения, из это было не совсем понятно.
Осталось запомнить, где лежит конфиг файл и утилита к нему)
Yaml-файл в git-репозитории каждого проекта, в который по ходу дела докидывается инфа типа ip-адреса, где у нас зарегана почта, где управляем DNS-записями:
На 3х моих последних работах так же всё пытались переизобрести service discovery: на одной - решили что Consul нам мало дает (на самом деле мы еще не умели его готовить) и придумали "паспорт сервиса", но реализовать не успели; на другой придумали настолько умную спецификацию паспорта, что реализовать не смогли; на третьей - взяли https://backstage.io/ да "забороли проблему".
За эти 3 подхода я очень устал понял, что:
универсального решения не будет (К.О.)
https://xkcd.com/927/ будет актуально всегда
всегда нужно встраиваться в имеющуюся инфраструктуру
ИМХО, для всего что связано с веб, нет смысла делать что-то вне парадигмы kubernetes, а там подобного рода тулинга достаточно
Ну, не знаю... На первый взгляд, для очень небольших организаций может как бы помочь, но... в очень небольших организациях нет той проблемы, которую решает эта штука.
А в больших организациях наступит момент, когда структура такого yaml может стать такой же сложной, как конфиги teraform и k8s. В результате окончится чем обычно: будет написан очередной DSL, который похоронит изначальный смысл решения )))
в очень небольших организациях нет той проблемы, которую решает эта штука.
Вот тут я не согласен. Посмотрите на инфру самого сайтдога: https://shorturl.at/j1aw9
Проекту всего месяц, делался на коленке вполсилы, а там уже четыре репозитория и вагон вспомогательных сервисов по каждому подпроекту.
Мне кажется прикол именно в том что мы недооцениваем сколько этих вспомогательных штук вокруг разработки, потому что они нужны там не каждый день, но раз в неделю, в месяц, тебе приходится про них вспоминать.
Что касается больших организаций, да, там будет самая жара! Хочу как раз щас затащить туда по максимуму своих проектов рабочих и нерабочих, и посмотреть как поедет. Понятно что надо будет докручивать всякую группировку/фильтрацию/поиск, как и автоэнричмент/автодискавери - тогда оно станет сильно полезнее и на больших масштабах.
В своем текущем виде тулза точно не предендует на законченое решение высеченное в камне. Это скорее первые шаги в интересном мне направлении.
Спасибо за фидбэк!
А под windows сборки нет?
Как я решил проблему бардака в инфраструктуре в рабочих и личных проектах