Вжух и собралось или как я ускорял сборку UI на базе kubernetes + jenkins и yarn + nx

[vitaly_il1]

Спасибо, интересно!

1) К сожалению, на первом скрееншоте нет тайминга всех ступеней pipeline. Что было самое тяжелое?

2) А всесто распараллеливания по десятку подов вы не пробовали scale up (запускать на мощном сервере)?

[softError]

Добрый день, спасибо за комментарий!
1) Да, прошу прощения, не нашел как в дженкинсе отобразить время выполнения всех шагов для наглядности. Самые тяжеловесные это тесты jest и enzyme + linting тоже не всегда легковесный и занимает достаточно времени
2) Совсем забыл в статье упомянуть какая еще проблема решалась. Стабильность. В такой сборке довольно непросто контролировать память и кол-во порождаемых сборщиком процессов. А так-как мы вращаем все сборки в k8s на одном пуле машин, то мы явно задаем лимиты для пода по используемой памяти. Ответ на вопрос - да, сначала так и делали, но на больших сборках тесты были нестабильные и часто валились по OOM, т.к. на больших сборках часто выставлялись большие значения --parallel , чтобы хоть как-то ее ускорить. На самом деле после рефакторинга стоит переосмыслить такой вариант и как-то гибко распределять тяжеловесные задачи по более мощным инстансам, которые можно поднимать по требованию. Спасибо за идею!

[dexec]

Cпасибо за статью. Впервые вижу практическое использование jenkins внутри kubernetes (до этого на хабре было пару статей о том как развернуть jenkins внутри k8s).
Подход с minio внутри кластера выглядит интересным и перспективным, по-моему опыту он вполне прост в поддержке, жалко что автор не провел эксперименты с ним, есть ли в планах какое-либо использование minio?

[softError]

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

[yzhar]

Вообще минио можно использовать для различных целей :) Например в нашей компании мы его используем как прокси кэш для докер образов. Очень полезно, особенно для кластеров со spot instances

[rewlad]

Еще можно rsync использовать, особенно при долгоживущем поде и инкрементальной сборке.
Иногда удобно rsync через kubectl, хотя нагрузка на апи-сервер заметно растет.

[softError]

Спасибо, интересная идея! Надо бы протестировать. Через kube-api идея сразу отвалилась, т.к. он и так достаточно нагружен (crossplane и еще всякое). Еще не уверен, насколько сильно rsync ударит по iops, т.к. мы все таки это не в in-memory храним, а перегнать надо в сумме около 1 Гб мелких файлов. Если доберусь - обязательно отпишусь о результатах.