Как сделать резервное копирование и восстановить ваш экземпляр Jenkins
Создавайте резервные копии и восстанавливайте Jenkins безопасно, архивируя JENKINS_HOME, сохраняя секреты и тестируя восстановление до того, как это понадобится.
Как создать резервную копию и восстановить экземпляр Jenkins
Jenkins часто становится управляющей плоскостью для ваших сборок, развертываний, учетных данных и истории релизов. Если вы потеряете $JENKINS_HOME из-за сбоя диска или неудачной миграции, ваши конвейеры CI/CD могут остановиться, даже если сам пакет Jenkins легко переустановить.
Это руководство показывает, что нужно резервировать, как безопасно создать архив файловой системы и как восстановить Jenkins, не нарушая учетные данные или права на файлы.
Понимание основ: каталог $JENKINS_HOME
Каждый экземпляр Jenkins полагается на единый корневой каталог, называемый $JENKINS_HOME. Этот каталог содержит все файлы конфигурации, плагины, журналы и данные заданий. Резервное копирование Jenkins по сути означает резервное копирование содержимого этого каталога.
В зависимости от способа установки (например, пакет Linux, контейнер Docker) расположение $JENKINS_HOME обычно варьируется:
- Linux (установка из пакета):
/var/lib/jenkins - Docker: Часто монтируется в том, например,
/var/jenkins_home - Автономный JAR: Каталог, в котором был запущен процесс Jenkins, если не указано иное через переменные окружения.
Определение критически важных компонентов данных
Хотя резервное копирование всего каталога $JENKINS_HOME является самым простым подходом, это может привести к очень большим архивам, если включены история сборок и данные рабочей области. Для быстрого и эффективного резервного копирования на случай аварийного восстановления необходимо убедиться, что захвачены следующие каталоги и файлы:
| Компонент | Путь внутри $JENKINS_HOME |
Назначение |
|---|---|---|
| Глобальная конфигурация | config.xml |
Основной файл конфигурации корневого экземпляра Jenkins. |
| Определения заданий | jobs/ |
Содержит подкаталоги для каждого настроенного задания, каждый со своим config.xml. |
| Пользователи и учетные данные | users/ и credentials.xml |
Учетные записи пользователей, настройки области безопасности и сохраненные секреты. |
| Ключи безопасности | secrets/ |
Ключи шифрования, необходимые для расшифровки конфиденциальных данных, таких как сохраненные учетные данные. |
| Список плагинов | plugins/ |
Содержит файлы .hpi для всех установленных плагинов. |
| Определения узлов | nodes/ |
Конфигурации всех подключенных агентов сборки (если определены). |
Метод 1: Резервное копирование файловой системы (рекомендуется)
Самый надежный метод резервного копирования Jenkins — создание согласованного сжатого архива необходимых файлов при временной остановке службы.
Шаг 1: Остановите службу Jenkins
Чтобы обеспечить согласованность данных и предотвратить частичную запись файлов во время процесса резервного копирования, процесс Jenkins должен быть остановлен. Невыполнение остановки службы рискует получить неполную или поврежденную резервную копию.
# Для систем, использующих systemd (большинство современных дистрибутивов Linux)
sudo systemctl stop jenkins
# Или для систем, использующих команду service
sudo service jenkins stop
Шаг 2: Создайте архив резервной копии
Перейдите в родительский каталог $JENKINS_HOME и используйте tar для создания сжатого архива. Настоятельно рекомендуется исключить большие артефакты сборки, чтобы сэкономить место и время.
Предполагая, что $JENKINS_HOME находится в /var/lib/jenkins:
JENKINS_HOME="/var/lib/jenkins"
BACKUP_TARGET="/mnt/backups/jenkins"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
ARCHIVE_NAME="jenkins_backup_${TIMESTAMP}.tar.gz"
# Создайте целевой каталог, если он не существует
mkdir -p $BACKUP_TARGET
# Создайте архив, исключая историю сборок и рабочие области
sudo tar -czvf "${BACKUP_TARGET}/${ARCHIVE_NAME}" \
--exclude="${JENKINS_HOME}/workspace" \
--exclude="${JENKINS_HOME}/caches" \
--exclude="${JENKINS_HOME}/jobs/*/builds" \
"${JENKINS_HOME}"
Совет: Включение истории сборок
Если сохранение истории сборок (
jobs/*/builds) критично, вы можете удалить соответствующий флаг--exclude. Однако будьте готовы к тому, что размеры архивов могут достигать сотен гигабайт.
Шаг 3: Проверьте и сохраните вне офиса
После создания архива проверьте, что его можно прочитать, прежде чем доверять ему:
tar -tzf "${BACKUP_TARGET}/${ARCHIVE_NAME}" >/dev/null
Затем перенесите его во внешнее хранилище, например, в корзину S3 или сетевую систему резервного копирования, чтобы отказ локального диска не уничтожил и Jenkins, и его резервную копию.
Шаг 4: Перезапустите Jenkins
sudo systemctl start jenkins
Метод 2: Использование плагина резервного копирования Jenkins (частичное решение)
Хотя существуют такие плагины, как ThinBackup или Backup Plugin, они часто захватывают только файлы конфигурации (config.xml) и могут не обрабатывать большие файлы или все необходимые элементы безопасности надежно. Эти плагины обычно подходят для резервного копирования только конфигураций заданий, и на них не следует полагаться для полной, безопасной стратегии аварийного восстановления.
Восстановление экземпляра Jenkins
Восстановление включает копирование резервных данных в каталог $JENKINS_HOME целевой машины и обеспечение правильных прав на файлы перед запуском службы.
Шаг 1: Подготовьте целевую среду
Убедитесь, что на целевой системе (или восстановленной системе) установлен Jenkins, но служба остановлена.
sudo systemctl stop jenkins
Шаг 2: Очистите существующие данные Jenkins (необязательно, но рекомендуется)
Если вы восстанавливаетесь на машине, которая ранее размещала Jenkins, очистите существующее содержимое $JENKINS_HOME, чтобы обеспечить чистоту среды.
# Будьте осторожны с командой 'rm -rf'!
sudo rm -rf /var/lib/jenkins/*
Шаг 3: Извлеките архив резервной копии
Скопируйте сжатый архив (jenkins_backup_latest.tar.gz) на целевую машину и извлеките его в каталог $JENKINS_HOME. Флаг -C указывает целевой каталог для извлечения.
# Предполагая, что архив находится в /tmp, а JENKINS_HOME — /var/lib/jenkins
sudo tar -xzvf /tmp/jenkins_backup_latest.tar.gz -C /var/lib/
# Примечание: Если команда tar включала родительский каталог в архив, скорректируйте путь.
# Результат должен быть таким, чтобы содержимое архива заменило содержимое /var/lib/jenkins
Шаг 4: Проверьте и исправьте права доступа
Это самый критический шаг после восстановления. Если права на файлы неверны, Jenkins не запустится или не будет работать безопасно. Вы должны рекурсивно установить владельца на пользователя и группу, от имени которых работает служба Jenkins (часто jenkins:jenkins).
JENKINS_HOME="/var/lib/jenkins"
JENKINS_USER="jenkins"
JENKINS_GROUP="jenkins"
sudo chown -R $JENKINS_USER:$JENKINS_GROUP $JENKINS_HOME
sudo find "$JENKINS_HOME" -type d -exec chmod 755 {} \;
sudo find "$JENKINS_HOME" -type f -exec chmod 644 {} \;
sudo chmod -R go-rwx "$JENKINS_HOME/secrets" "$JENKINS_HOME/users" 2>/dev/null || true
Шаг 5: Запустите Jenkins и проверьте
Запустите службу и отслеживайте журналы, чтобы убедиться в успешном запуске.
sudo systemctl start jenkins
# Отслеживайте журналы запуска
sudo tail -f /var/log/jenkins/jenkins.log
После успешного запуска убедитесь, что все задания, пользователи и установленные плагины присутствуют и работают корректно.
Лучшие практики для автоматизированного резервного копирования
Чтобы выйти за рамки ручного резервного копирования, внедрите автоматизацию с помощью системных инструментов и внешнего управления конфигурацией.
1. Используйте задачи Cron
Запланируйте выполнение скрипта резервного копирования (шаги 1 и 2 из метода 1) ежедневно или еженощно с помощью cron или аналогичного планировщика. Убедитесь, что задача cron выполняется от имени пользователя с соответствующими разрешениями на остановку и запуск службы Jenkins, а также на чтение и запись в каталог $JENKINS_HOME.
2. Конфигурация как код (CasC)
Рассмотрите возможность использования Jenkins Configuration as Code (CasC). CasC определяет настройки Jenkins, задания и плагины с помощью декларативных YAML-файлов. Сохраняя эти YAML-файлы в отдельном репозитории системы контроля версий (например, Git), ваша конфигурация становится переносимой и управляемой версиями, что значительно упрощает основное требование к резервному копированию.
Вывод
Относитесь к резервной копии Jenkins как к полезной только после того, как вы протестировали восстановление. Хороший план восстановления сохраняет config.xml, jobs/, plugins/, users/, credentials.xml и secrets/, а затем проверяет, что задания могут выполняться на чистом экземпляре.
Предупреждение: Защита учетных данных
При восстановлении экземпляра убедитесь, что каталог
secrets/присутствует и корректен. Если Jenkins не может найти ключи, используемые для шифрования учетных данных (таких как ключи API или пароли), эти учетные данные станут непригодными для использования, и их придется вводить вручную.