Комментарии 4
С почином! Какие-то сложности были? Как разбили приложение и постгрес с экспортером по неймспейсам и проектам опеншифта? Разработчики очень часто не понимают, как это сделать лучше
Сложности были в первоначальном осознании как это все подружить друг с другом )
по поводу
по поводу
Как разбили приложение и постгрес с экспортером по неймспейсам и проектам опеншифта— в одном неймспейсе микросервисы, рядом постгрес и все остальное. Архитектура такая выбрана не случайно, а по ряду причин не зависищих лично от моих хотелок))
по ряду причин не зависищих лично от моих хотелок))
В любом случае интересно почитать доводы за такое, а не другое распределение сервисов по NS.
В каждом NS полный набор всех приложений:
— микросервисы самого приложения — к ним сайдкар jaeger
— поды с postgres и mongo и elastic
— рядом поды с exporters
— далее вспомогательные поды с самим jaeger, prometheus, nginx, envoy
разделение внутри NS по тегам, то есть BD, APP_BACKEND, APP_FRONT, OTHER
именование конечно используется в соответсвии с именованием подов но суть такая
а сами NS разделены по темам, то есть 2 для тестирования локального, 2 для тестирования нагрузочного, 2 препрод, прод и есть еще NS для экспериментов и нужд
— микросервисы самого приложения — к ним сайдкар jaeger
— поды с postgres и mongo и elastic
— рядом поды с exporters
— далее вспомогательные поды с самим jaeger, prometheus, nginx, envoy
разделение внутри NS по тегам, то есть BD, APP_BACKEND, APP_FRONT, OTHER
именование конечно используется в соответсвии с именованием подов но суть такая
а сами NS разделены по темам, то есть 2 для тестирования локального, 2 для тестирования нагрузочного, 2 препрод, прод и есть еще NS для экспериментов и нужд
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторинг postgres внутри Openshift