GitLab 설치 복원

Tier: Free, Premium, Ultimate Offering: Self-managed

기타 Linux 패키지 또는 GitLab Helm 차트와 같은 다른 설치 방법을 사용한 기존 GitLab 인스턴스의 백업 tarball을 얻으려면 문서에 제공된 지침을 따르세요.

다른 인스턴스에서 백업을 복원하는 경우 해당 백업을 하기 전에 기존 인스턴스를 오브젝트 스토리지를 사용하도록 마이그레이션해야 합니다. 자세한 내용은 issue 646을 참조하세요.

백업을 복원할 때는 해당 백업이 생성된 GitLab 버전과 동일한 버전의 GitLab에 복원하는 것이 좋습니다.

GitLab 백업 복원은 차트에서 제공되는 Toolbox pod에서 backup-utility 명령을 실행하여 수행됩니다.

첫 번째로 복원을 실행하기 전에 Toolbox가 오브젝트 스토리지에 액세스하는지 확인이 필요합니다.

GitLab Helm 차트에서 제공하는 백업 도구는 다음 위치에서의 tarball 복원을 지원합니다.

  1. 인스턴스에 연결된 오브젝트 스토리지 서비스의 gitlab-backups 버킷. 이것이 기본 시나리오입니다.
  2. pod에서 액세스할 수 있는 공개 URL.
  3. kubectl cp를 사용하여 Toolbox pod로 복사할 로컬 파일.

Secrets 복원

Rails 시크릿 복원

GitLab 차트는 Rails 시크릿을 YAML 형식의 내용을 가진 Kubernetes Secrets로 제공되었음을 기대합니다. Linux 패키지 인스턴스에서 Rails 시크릿을 복원하는 경우, 시크릿은 /etc/gitlab/gitlab-secrets.json 파일에 JSON 형식으로 저장됩니다. 파일을 변환하고 YAML 형식의 시크릿을 생성하려면 다음을 실행하세요:

  1. /etc/gitlab/gitlab-secrets.json 파일을 kubectl 명령을 실행하는 워크스테이션으로 복사합니다.
  2. 워크스테이션에 yq 도구 (버전 4.21.1 이상)를 설치하세요.
  3. 다음 명령을 실행하여 gitlab-secrets.json을 YAML 형식으로 변환하세요:

    yq -P '{"production": .gitlab_rails}' gitlab-secrets.json -o yaml >> gitlab-secrets.yaml
    
  4. 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>
      ci_jwt_signing_key: <your ci jwt signing key>

YAML 파일에서 Rails 시크릿을 복원하려면:

  1. Rails 시크릿의 오브젝트 이름을 찾습니다:

    kubectl get secrets | grep rails-secret
    
  2. 기존 시크릿을 삭제합니다:

    kubectl delete secret <rails-secret-name>
    
  3. 기존 이름과 동일한 이름을 사용하여 새 시크릿을 생성하고 로컬 YAML 파일을 전달합니다:

    kubectl create secret generic <rails-secret-name> --from-file=secrets.yml=gitlab-secrets.yaml
    

pod 재시작

새 시크릿을 사용하려면 Webservice, Sidekiq 및 Toolbox pod을 재시작해야 합니다. 이러한 pod을 안전하게 재시작하려면 다음을 실행하세요:

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 설치를 복원하는 단계는 다음과 같습니다:

  1. 차트를 배포하여 실행 중인 GitLab 인스턴스가 있는지 확인하세요. 다음 명령을 실행하여 Toolbox pod이 활성화되어 있고 실행 중인지 확인하세요:

    kubectl get pods -lrelease=RELEASE_NAME,app=toolbox
    
  2. 위의 위치 중 아무 곳에나 준비된 tarball을 가져오세요. 이름이 <timestamp>_gitlab_backup.tar 형식으로 지정되어 있는지 확인하세요. 백업 타임스탬프에 대한 내용을 확인하세요.

  3. 이전에 버프리카에 대한 현재 복제본 수를 참고하세요:

    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"}'
    
  4. 복원 프로세스에 락이 간섭하는 것을 방지하기 위해 데이터베이스 클라이언트의 클라이언트를 중지하세요:

    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
    
  5. 백업 유틸리티를 실행하여 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>
    

    로컬 경로를 URL로 제공하는 것이 가능합니다. 형식은 다음과 같아야 합니다: file:///<path>

  6. 이 프로세스는 tarball의 크기에 따라 시간이 소요됩니다.
  7. 복원 프로세스는 데이터베이스의 기존 내용을 지우고 기존 리포지터리를 임시 위치로 이동시킨 후 tarball의 내용을 추출합니다. 리포지터리는 디스크의 해당 위치로 이동되고 기타 데이터(아티팩트, 업로드, LFS 등)는 오브젝트 스토리지의 해당 버킷에 업로드됩니다.

  8. 애플리케이션을 재시작합니다:

    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>
    
note
복원 중에 백업 tarball은 디스크에 추출되어야 합니다. 따라서, Toolbox pod은 필요한 크기의 디스크를 사용할 수 있어야 합니다. 자세한 내용 및 구성은 Toolbox documentation을 참조하세요.

러너 등록 토큰 복원

복원 후 포함된 러너는 올바른 등록 토큰이 더 이상 없기 때문에 인스턴스에 등록할 수 없습니다. 이를 해결하려면 문제 해결 단계를 따라 업데이트하세요.

쿠버네티스 관련 설정 활성화

복원된 백업이 차트의 기존 설치에서 오지 않은 경우, 복원 후에도 몇 가지 쿠버네티스 특정 기능을 활성화해야 합니다. 예를 들어 점진적 CI 작업 로깅 등이 있습니다.

  1. 다음 명령을 실행하여 Toolbox pod을 찾으세요.

    kubectl get pods -lrelease=RELEASE_NAME,app=toolbox
    
  2. 필요한 기능을 활성화하기 위해 인스턴스 설정 스크립트를 실행하세요.

    kubectl exec <Toolbox pod 이름> -it -- gitlab-rails runner -e production /scripts/custom-instance-setup
    

파드 재시작

새 변경 사항을 사용하려면 Webservice 및 Sidekiq 파드를 다시 시작해야 합니다. 이러한 파드를 다시 시작하는 가장 안전한 방법은 다음과 같이 실행하는 것입니다.

kubectl delete pods -lapp=sidekiq,release=<helm 릴리스 이름>
kubectl delete pods -lapp=webservice,release=<helm 릴리스 이름>

(선택 사항) 루트 사용자의 비밀번호 재설정

복원 프로세스는 gitlab-initial-root-password 시크릿을 백업 값으로 업데이트하지 않습니다. root로 로그인하려면 백업에 포함된 원래 비밀번호를 사용하세요. 비밀번호에 더 이상 접근할 수 없는 경우, 아래 단계를 따라 재설정하세요.

  1. 다음 명령을 실행하여 Webservice 파드에 연결하세요.

    kubectl exec <Webservice pod 이름> -it -- bash
    
  2. root 사용자의 비밀번호를 재설정하려면 다음 명령을 실행하세요. #{password}를 원하는 비밀번호로 대체하세요.

    /srv/gitlab/bin/rails runner "user = User.first; user.password='#{password}'; user.password_confirmation='#{password}'; user.save!"
    

추가 정보