Comments 5
Классная статья, спасибо!
а как организовали вывод логов из проблемных подов в pipline?
Если вкратце, после того как запустили helm upgrade --install, скачиваем на раннер скрипт kubectl_show_error, который ищет есть ли в развернутом неймспейсе поды с ошибками:
PROBLEM_PODS="kubectl get pods -n " class="formula inline">ENV_NAME -o jsonpath='{range .items[]}{.status.containerStatuses[].ready} {.metadata.name} {end}' | grep "false" | rev |cut -d ' ' -f1 | rev )"
И далее выводим лог ошибочного пода в вывод раннера который и отобразит это в пайплайне. Пример такого вывода:
Надеюсь в следующем году опубликуем еще пару статей по поводу того как у нас устроена архитектура пайплайнов в части билдов/сборок чартов/деплойментов, там есть много интересного о чем рассказать.
Всё гениальное просто) спасибо большое.
Обычно же после окончания helm upgrade --install под удаляется если не смог нормально подняться, как тогда получаете их логи?
Можете по шагам объяснить когда запускаете ваш скрипт ?
Выполняется upgrade, не ожидания окончания обновления, проверяется namespace на наличие ошибок и проблемных подов, и если такие поды есть их логи выводим в в лог пайплайна. По-сути процес похож на ручной дебаг, когда запустили helm и с помощью kubectl проверяем все ли раскатывается правильно и без ошибок. Надеюсь в ближайшее время выпустим серию статей, про устройству нашего CI/CD. Там более наглядно разберем такие моменты и как они помогают жизни разработчика/тестировщика.
Оптимизация DevOps: Как персональные стенды и Grafana улучшают разработку и мониторинг