Одновременные сборки Jenkins на подчиненных докерах

У меня есть Jenkins Server (2.204.1) с плагином Docker (1.1.9) и облачным API докеров.

Я работаю с агентами докеров Jenkins (подчиненными). И я сопоставляю рабочую область сборки подчиненного докера между контейнером и хостом, чтобы иметь возможность направлять артефакты к последующим заданиям.

в конфигурации Jenkins - Сведения об облаке Docker - Настройки контейнера:

Volumes /var/lib/jenkins:/var/lib/jenkins

Это отлично работает для одной сборки. Проблема начинается, когда я запускаю параллельные сборки. Все они отображаются в одной рабочей области на хосте Docker и мешают друг другу. Что было бы лучше всего при использовании подчиненных докеров и отображении рабочего пространства в качестве тома?

Я бы не хотел использовать $ CustomWorkspace или копировать артефакты во время сборки, так как ими сложно управлять и очищать. Я предпочитаю обычный подчиненный подход Jenkins для добавления @ 2 во вторую параллельную сборку, но это не поведение при запуске параллельных сборок на подчиненных докерах.


jenkins jenkins-plugins jenkins-pipeline jenkins-docker
person Jeronimo    schedule 18.05.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Один удаленный агент Jenkins не может узнать, используется ли данный каталог рабочей области другим агентом, работающим на том же компьютере. Это в равной степени верно и для агентов на основе докеров, которые совместно используют общий каталог посредством монтирования тома. В идеале все агенты, работающие с одной машины, должны иметь какой-то способ общения друг с другом, чтобы не наступать друг другу на ногу (например, файл блокировки в рабочей области, который удаляется при завершении задания), но в настоящее время это не так.

Решение №1: уникальные рабочие области для сборки

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

agent {
    node {
        customWorkspace "${env.BUILD_NUMBER}"
    }
}

Ссылка: https://www.jenkins.io/doc/book/pipeline/syntax/#agent

Решение # 2: уникальные рабочие области агента

Если это невозможно или нежелательно, другое потенциальное решение - изменить корневой рабочий каталог самого агента Jenkins, что можно сделать, предоставив дополнительный аргумент команде запуска агента:

-workDir FILE : Declares the working directory of the
                remoting instance (stores cache and logs by
                default)

Источник: java -jar agent.jar -help

При динамическом развертывании нескольких агентов на одной машине, мы можем установить для этого значения -workDir что-то с немного большей уникальностью, чтобы дать каждому агенту свой собственный каталог для работы, эффективно уменьшая конфликты рабочих пространств. Что-то вроде этого должно работать хорошо:

java -classpath agent.jar hudson.remoting.jnlp.Main -headless \
     -workDir /var/lib/jenkins/workspace/$(date +%3N) ...

Магия заключается в $(date +%3N), который возвращает наносекунды системных часов с точностью до трех цифр. Мы можем захотеть использовать больше или меньше цифр, потому что есть компромисс: большая точность приведет к большему максимальному количеству каталогов рабочей области, но уменьшит риск конфликтов рабочей области; меньшая точность будет иметь противоположный эффект - меньше каталогов, увеличится риск столкновения.

Настройка этой команды будет зависеть от вашей настройки Jenkins. Например, мы используем плагин Docker Swarm (v1.9) в Jenkins 2.249.3. . Наша команда агента настраивается в разделе «Управление Jenkins» ›› Управление узлами и облаками ›› Настройка облаков ›› Конфигурация облака Docker Swarm ›› Шаблоны агента Docker ›› Команда.

Ссылка: https://man7.org/linux/man-pages/man1/date.1.html

person Ben Amos    schedule 20.05.2021