${XPACK_MONITORING_ENABLED:true} - это что за конструкция?

Ну вот в template/configmap.yaml так

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

значит у меня мозг не работает. Если нужно масштабироваться 2 разным приложениям, но одно важнее. Как рассказать эту кубу? Он же не пойдет откатывать второстепенное?

беру все слова обратно, если потушит

это так не работает. Нужно или самому настраивать доступ прома в куб апи или делать по нормальному - ставить https://github.com/coreos/prometheus-operator/tree/master/contrib/kube-prometheus и не страдать велосипедами

я под докер сварм (свят-свят) руками ставил конт с промом и настраивал вроде норм.. а тут получается просто так не выходит.

чем лучше?

документация есть

а к чему нету?

к велосипедам

я упустил, а что есть велосипеды в данном контекте?

А если инфра будет соответствовать требованиям инфосек, то тоже атата?

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

Кейс. Saas сервис. Для клиента поднимается несколько контейнеров: Бекенд (yii2) Фронтенд. (Vue.js) Отдельно доступны сервисы общие доя хранения, бд и т.д. Платформарма бека и фронта может обновляться. Соотвественно контейнеры пересобираются и обновляются. Клиент из маркетплейса может себе затянуть модуль как в бекенд, так и во фронт. Поэтому по составу конейнеры у каждого пользователямогут быть разные по содержанию. Мы хотим установка модулей и обновление платформы делать через скрипты внутри контейнера и делать копии контейнера для балансировки в случае если один из них потухнет. Кто сталкивался с таким кейсом? Как лучше поступать?

никто не сталкивался. советую нанять инженера

Кейс. Saas сервис. Для клиента поднимается несколько контейнеров: Бекенд (yii2) Фронтенд. (Vue.js) Отдельно доступны сервисы общие доя хранения, бд и т.д. Платформарма бека и фронта может обновляться. Соотвественно контейнеры пересобираются и обновляются. Клиент из маркетплейса может себе затянуть модуль как в бекенд, так и во фронт. Поэтому по составу конейнеры у каждого пользователямогут быть разные по содержанию. Мы хотим установка модулей и обновление платформы делать через скрипты внутри контейнера и делать копии контейнера для балансировки в случае если один из них потухнет. Кто сталкивался с таким кейсом? Как лучше поступать?

делать по канонам микросервисов с шинами и тп. 0 проблем же.

https://github.com/coreos/prometheus-operator/blob/master/contrib/kube-prometheus/docs/exposing-prometheus-alertmanager-grafana-ingress.md

Кейс. Saas сервис. Для клиента поднимается несколько контейнеров: Бекенд (yii2) Фронтенд. (Vue.js) Отдельно доступны сервисы общие доя хранения, бд и т.д. Платформарма бека и фронта может обновляться. Соотвественно контейнеры пересобираются и обновляются. Клиент из маркетплейса может себе затянуть модуль как в бекенд, так и во фронт. Поэтому по составу конейнеры у каждого пользователямогут быть разные по содержанию. Мы хотим установка модулей и обновление платформы делать через скрипты внутри контейнера и делать копии контейнера для балансировки в случае если один из них потухнет. Кто сталкивался с таким кейсом? Как лучше поступать?

Не совсем. Они в маркетплейсе нажимают кнопочку «установить» и закачивается zip пакет расширения.

Не совсем. Они в маркетплейсе нажимают кнопочку «установить» и закачивается zip пакет расширения.

итак сейчас у меня есть пром, задеплоеный из обычного офф имаджа. в дефолтной конфигурации он не видит мой екпортер. чтобы он увидел, мне пришлось добавить в конф файл, в самом контейнере прома, кусок конфига для експортера: - job_name: 'celery-prometheus-exporter' static_configs: - targets: ['10.1.2.3:8888'] после команды kill -HUP 1 пром увидел этот экспортер. вопрос - как мне зафиксировать этот конфиг, чтобы после ребута пода с промом он продолжал видеть експортер? это можно сделать с помощью конфиг мапов?

итак сейчас у меня есть пром, задеплоеный из обычного офф имаджа. в дефолтной конфигурации он не видит мой екпортер. чтобы он увидел, мне пришлось добавить в конф файл, в самом контейнере прома, кусок конфига для експортера: - job_name: 'celery-prometheus-exporter' static_configs: - targets: ['10.1.2.3:8888'] после команды kill -HUP 1 пром увидел этот экспортер. вопрос - как мне зафиксировать этот конфиг, чтобы после ребута пода с промом он продолжал видеть експортер? это можно сделать с помощью конфиг мапов?

после ребута прома он подтянет текущий конфиг

ну вот впишу, а потом под с промом рестартанет опять вписывать?

я в соседнем треде предложил вариант - вопрос в том как часто идут изменения платформы и модулей в маркетплейсе

как мне конфиг замапить в кубере жке?

от прометеуса зависит ) но ты можешь например персистировать конфиг в pvc и не париться. хотя это не правильно

он сейчас хочет получить стабильный url пода. Я написал как

Кейс. Saas сервис. Для клиента поднимается несколько контейнеров: Бекенд (yii2) Фронтенд. (Vue.js) Отдельно доступны сервисы общие доя хранения, бд и т.д. Платформарма бека и фронта может обновляться. Соотвественно контейнеры пересобираются и обновляются. Клиент из маркетплейса может себе затянуть модуль как в бекенд, так и во фронт. Поэтому по составу конейнеры у каждого пользователямогут быть разные по содержанию. Мы хотим установка модулей и обновление платформы делать через скрипты внутри контейнера и делать копии контейнера для балансировки в случае если один из них потухнет. Кто сталкивался с таким кейсом? Как лучше поступать?

урл експортера, для конфига прома, очень простой - ip_pod:port я хочу понять - можно ли както замапить конфиг прома, чтобы он лежал в какотом месте в гуглклауде, и чтобы под при рестарте подхватывал его.. это как мапинг в докере - такое можно сделать с конфиг файлами?

Платформа раз в месяц. А модули своей жизнью живут

сделай сервис дополнительно kind: Service и обращайся по имени сервиса. А сервис по селектору найдет под. Третий раз пишу

не врубаюсь - нафига мне это пока? мне конфиг, в котором обращаюсь надо сделать постоянным) а обращаться могу и по ИП пода или по ИП сервиса - это уже вторая задача

сделай сервис дополнительно kind: Service и обращайся по имени сервиса. А сервис по селектору найдет под. Третий раз пишу

даже если я это сделаю, то мне все равно надо будет править конфиг прома и указать адрес сервиса, чтобы пром увидел данные експортера. это верно?

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

нет