GitLab 설치 복원하기
기타 설치 방법(예: Linux 패키지 또는 GitLab Helm 차트)을 사용한 기존 GitLab 인스턴스의 백업 tarball을 받으려면
문서에서 제공하는 지침을 따르세요.
다른 인스턴스에서 가져온 백업을 복원하는 경우, 백업을 받기 전에 기존 인스턴스를 오브젝트 스토리지로 마이그레이션해야 합니다.
이슈 646을 참조하세요.
생성된 GitLab 버전과 동일한 버전으로 백업을 복원하는 것이 좋습니다.
GitLab 백업 복원은 차트에서 제공하는 Toolbox 포드에서 backup-utility
명령을 실행하여 수행됩니다.
처음 복원을 실행하기 전에 Toolbox가 올바르게 구성되었는지 확인하고
오브젝트 스토리지에 접근할 수 있어야 합니다.
GitLab Helm 차트에서 제공하는 백업 유틸리티는 다음 위치 중 하나에서 tarball을 복원하는 것을 지원합니다.
- 인스턴스와 연결된 오브젝트 스토리지 서비스의
gitlab-backups
버킷. 이는 기본 시나리오입니다. - 포드에서 접근할 수 있는 공개 URL.
-
kubectl cp
를 사용하여 Toolbox 포드에 복사할 수 있는 로컬 파일.
비밀 복원하기
Rails 비밀 복원하기
GitLab 차트는 Rails 비밀이 YAML 형식의 콘텐츠를 가진 Kubernetes Secret으로 제공될 것을 기대합니다.
Linux 패키지 인스턴스에서 Rails 비밀을 복원하는 경우, 비밀은 /etc/gitlab/gitlab-secrets.json
파일에 JSON 형식으로 저장됩니다.
파일을 변환하고 YAML 형식으로 비밀을 생성하려면:
-
/etc/gitlab/gitlab-secrets.json
파일을kubectl
명령을 실행하는 워크스테이션으로 복사합니다. -
워크스테이션에 yq 도구(버전 4.21.1 이상)를 설치합니다.
-
다음 명령을 실행하여
gitlab-secrets.json
을 YAML 형식으로 변환합니다:yq -P '{"production": .gitlab_rails}' gitlab-secrets.json -o yaml >> gitlab-secrets.yaml
-
새로 생성된
gitlab-secrets.yaml
파일에 다음 내용이 있는지 확인합니다:production: db_key_base: <your key base value> secret_key_base: <your secret key base value> otp_key_base: <your otp key base value> openid_connect_signing_key: <your openid signing key>
YAML 파일에서 Rails 비밀을 복원하려면:
-
Rails 비밀의 객체 이름을 찾습니다:
kubectl get secrets | grep rails-secret
-
기존 비밀을 삭제합니다:
kubectl delete secret <rails-secret-name>
-
이전과 동일한 이름으로 새 비밀을 생성하고 로컬 YAML 파일을 전달합니다:
kubectl create secret generic <rails-secret-name> --from-file=secrets.yml=gitlab-secrets.yaml
포드 재시작하기
새로운 비밀을 사용하려면 Webservice, Sidekiq 및 Toolbox 포드를 재시작해야 합니다.
이 포드를 안전하게 재시작하는 방법은 다음을 실행하는 것입니다:
kubectl delete pods -lapp=sidekiq,release=<helm release name>
kubectl delete pods -lapp=webservice,release=<helm release name>
kubectl delete pods -lapp=toolbox,release=<helm release name>
백업 파일 복원하기
GitLab 설치 복원 단계는 다음과 같습니다.
-
차트를 배포하여 실행 중인 GitLab 인스턴스가 있는지 확인합니다. 다음 명령을 실행하여 Toolbox 포드가 활성화되고 실행 중인지 확인합니다.
kubectl get pods -lrelease=RELEASE_NAME,app=toolbox
-
위의 위치 중 하나에 tarball을 준비합니다.
<timestamp>_gitlab_backup.tar
형식으로 이름이 지정되었는지 확인합니다. 백업 타임스탬프가 무엇인지 읽어보세요. -
이후 재시작을 위해 데이터베이스 클라이언트의 현재 복제본 수를 기록합니다:
kubectl get deploy -n <namespace> -lapp=sidekiq,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}' kubectl get deploy -n <namespace> -lapp=webservice,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}' kubectl get deploy -n <namespace> -lapp=prometheus,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
-
복원 과정에 방해가 되는 잠금을 방지하기 위해 데이터베이스 클라이언트를 중지합니다:
kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=0 kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=0 kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=0
-
tarball을 복원하기 위해 백업 유틸리티를 실행합니다.
kubectl exec <Toolbox pod name> -it -- backup-utility --restore -t <timestamp>
여기서
<timestamp>
는gitlab-backups
버킷에 저장된 tarball의 이름에서 가져온 것입니다. 공개 URL을 제공하려면 다음 명령을 사용하세요:kubectl exec <Toolbox pod name> -it -- backup-utility --restore -f <URL>
로컬 경로를
file:///<path>
형식으로 URL로 제공할 수 있습니다. -
이 과정은 tarball의 크기에 따라 시간이 걸립니다.
-
복원 과정에서는 데이터베이스의 기존 내용이 삭제되고, 기존 리포지토리가 임시 위치로 이동되며, tarball의 내용이 추출됩니다. 리포지토리는 디스크의 해당 위치로 이동되며, 기타 데이터(예: 아티팩트, 업로드, LFS 등)는 객체 저장소의 해당 버킷으로 업로드됩니다.
-
애플리케이션을 재시작합니다:
kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<value> kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<value> kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<value>
러너 등록 토큰 복원
복원 후 포함된 러너는 올바른 등록 토큰이 없기 때문에 인스턴스에 등록할 수 없습니다.
업데이트하려면 이 문제 해결 단계를 따르세요.
Kubernetes 관련 설정 활성화
복원된 백업이 차트의 기존 설치에서 가져온 것이 아닌 경우, 복원 후 일부 Kubernetes 특정 기능을 활성화해야 합니다. 예를 들어, 증분 CI 작업 로깅이 필요합니다.
-
다음 명령을 실행하여 Toolbox 포드를 찾습니다.
kubectl get pods -lrelease=RELEASE_NAME,app=toolbox
-
필요한 기능을 활성화하기 위해 인스턴스 설정 스크립트를 실행합니다.
kubectl exec <Toolbox pod name> -it -- gitlab-rails runner -e production /scripts/custom-instance-setup
포드 재시작
새로운 변경 사항을 사용하려면 Webservice와 Sidekiq 포드를 재시작해야 합니다. 이러한 포드를 재시작하는 가장 안전한 방법은 다음을 실행하는 것입니다:
kubectl delete pods -lapp=sidekiq,release=<helm release name>
kubectl delete pods -lapp=webservice,release=<helm release name>
(선택 사항) 루트 사용자 비밀번호 재설정
복원 프로세스는 백업의 값으로 gitlab-initial-root-password
비밀을 업데이트하지 않습니다. root
사용자로 로그인하려면 백업에 포함된 원래 비밀번호를 사용하세요. 비밀번호에 더 이상 접근할 수 없는 경우, 아래 단계를 따라 비밀번호를 재설정하세요.
-
다음 명령을 실행하여 Webservice 포드에 접속합니다.
kubectl exec <Webservice pod name> -it -- bash
-
다음 명령을 실행하여
root
사용자 비밀번호를 재설정합니다.#{password}
를 원하는 비밀번호로 교체합니다./srv/gitlab/bin/rails runner "user = User.first; user.password='#{password}'; user.password_confirmation='#{password}'; user.save!"