Вопрос именно в этом, работал или нет?)

Да никак не могу прицепить свой ServiceMonitor

А что именно не получается? Я первый раз по их доке на coreos все делал, вроде все ок

Может с labels намудрил чего то?

Может. В deployment и сервисе стоит labels: exporter: clickhouse в ServiceMonitor selector: matchLabels: exporter: clickhouse namespaceSelector: any: true Создаю в namespace где и пром, monitoring. После добавления operator в логах пишет "updating config skipped, no configuration change"

А в ServiceMonitor прописываешь label, которые ждет kind: Prometheus?

Ставил через helm coreos/kube-prometheus, на сколько я понял, по умолчанию SerivceMonitorSelector пустой, что означает что он должен дискаверить все ServiceMonitor

Кинул в личку свой пример. Про "дискаверить все ServiceMonitor" - не понмю, кажется я не пробовал. Я сразу label прописвывал

Всем спасибо, всё взлетело

Так а в чем проблема-то была? Интересно же)

Так а в чем проблема-то была? Интересно же)

Пока хз, но прописал в values файл то же самое и взлетело. Грешу на метки, узнаю уже в понедельник

Окееей. Спасибо

привет, настраиваю tls bootstrapping для кублетов и не работают ни logs ни exec, валятся с ошибкой: x509: certificate signed by unknown authority

как это поправить?

ну если вы хельм не хотите) пушьте ямлик, и смотрите пока все не станет Running, обновлением инфы раз в сколько то сек))

Вот кстати интересно. Деплою через bamboo, как узнать статус успешно прошел деплой или нет ? Сейчас деплою через yaml. Например возникает следующая ситуация yaml принят успешно, но допустим есть ошибка в коде и под валится после старта. И узнаю я об этом только от прометея. Helm может как то решить эту проблему ? Ну что бы я в выхлопе деплоя в bamboo выдел что что-то пошло не так ?

Вот кстати интересно. Деплою через bamboo, как узнать статус успешно прошел деплой или нет ? Сейчас деплою через yaml. Например возникает следующая ситуация yaml принят успешно, но допустим есть ошибка в коде и под валится после старта. И узнаю я об этом только от прометея. Helm может как то решить эту проблему ? Ну что бы я в выхлопе деплоя в bamboo выдел что что-то пошло не так ?

Добавить еще один таск с тестами?

Добавить еще один таск с тестами?

Ну не знаю... сам по себе pull образа из реджестри может быть долгим ... Хотя вполне вариант , спасибо за идею

Добавить еще один таск с тестами?

а откуда этот таск узнает что всё что надо раздеплоилось?

и что надо тест запустить

а кто-то настраивал у себя tls bootstrapping?

и что надо тест запустить

Сделать N retry’ев c интервалом в секунд 10

и что надо тест запустить

Ну он может быть последним в списке. И соответсвенно из переменных окружения будет знать какой под чекать

Сделать N retry’ев c интервалом в секунд 10

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

можно отдавать release через nginx

это теория или сам так делал?

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

можно отдавать release через nginx

Ну release может и от старого придти...

а новое может вообще не запуститься например

ну короче смысл делать такой тест если всё равно прометей есть, который по сути частично этот тест дублирует

Ну release может и от старого придти...

Не вижу проблем. N попыток в надежде получить текущий релиз

ну короче смысл делать такой тест если всё равно прометей есть, который по сути частично этот тест дублирует

Разработчикам типа проще сразу узнавать о заваленом деплое )))

ну вот если добавить подобный тест, то лаг будет в пределах интервала опроса прометея, то есть не больше 1 минуты (обычно)

смысл подобный тест тогда заводить вообще

Чтобы валился деплой

а не за метриками лезть

Можно и тест сделать на базе метрик прометея. Тут кто как хочет так и ...

так он и свалится

вопрос в том, откуда ты про это узнаешь

Почему он свалится?

> как узнать статус успешно прошел деплой или нет ? > Например возникает следующая ситуация yaml принят успешно, но допустим есть ошибка в коде и под валится после старта. И узнаю я об этом только от прометея. из задачи

Еще до того как заехали в k8s деплоили в докер контейнерами. Ну и в момент когда выполнялся docker start $name, наступал момент истины. Все к этому как то привыкли ) А теперь еще после успешного деплоя нужно еще и чятик мониторинга посмотреть )

Кстати, тоже вариант. Узнавать у куба что там с текущей выкаткой, не ушел ли контэйнер в loop

Кстати, тоже вариант. Узнавать у куба что там с текущей выкаткой, не ушел ли контэйнер в loop

Кстати да 👍

Вот кстати интересно. Деплою через bamboo, как узнать статус успешно прошел деплой или нет ? Сейчас деплою через yaml. Например возникает следующая ситуация yaml принят успешно, но допустим есть ошибка в коде и под валится после старта. И узнаю я об этом только от прометея. Helm может как то решить эту проблему ? Ну что бы я в выхлопе деплоя в bamboo выдел что что-то пошло не так ?

Кстати, почему bamboo? У нас сейчас он, но с появлением куба уже посматриваю налево.

технически в кубере есть хуки: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/

Они ж сейчас только в последних версиях сделали файл с описанием действий как у всех

но я их не юзал

Кстати, почему bamboo? У нас сейчас он, но с появлением куба уже посматриваю налево.

Мы весь стек атласиан юзаем... удобная типа интеграция...) А на что смотрите ?

Да у меня тоже весь, тоже интеграция…

В деплойменте есть такой параметр: spec: progressDeadlineSeconds: 180 С ним kubectl rollout status возвращает ошибку, если деплоймент не смог подняться по завершении этого таймаута. А дальше баш. Пример для гитлаба. Для самого деплоя используется set image, но apply -f ничем не будет отличаться - kubectl set image deployment/$CI_PROJECT_NAME *=$REPOSITORY_URL/$CI_PROJECT_NAME:$CI_COMMIT_REF_SLUG.$CI_PIPELINE_ID --namespace production - kubectl rollout status deployment/$CI_PROJECT_NAME --namespace production || (kubectl rollout undo deployment/$CI_PROJECT_NAME --namespace production && exit 1)

а в helm? helm status … -o json | grep ?

А в helm есть ключ --wait. С ним helm upgrade будет ждать пока не поднимутся все поды. А по истечении таймаута вернет ошибку. И можно сделать helm rollback.

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

О, спасибо!

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

На счет всех не скажу: jira/confluence/crowd по мне так отличные продукты

ух даже так, ок лучше не буду начинать

Bamboo да, пока только догоняет остальных

хуже confluence не видел вики

жира ок, но жыр

Давайте не будем уходить в «дистро срач»)

из моих наблюдений ниша деплоя и потом (что мне еще более интересно) какого-то дашборда где бы показывало какая версия микросервиса продеплоена в каком энвайроменте не заполнена

Можно такое на графане собрать

есть какие-то хрени прикрученные сбоку - гитбал интеграция и спиннакер

обе более чем ущербны

и похоже что пока все велосипедят кто как может :( я думаю скоро тоже буду писать свой велосипед на эту тему

Я пока описываю сборку/деплой в makefile. Позволяет унифицировать разные проекты с разными схемами деплоя (k8s, docker-compose, capistrano) и переезд между разными ci/cd не страшный. Можно хоть локально задеплоить

и похоже что пока все велосипедят кто как может :( я думаю скоро тоже буду писать свой велосипед на эту тему

+1

Тут еще были разговоры по поводу определения успешности деплоя через прометеус. Посмотрите эту штуку. Уже все готово. https://github.com/ContainerSolutions/helm-monitor

Шикарно, спасибо!

интересно

Я пока описываю сборку/деплой в makefile. Позволяет унифицировать разные проекты с разными схемами деплоя (k8s, docker-compose, capistrano) и переезд между разными ci/cd не страшный. Можно хоть локально задеплоить

а какой профит от makefile? почему не просто на баш?

но завязка на хельм

Ну я и так в сторону хельма поглядываю.

лишняя зависимость и весьма opionated идея делать все что попадется под руку (в данном случае деплоить) мейкфайлом

лишняя зависимость и весьма opionated идея делать все что попадется под руку (в данном случае деплоить) мейкфайлом

+1

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

а потом контейнер не стопается (мейкфайл там оборачивает все в шелл команды вот это все)

а какой профит от makefile? почему не просто на баш?

Зачем велосипедить, когда есть стандарт? make deploy-dev и все

А можно поподробнее? а то что-то посоны и не в курсе про стандарт деплоить мейкфайлами

фабриком надо

fab deploy и вот это всё