Jenkins 인스턴스 백업 및 복원 방법
JENKINS_HOME을 아카이브하고, 비밀을 보존하며, 필요하기 전에 복구를 테스트하여 Jenkins를 안전하게 백업하고 복원합니다.
Jenkins 인스턴스 백업 및 복원 방법
Jenkins는 종종 빌드, 배포, 자격 증명 및 릴리스 기록을 위한 제어 평면이 됩니다. 디스크 오류나 잘못된 마이그레이션 중에 $JENKINS_HOME을 잃으면 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}" \
--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 작업 활용
cron 또는 유사한 스케줄러를 사용하여 백업 스크립트(방법 1의 1단계 및 2단계)를 매일 또는 매일 밤 실행하도록 예약하십시오. cron 작업이 Jenkins 서비스를 중지 및 시작하고 $JENKINS_HOME 디렉토리를 읽고 쓸 수 있는 적절한 권한이 있는 사용자로 실행되는지 확인하십시오.
2. 코드형 구성(CasC)
Jenkins Configuration as Code(CasC) 도입을 고려하십시오. CasC는 선언적 YAML 파일을 사용하여 Jenkins 설정, 작업 및 플러그인을 정의합니다. 이러한 YAML 파일을 별도의 소스 제어 저장소(예: Git)에 저장하면 구성이 이식 가능하고 버전 관리되어 핵심 백업 요구 사항이 크게 간소화됩니다.
결론
Jenkins 백업은 복원을 테스트한 후에만 유용하다고 간주하십시오. 좋은 복구 계획은 config.xml, jobs/, plugins/, users/, credentials.xml 및 secrets/를 보존한 다음 깨끗한 인스턴스에서 작업을 실행할 수 있는지 확인합니다.
경고: 자격 증명 보안
인스턴스를 복원할 때
secrets/디렉토리가 존재하고 올바른지 확인하십시오. Jenkins가 자격 증명(예: API 키 또는 비밀번호)을 암호화하는 데 사용된 키를 찾을 수 없으면 해당 자격 증명을 사용할 수 없게 되며 수동으로 다시 입력해야 합니다.