Хранение конфигурации Jenkins для нескольких сред

Question

Моя компания использует Jenkins в качестве исполнителя интеграционного теста.

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

В настоящее время мы храним XML-конфигурацию Jenkins в Git и вносим изменения в окружающую среду как часть нашего рецепта шеф-повара при повторном развертывании экземпляров.

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

Есть ли у кого-нибудь любимый механизм совместного использования конфигурации Jenkins в разных экземплярах при применении небольших модификаций для каждого экземпляра?

Answer 1

Я недавно натолкнулся на gradle-jenkins-plugin, который в основном расширяет Job DSL Plugin, позволяя поддерживать конфигурацию заданий в исходном управлении и применять их к серверу Jenkins через Gradle. Таким образом, вы можете легко развернуть одни и те же конфигурации на разных серверах, с небольшими изменениями, используя DSL в зависимости, например. на URL-адрес сервера Jenkins.

В качестве альтернативы, вы, вероятно, можете достичь чего-то подобного, используя новый Workflow Plugin.

Answer 2

Одним из возможных вариантов (не тестировалось меня) будет использовать Jenkins Remote Access API через обертку, как arangamani/jenkins_api_client (рубин)

Это позволило бы updating jobs удаленного экземпляра Дженкинс, изменяя только параметры, для которых нужно небольшое изменение ,

Answer 3

Вы можете сделать несколько среды CONFIGFILE с линиями, как

hostA:settings.xml:key_1:value_1A 
hostB:settings.xml:key_1:value_1B 
hostC:settings.xml:key_1:value_1C 
hostD:settings.xml:key_1:value_1D 

hostA:settings.xml:key_2:value_2A 
hostB:settings.xml:key_2:value_2B 
hostC:settings.xml:key_2:value_2C 
hostD:settings.xml:key_2:value_2D 

(выше раскладка работает, когда вы не нуждаетесь в: для ключевых/значений)

В вашем сценарии развертывания вы называете post_configure скрипт, который выберет правильные строки хоста и заменит ключи в xml (ключи найдены как <key>...</key>).
Код post_configure может быть написан на разных языках.

Пример
Когда все цели являются Linux, и открывающим и закрывающим тегом для каждого значения является одна строка 1, я хотел бы использовать Баш и код что-то вроде

grep $(hostname) multi.cfg | while IFS=: read host file key value; do 
    sed -i 's/'${key}'/'${value}'/g' ${file} 
done 

Я считаю, что это лучше чем генерация различных распределений для разных систем.