gitlab 컨테이너 backup/restore(백업 및 복원)
본 문서는 DockerHub 이미지 gitlab/gitlab-ce:11.11.8-ce.0을 기준으로 작성되었으며 12.2 버전 이상이거나 컨테이너가 아닌 경우 공식 문서를 참고하는 것을 권장한다
gitlab에서 공식 제공하는 컨테이너를 사용하는 경우, gitlab 데이터를 백업 및 복원하는 과정에서 겪은 시행착오를 정리한다. 백업 복원 작업시 다음과 같은 내용들은 유의하는 것이 좋다.
- 백업 대상 서비스와 복원 대상 서비스의 gitlab 버전을 같은 버전으로 설정해 준다.
- 마운트를 완료한 상태에서, 순정상태의 gitlab을 한번 기동하여 동작을 확인한다.
- gitlab 쉘을 통해 복원 명령 수행시 확인 입력을 받는 경우(데이터 삭제시)가 있으므로 가급적으로 컨테이너에 직접 접근하여 명령을 수행한다.
- 공식 문서에서는 같은 버전이라도 CE ↔︎ EE 간에 백업 복원이 공식 지원되지 않는 것처럼 나오는데, 실제 수행해 본 결과 동일버전 EE → CE는 정상적으로 수행이 되었다. 반대의 경우는 테스트 해보지 못하였는데 관련하여 제보 해주시면 굽신굽신.(_ _)
백업 수행
백업 파일 생성
명령어들은 gitlab 컨테이너에 docker exec -it <컨테이너명> /bin/bash 와 같은 형태로 접근하여 사용하는 것을 전제로 한다.
- gitlab 버전 12.2 이상
gitlab-backup create- gitlab 버전 12.1 이하
gitlab-rake gitlab:backup:create설정 및 암호키 백업
백업 명령으로 생성되는 백업파일에는 설정정보나 CI/CD 시크릿 변수, 2차인증 정보 등과 관련한 정보들은 자동으로 저장되지 않는다고 한다. (보안상의 이유로 자동으로 백업을 생성하는 것이 구조적으로 문제가 있어서 그렇다고 한다.)
본인은 pull push도 http 방식으로 진행었고, CI/CD 관련 설정한 것이나 2차인증등은 구현하지 않았었기 때문에 별도로 백업을 하지 않아도 이후 복원시 전혀 문제가 없었지만, 관련하여 백업이 필요한 경우에는 별도 백업 이후 복원작업 진행시 다시 정상 경로에 파일들을 위치시키고 복원을 진행해야 한다고 한다. 파일들의 위치는 다음과 같다.
- /etc/gitlab/gitlab-secrets.json
- /etc/gitlab/gitlab.rb
📌 11.11.8ce 버전을 기준으로 컨테이너 내부에 해당 위치에 백업 파일들이 존재 했으나, 공식 문서에는 /srv/gitlab/config 경로로 표기되어 있으니 참고할것.백업파일 확인
기본설정으로 세팅되어 있다면, /var/opt/gitlab/backups 경로에 타임스템프값_버전_gitlab_backup.tar 와 같은 형태로 백업파일이 생성된다.
복원 수행
명령어들은 gitlab 컨테이너에 docker exec -it <컨테이너명> /bin/bash 와 같은 형태로 접근하여 사용하는 것을 전제로 한다.
복원 수행하기 전에 마운트를 완료한 상태에서, 순정상태의 gitlab을 한번 기동하여 동작을 확인해야 한다. 특히 복원을 수행할 때는 gitlab 쉘에서 사용자 입력을 요구하는 경우가 있으니 컨테이너에 쉘 접근을 수행한 후에 명령들을 수행하는 것을 권장한다.
설정 및 암호키 배치
- /etc/gitlab/gitlab-secrets.json
- /etc/gitlab/gitlab.rb
위에서 별도 저장해 두었던 파일들을 본래 경로에 위치시킨다. (다른 경로에서 백업을 수행했다면, 해당 경로에 위치시키면 된다.)
백업파일 위치 확인
백업시 파일이 기본으로 생성되었던 것과 같은 경로(/var/opt/gitlab/backups)에 파일을 위치시켜준다.
데이터베이스 연결 프로세스 종료
데이터베이스와 연결되는 프로세스들을 정지하고, 잘 정지되었는지 확인한다.
gitlab-ctl stop unicorn
gitlab-ctl stop puma
gitlab-ctl stop sidekiq
# Verify
gitlab-ctl status복원 명령 수행
복원 명령 수행시 BACKUP변수에 명시해주는 백업대상 은 복원 대상이 되는 파일명을 기준으로 작성된다. 예를들어 12_2021_03_12_11.11.8_gitlab_backup.tar 이 파일 이름이라면 _gitlab_backup.tar 의 앞부분까지의 문자열인 12_2021_03_12_11.11.8 까지를 입력해주면 된다.
- gitlab 버전 12.2 이상
gitlab-backup restore BACKUP=백업대상지정
#Ex
#gitlab-backup restore BACKUP=12_2021_03_12_11.11.8- gitlab 버전 12.1 이하
gitlab-rake gitlab:backup:restore BACKUP=백업대상지정
#Ex
#gitlab-rake gitlab:backup:restore BACKUP=12_2021_03_12_11.11.8중간에 데이터베이스 초기화가 필요하거나 ~~경우 다음과 같이 사용자의 입력을 요구한다. 적절하게 대답하면 된다.
Before restoring the database, we will remove all existing
tables to avoid future upgrade problems. Be aware that if you have
custom tables in the GitLab database these tables and all data will be
removed.
Do you want to continue (yes/no)? yes
This task will now rebuild the authorized_keys file.
You will lose any data stored in the authorized_keys file.
Do you want to continue (yes/no)? yes작업이 완료된 이후 컨테이너를 재시작 해주면 적용이 완료 된다.
복원 후 설정 리빌드
컨테이너는 복원 완료 이후 기본적으로 reconfigure 과정이 수행되지만, 커스텀 이미지를 사용하거나 기타 다른 이유로 인해 컨테이너 내에서 수동으로 작업해 주어야 하는 경우, 아래와 같은 과정을 통해 설정 리빌드 후 gitlab 서비스 재시작 프로세스를 수행해 주어야 한다.
gitlab-ctl reconfigure
gitlab-ctl restart- 리빌드 수행시 redis 체크 과정에서 진행이 되지 않을 경우
컨테이너의 엔트리포인트 오버라이딩을 통해 임의의 프로세스(sleep infinify) 와 같은 형태로 컨테이너를 강제 기동시키고 쉘에서 작업을 수행하는 경우, 기본적으로 기동되고 있어야 하는 gitlab 연관 프로세스들(redis, postgres ..)들이 대기중이지 않기 때문에 서비스들을 1차적으로 기동해주고 리빌드 작업을 수행해야 한다.
/opt/gitlab/embedded/bin/runsvdir-start &위 명령을 수행하여 runit 서비스들을 띄워주고 리빌드를 수행하면 정상적으로 동작한다. (명령 수행 이후 에러가 발생해도 그냥 진행하면 된다.)
참고자료
- gitlab 공식 문서 : https://docs.gitlab.com/ee/raketasks/backup_restore.html#restore-gitlab
- omnibus-gitlab issues: https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4257