Представляем Warm Agents — плагин для TeamCity

Новости и релизы TeamCity

Представляем Warm Agents, плагин для TeamCity

Ожидание «поиска свободного агента» особенно раздражает, когда вам нужно просто запустить тесты для PR. Больнее всего, когда быстрая минутная сборка висит в очереди десять минут, пока запускается медленный облачный инстанс Windows.

Плагин Warm Agents — наш ответ на эту задержку.

С этим плагином TeamCity поддерживает заданное количество простаивающих, предварительно запущенных агентов для конкретного облачного образа. Как только число свободных агентов падает ниже целевого, TeamCity немедленно подготавливает новый — гарантируя, что сборки начнутся сразу после поступления в очередь. Плагин работает с любым облачным провайдером, поддерживаемым TeamCity.

Есть только один момент, который нужно учесть заранее. Каждый работающий «теплый» агент потребляет лицензию агента сборки, а простаивающие облачные инстансы по-прежнему стоят денег у вашего провайдера. «Теплые» агенты обменивают стоимость на снижение задержки, поэтому выбирайте целевое значение, исходя из того, сколько времени ожидания в очереди вы действительно хотите сэкономить.

Предварительные требования

• TeamCity 2024.12.3 или более поздняя версия.
• Облачный профиль и облачный образ, настроенные в проекте.
• Разрешение «Manage project’s agent cloud profiles», предоставленное в проекте.
• Установленный и включенный плагин Warm Agents.

Чтобы начать работу с плагином, перейдите в Admin | Plugins, нажмите Browse plugins repository и найдите Warm Agents в списке JetBrains Marketplace. Установите и включите его.

Как только плагин заработает, используйте вызовы REST API для настройки «теплых» агентов. В этой статье показано, как это сделать с помощью teamcity-cli, самого удобного способа управления сервером из терминала. Если вы предпочитаете вызывать эндпоинты напрямую, ознакомьтесь с нашим руководством по быстрому старту REST API и примерами запросов в репозитории.

Настройка

Чтобы поддерживать десять свободных агентов готовыми для облачного образа, выполните:

Чтобы прекратить поддержку «теплых» агентов для образа, установите target=0.

Если для вашего облачного образа настроен жесткий лимит общего количества работающих агентов, TeamCity будет его соблюдать, хотя установить целевое значение выше лимита все еще возможно.

Чтобы проверить конфигурацию, выполните:

Альтернативно перейдите в Project Settings | Integrations | Warm Agents:

TeamCity отслеживает количество свободных агентов для образа и запускает новые инстансы, как только их число падает ниже целевого. Обратите внимание, что инстансы запускаются группами с небольшими задержками между ними, поэтому для достижения высокого целевого значения может потребоваться время.

Чтобы найти ID, используемые выше, воспользуйтесь teamcity-cli или REST API:

• teamcity project list
• teamcity project cloud profile list --project <projectExternalID>
• teamcity project cloud image list --project --profile Используйте только имя: teamcity-linux-aws-a (lt-0cd4ecf32d77770a9) -> teamcity-linux-aws-a
• Используйте только имя: teamcity-linux-aws-a (lt-0cd4ecf32d77770a9) -> teamcity-linux-aws-a

Альтернативно откройте страницу облачного профиля на вашем сервере и считайте ID из URL: ищите projectId=My_Project и profileId=amazon-123 в адресе вида my.teamcity.com/admin/editProject.html.

Расширенное использование

Спрос на «теплых» агентов редко остается неизменным. Поддержание агентов в «теплом» состоянии ночью может привести к напрасной трате ресурсов, поэтому функция создана для частого изменения целевых значений. TeamCity мгновенно подхватывает новую цель и адаптируется, запуская больше или меньше агентов. Изменение цели никогда не влияет на уже работающих агентов — TeamCity не останавливает инстансы принудительно при уменьшении масштаба. Конфигурация «тайм-аута простоя» (idle timeout) вашего облачного образа по-прежнему применяется, хотя TeamCity может перезапустить некоторые инстансы, которые только что отключились, чтобы поддерживать количество агентов.

Очевидное применение — расписание. Настройте сборку с триггером по расписанию, который снижает целевое значение на ночь и восстанавливает его утром. На Kotlin DSL:

Сохраните warmAgents.token как параметр типа password, чтобы значение оставалось скрытым в логах сборки.

И триггер:

Добавьте второй триггер с target=0 для вечера. Полный пример смотрите в этом репозитории.

Разделение на день и ночь — распространенный случай, но ваш рабочий процесс может требовать иного подхода. Чтобы увидеть, как на самом деле колеблется спрос, плагин предоставляет небольшой набор метрик:

При настройке с несколькими узлами добавьте cookie X-TeamCity-Node-Id-Cookie=<main-node-id>, чтобы закрепить запрос за главным узлом, который собирает метрики.

Плагин вычисляет метрики использования и насыщения для каждого настроенного облачного образа, показывая, насколько заняты ваши агенты и насколько хорошо они справляются с очередью. Метрики выводятся в формате Prometheus, поэтому вы можете собирать их с течением времени и видеть пики спроса. Минимальная конфигурация Prometheus доступна в качестве примера.

Поделитесь своим мнением

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