ну вот если добавить подобный тест, то лаг будет в пределах интервала опроса прометея, то есть не больше 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 и вот это всё

Не стандарт деплоить, а сами формат и описание стандартизированы

gnu make?

ну это из раздела когда знаешь молоток то вокруг видишь только гвозди

да ладно, мейк не так уж плох

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

нафиг. питон тащить, или в случае с capistrano ruby с нужными модулями

ну то есть плох, но не фатально

на прошлой работе у нас был мейкфайл на 3к строк, он там еще другие инклюдил, какие-то запрашивал данные ввести и т.п. - бррр

давно ядро собирал сам? %)

Вы не поверите, но почти весь софт из сорцов через него и собирается

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

так собирается - я только за, затем его и придумали

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

но юзать его для других задач...

в лучшую сторону

деплойте zsh'ем!

Кто их плодит то? Я лучше makefile прочитаю, чем чужой башник

да, все станет лучше с мейкфайлом ?

нету "стандарта для деплоя", поэтому все делают свои костыли

кто на чём умеет

make, bash, fabric, самодельный-костыль

Я ж молчу про простыни для сборки jenkins’ом

Кто их плодит то? Я лучше makefile прочитаю, чем чужой башник

вы бы другие технологии лучше бы освоили

например?

в гитлабе удобно собирать

да в куб деплоить ведь одна команда kubectl ...

в гитлабе удобно собирать

А локально можно собрать?

ну может еще статус получить в цикле или еще как, зачем же тут мейкфайл или еще что-то?

А локально можно собрать?

собери, кто ж тебе запретит?

например?

http://fqa.9front.org/fqa1.html

А если вы завтра захотите сменить gitlab на drone/еще чего-то?

зачем?

может ещё на атлассиан битбакет?

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

у меня в каждом проекте обычно два баш файла build и test, один собирает контейнер (multistage build чаще всего) второй тестирует, можно запустить локально а можно на гитлаб, юзаю докер раннер и динд сервисом - локально ничего кроме докера не нужно

http://fqa.9front.org/fqa1.html

Это уже пятничные подколы пошли?

ну гитлаб останется гитом

ну и из его ci можно будет подёргать что тебе удобнее

оттуда и хельм можно потрогать и твои makefile'ы

и его конфиг в сто раз проще дженкинса (хотя технически менее фичаст)

никаких мейкфайлов и прочих лишних зависимостей не надо ни локально ни в гитлаб раннере

Это уже пятничные подколы пошли?

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

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

по-умолчанию там было -j1 всю дорогу

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

(но другие более удобные велосипеды я трогать не буду потому что боюсь неизвестного)

Это Ваши додумки, я такого не говорил и сейчас как раз в планах поюзать что-то кроме bamboo

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

Не следует множить сущее без необходимости (14 век)

а хашикорп номад раньше появился чем кубер вроде?

Множить: это обернуть это все в fab, как пошутили выше)