Comments 13
Есть ли какие-то шансы приспособить этот инструмент для менее масштабной задачи?
У нас в отделе на порядок меньше сервисов (на глаз — меньше 100), но все равно хотелось бы иметь их карту и минимальную автоматическую документацию, и очень не хочется писать все решение с нуля
Может быть, посоветуете что-то?
У нас в отделе на порядок меньше сервисов (на глаз — меньше 100), но все равно хотелось бы иметь их карту и минимальную автоматическую документацию, и очень не хочется писать все решение с нуля
Может быть, посоветуете что-то?
может быть автор еще что-то посоветует, я пока поделюсь своим опытом
у меня есть небольшая инсталяция: на нескольких машинах работает несколько приложений. Каждое приложение — это несколько докер-процессов, описанных в docker-compose.yml.
также в docker-compose.yml для каждого сервиса есть labels в которых есть дополнительная метаинформация, например, ссылка на документацию и url, который обслуживается этим сервисом (например, если там http-сервер)
все эти docker-compose.yml парсятся и создается html-табличка, где указано что за сервис, процесс и мета-информация из labels docker-контейнеров
парсинг происходит периодически и любой коллега имеет доступ к этой табличке и может посмотреть на какой машине какой сервис вертится. в этой инсталяции у меня работает порядка 200 контейнеров (не кубернетес же для этого городить ;), десятки поддоменов и т.д. поэтому табличка эпизодически напоминает где-что работает
при добавлении нового приложения и соответствующего ему docker-compose.yml парсинг его подхватит и табличка дополнится информацией
но это такой промежуточный наколенный вариант, возможно у кого-то есть что-то получше, буду рад узнать
у меня есть небольшая инсталяция: на нескольких машинах работает несколько приложений. Каждое приложение — это несколько докер-процессов, описанных в docker-compose.yml.
также в docker-compose.yml для каждого сервиса есть labels в которых есть дополнительная метаинформация, например, ссылка на документацию и url, который обслуживается этим сервисом (например, если там http-сервер)
все эти docker-compose.yml парсятся и создается html-табличка, где указано что за сервис, процесс и мета-информация из labels docker-контейнеров
парсинг происходит периодически и любой коллега имеет доступ к этой табличке и может посмотреть на какой машине какой сервис вертится. в этой инсталяции у меня работает порядка 200 контейнеров (не кубернетес же для этого городить ;), десятки поддоменов и т.д. поэтому табличка эпизодически напоминает где-что работает
при добавлении нового приложения и соответствующего ему docker-compose.yml парсинг его подхватит и табличка дополнится информацией
но это такой промежуточный наколенный вариант, возможно у кого-то есть что-то получше, буду рад узнать
Дешево и сердито. Наверное, если никакого готового (или хотя бы наполовину готового) варианта не найдем, придется так же поступить
Субъективно, на сколько вообще полезными эти данные оказываются?
Субъективно, на сколько вообще полезными эти данные оказываются?
Еще недавно мы работали из офиса, и можно было спросить коллегу за соседним столом: «не помнишь, где работает приложение такое-то?» он называл имя сервера, и в целом ты быстро находил нужный сервер
сейчас каждый в своем домашнем офисе работает, и звонить чтобы спросить как-то не всегда удобно, поэтому html-табличка появилась. по логам глянул — ежедневно коллеги на нее заходят по нескольку раз.
сначала это просто была таблица: машина — приложение — сервис. сейчас стал понемногу добавлять обслуживаемые url и ссылки на документацию (в том числе на swagger-интерфейсы), и стали чаще спрашивать когда добавлю оставшиеся ))
так как докер еще логи через сислог на машину логов скидывает, где логи также лежат в директориях соответствующих машинам, то понятно где логи разыскивать. поэтому субъективно — данными пользуются каждый день.
но… чисто мне не очень нравится такой вариант, какое-то внутреннее убеждение, что можно как-то сделать более системно что ли. воспринимаю как временное решение, хотя людям стало удобнее искать где какие приложения работают, что в них входит, есть ссылка на описание работы приложения.
сейчас каждый в своем домашнем офисе работает, и звонить чтобы спросить как-то не всегда удобно, поэтому html-табличка появилась. по логам глянул — ежедневно коллеги на нее заходят по нескольку раз.
сначала это просто была таблица: машина — приложение — сервис. сейчас стал понемногу добавлять обслуживаемые url и ссылки на документацию (в том числе на swagger-интерфейсы), и стали чаще спрашивать когда добавлю оставшиеся ))
так как докер еще логи через сислог на машину логов скидывает, где логи также лежат в директориях соответствующих машинам, то понятно где логи разыскивать. поэтому субъективно — данными пользуются каждый день.
но… чисто мне не очень нравится такой вариант, какое-то внутреннее убеждение, что можно как-то сделать более системно что ли. воспринимаю как временное решение, хотя людям стало удобнее искать где какие приложения работают, что в них входит, есть ссылка на описание работы приложения.
Да, решение которые мы используем вряд ли можно назвать дешевым, оно скорее применимо в компаниях: где уже есть практика Enterprise Architecture Management, существует описание IT ландшафта и эту EAM практику надо «обновить» с учетом того, что IT ландшафт становится все более «микросервисным».
С моей т.з., вам все равно нужно хранить метаинформацию о компонентах, где-то рядом с кодом самих компонентов. Мы используем yaml файл, antirek использует labels в docker-compose.
После того как у вас действительно есть «информация», то остается достаточно простая задачи по ее сбору в единую документацию и предоставления в удобном виде. И тут уже много вариантов в зависимости от ваших возможностей и требованиям к документации.
С моей т.з., вам все равно нужно хранить метаинформацию о компонентах, где-то рядом с кодом самих компонентов. Мы используем yaml файл, antirek использует labels в docker-compose.
После того как у вас действительно есть «информация», то остается достаточно простая задачи по ее сбору в единую документацию и предоставления в удобном виде. И тут уже много вариантов в зависимости от ваших возможностей и требованиям к документации.
- Для внутренних нужд мы используем генератор, который создает страницы в confluence wiki на основе метаинформации и конфигурации зависимостей между компонентами. (https://www.youtube.com/watch?v=V56GEtx36HE&feature=youtu.be&t=2693 с 43 минуты, пару слайдов о нашем опыте).
- Вы можете попробовать сервис Pivio (http://pivio.io), но тут на ваш риск, проект сейчас не выглядит очень живым и развивающимся.
- Так же, вы повторить наш опыт использования проекта github.com/AOEpeople/vistecture. (то же видео что и раньше, но с 35-й минуты).
- antirek предлагает просто генерацию html страниц(что очень похоже на пункт 1.)
Тоже хотелось найти менее промышленное решение для документации
как докер-микросервисов, так и любых других API, сайтов и прочего наследия.
И желательно еще чтобы документация была интегрирована с мониторингом/health чеками.
(для десятка, а не сотен проектов; для десятков, а не сотен микросервисов внутри проекта)
как докер-микросервисов, так и любых других API, сайтов и прочего наследия.
И желательно еще чтобы документация была интегрирована с мониторингом/health чеками.
(для десятка, а не сотен проектов; для десятков, а не сотен микросервисов внутри проекта)
то что вы описываете, в верхних трех строчках, больше похоже на API Management, посмотрите решения класса API Portal / API Management.
Например, konghq.com/products/kong-enterprise/dev-portal, правда, я не уверен что будет удобен если не используете Kong как API Gateway.
Например, konghq.com/products/kong-enterprise/dev-portal, правда, я не уверен что будет удобен если не используете Kong как API Gateway.
был просто хаос, стал хаос с картинкой ))
en.wikipedia.org/wiki/LeanIX — не существует такой страницы
странно, месяц назад была. Тогда смотрите официальный сайт — www.leanix.net/en
slookin
Спасибо за статью,
подход с авто-документированием через .yml файл в корне кажется самым практичным…
Подскажите пожалуйста каким образом в pivio.yaml передаются параметры окружения при деплое в вашей конфигурации?
Там есть, например, поле lifecycle (production/developement), есть адреса сервисов с портами,
это же не может лежать в git в самом pivio.yml…
Спасибо за статью,
подход с авто-документированием через .yml файл в корне кажется самым практичным…
Подскажите пожалуйста каким образом в pivio.yaml передаются параметры окружения при деплое в вашей конфигурации?
Там есть, например, поле lifecycle (production/developement), есть адреса сервисов с портами,
это же не может лежать в git в самом pivio.yml…
Сразу видно, читали «в деталях» и даже пытались применить.
Да, естественно, параметры которые специфичны для окружения у нас не храняться в yaml.
Да, естественно, параметры которые специфичны для окружения у нас не храняться в yaml.
- Во-первых мы и не собирались использовать пока эту информацию (те же порты)
- Во-вторых есть ограничения в Pivio-LeanIX интеграции (большая часть полей не поддерживается — например lifecycle).
- Ну и в третьих, если уж нам действительно нужны будут параметры с окружения — можно попробывать использовать интеграцию LeanIX Cloud Native Suite с k8s (https://www.leanix.net/en/solutions/cloud-native-suite). Но повторюсь, пока мы не дошли до такой необходимости.
- В четверых, если вам все же нужны будут значения с окружения, мы же можете в процессе разворачивания просто вызвать LeanIX REST API и обновить нужные аттрибуты уже в существующих Fact Sheet.
Sign up to leave a comment.
Документирование микросервисов в LeanIX (EAM)