Как резервно копировать и восстанавливать экземпляр Jenkins
Jenkins служит центральным центром автоматизации для непрерывной интеграции и непрерывной доставки (CI/CD). Конфигурационные данные — включая определения заданий, учетные данные пользователей, настройки плагинов и историю сборок — представляют собой значительные организационные инвестиции. Потеря этих данных из-за сбоя оборудования, ошибки конфигурации или миграции может полностью остановить конвейеры разработки.
Это подробное руководство описывает основные компоненты надежной стратегии резервного копирования 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 \n --exclude="${JENKINS_HOME}/workspace" \n --exclude="${JENKINS_HOME}/caches" \n --exclude="${JENKINS_HOME}/jobs/*/builds" \n $JENKINS_HOME
Совет: Включение истории сборок
Если сохранение истории сборок (
jobs/*/builds) имеет решающее значение, вы можете удалить соответствующий флаг--exclude. Однако будьте готовы к тому, что размеры архива могут достигать сотен гигабайт.
Шаг 3: Проверка и хранение вне площадки
После создания архива проверьте его целостность и немедленно передайте его на внешнее, географически отдельное место хранения (например, корзину S3, сетевой диск) для защиты от сбоя на уровне площадки.
Шаг 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 chmod -R 755 $JENKINS_HOME
Шаг 5: Запуск Jenkins и проверка
Запустите службу и следите за журналами, чтобы убедиться в успешном запуске.
sudo systemctl start jenkins
# Мониторинг журналов запуска
sudo tail -f /var/log/jenkins/jenkins.log
После успешного запуска убедитесь, что все задания, пользователи и установленные плагины присутствуют и работают должным образом.
Рекомендации по автоматическому резервному копированию
Чтобы выйти за рамки ручного резервного копирования, внедрите автоматизацию с помощью системных инструментов и внешнего управления конфигурацией.
1. Использование Cron Jobs
Запланируйте выполнение скрипта резервного копирования (Шаги 1 и 2 из Метода 1) ежедневно или ночью с помощью cron или аналогичного планировщика. Убедитесь, что задание cron выполняется от имени пользователя с соответствующими правами для остановки и запуска службы Jenkins, а также для чтения/записи в каталог $JENKINS_HOME.
2. Конфигурация как код (CasC)
Рассмотрите возможность внедрения Jenkins Configuration as Code (CasC). CasC определяет настройки Jenkins, задания и плагины с помощью декларативных файлов YAML. Сохраняя эти файлы YAML в отдельном репозитории системы контроля версий (например, Git), ваша конфигурация становится переносимой и версионированной, что значительно упрощает основное требование к резервному копированию.
Предупреждение: Защита учетных данных
При восстановлении экземпляра убедитесь, что каталог
secrets/присутствует и корректен. Если Jenkins не может найти ключи, используемые для шифрования учетных данных (таких как ключи API или пароли), эти учетные данные станут непригодными для использования, и их потребуется ввести вручную.