Як створити резервну копію вакансій і головних конфігурацій Jenkins?


56

Я хотів би створити резервну копію всіх завдань і налаштування файлів Jenkins. Який найпростіший спосіб зробити це?


Що ви спробували?
030

1
Я спробував це .
kenorb

Відповіді:


33

Існує багато способів зробити це, але найпростіший спосіб, на який я думаю, це зробити резервну копію папки Jenkins Home.

Ви можете побачити, де знаходиться ваш дім з Дженкінсом:

echo $JENKINS_HOME

Наприклад, якщо ви хочете створити резервну копію завдань, ви можете перейти до:

cd $JENKINS_HOME/jobs

І зробіть резервну копію для цієї папки.

Вся ця конфігурація буде купою файлів XML .

Якщо ви використовуєте офіційне зображення докера Jenkins , дім буде ввімкнено:

/var/jenkins_home

2
Мені потрібно було перейти на користувача jenkins, щоб мати доступ до $JENKINS_HOMEзмінної середовища:, sudo su -s /bin/bash jenkinsа потім echo $JENKINS_HOME, що для мене було/var/lib/jenkins
Брайс Гінта

2
Проблема резервного копіювання «робочих місць» всієї папки полягає в тому, що також викопіюються виконання завдань - це може означати багато ГБ.
Майк Аргіріу

Чи варто перезапускати службу Дженкінса?
Сінь Менг

Додому Дженкінса в MacOS (встановлення за замовчуванням Homebrew): ~ / .jenkins
chuckSaldana

30

Усі завдання ( jobs/) та основні файли конфігурації ( config.xml) можна знайти в домашній папці Jenkins ( JENKINS_HOME) у такій структурі:

JENKINS_HOME
 +- config.xml     (jenkins root configuration)
 +- *.xml          (other site-wide configuration files)
 +- userContent    (files in this directory will be served under your http://server/userContent/)
 +- fingerprints   (stores fingerprint records)
 +- plugins        (stores plugins)
 +- workspace (working directory for the version control system)
     +- [JOBNAME] (sub directory for each job)
 +- jobs
     +- [JOBNAME]      (sub directory for each job)
         +- config.xml     (job configuration file)
         +- latest         (symbolic link to the last successful build)
         +- builds
             +- [BUILD_ID]     (for each build)
                 +- build.xml      (build result summary)
                 +- log            (log file)
                 +- changelog.xml  (change log)

Більшість конфігурацій у форматі XML, тому резервного копіювання всіх .xmlфайлів повинно бути достатньо.

Усі налаштування, журнали збирання, артефакти архівів зберігаються в каталозі JENKINS_HOME. Просто заархівуйте цей каталог, щоб створити резервну копію. Так само відновлення даних - це просто заміна вмісту каталогу JENKINS_HOME із резервної копії.

Резервні копії можна зробити без зупинки сервера, але коли ви відновите, будь ласка, зупиніть його.


Для послідовних резервних копій добре зберігати JENKINS_HOMEкаталог у репозиторії Git.

Наприклад:

cd $JENKINS_HOME
git init
shopt -s globstar
git add **/config.xml
git commit -m'Added job config files' -a

і переміщення файлів до зовнішнього сховища. Ви також можете додати наступний .gitignoreфайл, щоб ігнорувати деякі файли.

Пов’язано: Чи існує спосіб збереження файлів конфігурації Хадсона / Дженкінса у контролі джерел?


Як часто ви створюєте резервну копію? Ви автоматично натискаєте код до сховища git? Якщо це правда, ви створюєте Запит на витяг, який потрібно об'єднати вручну (вручну втручання), щоб зробити перевірку цілісності резервного копіювання?
030

2
@ 030 Зазвичай після внесення значних змін вручну, коли я знаю, що конфігурація стабільна, і мені потрібно створити резервну копію, оскільки Дженкінс часто любить ламати речі, такі як зміна рабів з Unix на Windows самостійно, видалення паролів з форм, так маючи їх у git / GitHub, я можу легко порівняти та знайти відсутні дані та додати їх назад або відновити якийсь конкретний файл. Є кілька плагінів, щоб зберегти зміни історії, але я не вважаю це корисним.
kenorb

Ви зберігаєте паролі в git? Ви їх шифруєте? Чи використовуєте ви також трубопроводи aka Pipeline як код?
030

3
@ 030 Jenkins за замовчуванням шифрує паролі / облікові дані, але ви можете їх легко розшифрувати . Однак без головного ключа (який не повинен бути частиною резервного копіювання) або доступу до Дженкінса ніхто більше не може. Я не використовую Pipeline як код.
kenorb

Як ви перевіряєте цілісність цієї резервної копії в git? Наприклад, ви закручуєте віртуальну машину чи докерську систему, монтуєте git repo і перевіряєте, чи все ще працює?
030

11

Якщо ваші завдання Jenkins визначені в Jenkinsfile, ви можете зберігати його у сховищі git і завантажувати його за допомогою Pipeline .

На жаль, оскільки не всі плагіни Jenkins підтримують Jenkinsfile та Pipeline, вам потрібно буде вручну створити нові Jenkinsfiles, якщо ви хочете перенести існуючі завдання до цього формату.


9

SCM синхронізації конфігурації Plugin робить саме те , що ви хочете. Працює з svn або git, щоб створити резервну копію ядра і конфігурації роботи, тому ви можете легко відстежувати, хто вносив зміни, а також резервну копію.


1
Я буквально націлюю папку $ JENKINS_HOME, але це здається набагато кращим.
MrMesees

2
Ці плагіни здаються досить неактивними / мертвими - чи це дійсно функціонально і нарівні станом на 2017 рік?
Tuukka Mustonen

5

Є кілька способів резервного копіювання даних джинкінів та майстерних конфігурацій. Найкращий спосіб резервного копіювання - використовувати плагін Thinbackup. Ви можете планувати своєчасне створення резервних копій за допомогою виразів cron. Ви також можете налаштувати повне резервне та додаткове резервне копіювання.

Ще один спосіб резервного копіювання даних та налаштування - це зробити знімок диска вашого майстерного сервера jenkins. Ідеальний спосіб зробити це, встановивши диск і з'єднавши каталог конфігурації jenkins до точки кріплення диска

Обидва сценарії добре пояснені в цій публікації блогу . Ви отримаєте кращу ідею та кроки щодо конфігурацій.


3

Я використовую сценарії від sue445/jenkins-backup-script.

Він архівує настройки Дженкінса та плагіни, такі як:

  • $JENKINS_HOME/*.xml
  • $JENKINS_HOME/jobs/*/*.xml
  • $JENKINS_HOME/nodes/*
  • $JENKINS_HOME/plugins/*.jpi
  • $JENKINS_HOME/secrets/*
  • $JENKINS_HOME/users/*

Використання

./jenkins-backup.sh /path/to/jenkins_home archive.tar.gz

# add timestamp suffix
./jenkins-backup.sh /path/to/jenkins_home backup_`date +"%Y%m%d%H%M%S"`.tar.gz

3

Ви можете спробувати плагін thinBackup (навіть якщо він не підтримується активно) [якщо використовувати логічну резервну копію - все, що вам потрібно] (тобто більшість конфігураційних файлів xml, завдання, вузли тощо). Розмір резервного копіювання не буде величезним.


1

Мені потрібно було перенести Дженкінса з одного екземпляра Windows Server на інший. Нарешті мені вдалося зробити це так:

  • Зупиніть послугу Дженкінса (якщо ви можете собі це дозволити)
  • Скопіюйте всю папку Дженкінса (за замовчуванням C:\Program Files x86\Jenkins)
  • Вставте новий екземпляр
  • Зайдіть всередину каталогу і запустіть jenkins.exe install

Це зареєструє свіжозаклеєний Дженкінс як послугу на новій машині і буде працювати на 100% те саме.

Якщо це працює, тоді, якщо вам потрібна резервна копія лише для майбутньої безпеки, скопіюйте десь папку Дженкінса. Це буде працювати як знімок.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.