Как запускаются пайплайны и где выполняются

В предыдущем посте я уже по сути описал, как запускаются пайплайны: в каждой job указывается триггер, когда он срабатывает, все job собираются в кучу, выстраиваются в порядок и погнали.

Где выполняются пайплайны, а точнее сами job?

Чтобы ответить на этот вопрос, нужно накинуть немного контекста. Вот у нас есть сервер с CI, он рисует web-интерфейс, следит за git, отвечает за функционал создания МРов, запускает и создает пайплайны — всё такое. На этот сервер выделены какие-то ресурсы, т.е. он крутится на какой-то машине. И очень важно, чтобы сервер с CI был подобен алкашу в 21:59 – максимально быстрым.

Возвращаемся к Job. Для выполнения Job нужно определенное окружение. Если мы собираем Android-приложение, нужно, чтобы там, где выполняется Job со сборкой, была установлена JDK, а еще Android SDK, ну и желательно уже скачанный Gradle, чтобы не скачивать каждый раз. Помимо этого, сборка больших приложений — это очень дорого по памяти, нужно, чтобы её было много.

Если у нас более-менее большая команда, то будет создаваться много МРов. И вместе с этим будет запущено большое количество Job. Нам важно, чтобы сервер с CI не тормозил, и при этом чтобы сборкам хватало памяти и процессора. Для этого мы выполнение самих Job выносим на другие машины.

Выглядит это так: мы берем какой-то сервер, устанавливаем на него специальное ПО, которое называется Runner (он же агент в TeamCity). Всё, что делает этот Runner — коннектится к серверу CI как к материнскому кораблю и ждет команды. Когда CI нужно запустить какой-то пайплайн, она помещает список Job в очередь. Runner'ы, которые сейчас не заняты, забирают задачи из этой очереди и начинают выполнять Job.

Очень красивая система, которая позволяет масштабировать нашу инфраструктуру горизонтально. Поэтому даже если у нас будет создано огромное количество пайплайнов, это никак не повлияет на сервер CI. И мы можем в зависимости от нагрузки добавлять или убирать лишние Runner'ы. При этом мы еще и решаем проблему того, что например iOS приложение очень желательно собирать на Mac, а не linux машинах.

Осталась только проблема с окружением, и решается она крайне просто. У нас есть готовый Docker-образ с JDK, Android SDK и всем, что нам нужно для сборки. Когда Runner начинает выполнять Job, он сначала скачивает нужный образ (какой образ использовать, мы указываем в самой Job) и затем запускает нужные скрипты уже в рамках этого образа.