Как я могу изменить поведение балансировки нагрузки, используемое Jenkins для управления ведомыми устройствами?

Мы используем Jenkins для нашей системы сборки CI. Мы также используем "параллельные сборки", чтобы Дженкинс самостоятельно строил каждое изменение. Это означает, что мы часто имеем 5 или 6 сборок одной и той же работы, выполняемой одновременно. Для этого у нас есть 4 подчиненных с 12 исполнителями.

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

Есть ли плагин или что-то, что изменяет поведение балансировки нагрузки, используемое Jenkins для управления его подчиненными устройствами?

ОТВЕТЫ

Ответ 1

Если вы не нашли плагин, который делает это автоматически, вот идея о том, что вы можете сделать:

  • Установите Node Плагин параметров метки.
  • Добавьте параметр SLAVE к вашим заданиям
  • Ограничить выполнение заданий на ${SLAVE}

  • Добавьте триггерное задание, которое сделает следующее:

    • Проанализируйте распределение нагрузки через Систему Groovy Script и выберите, для чего node, чтобы начать следующую сборку.
    • Отправляем сборку на node с Параметрированный триггер плагин задав соответствующее значение параметру SLAVE.

Для анализа распределения нагрузки вам необходимо установить Groovy плагин и ознакомиться с API основного модуля Jenkins. Вот несколько полезных начальных указателей.

Ответ 2

Мы столкнулись с подобной проблемой. Поэтому я собрал плагин, который изменяет Load Balancer в Jenkins, чтобы выбрать node, который в настоящее время имеет наименьшую нагрузку - https://wiki.jenkins-ci.org/display/JENKINS/Least+Load+Plugin

Приветствуется любая обратная связь.

Ответ 3

Если ваши машины сборки не могут с комфортом обрабатывать более 1 сборки, зачем их настраивать с 12 исполнителями? Если это действительно так, вы должны уменьшить количество исполнителей до 1. Мой Jenkins имеет 30 подчиненных, каждый с 1 исполнителем.

Ответ 4

Вы также можете использовать плагин Throttle Concurrent Builds, чтобы ограничить, сколько экземпляров задания может выполняться параллельно на одном и том же node

Ответ 5

У меня есть две метки - одна для небольших задач и одна для больших задач. У меня есть один исполнитель для большой задачи и 4 для небольших задач. Это немного уравновешивает вещи.