GitLab 설치 복원

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

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

다른 인스턴스에서 가져온 백업을 복원하는 경우 백업을 가져오기 전에 기존 인스턴스를 객체 저장소 사용으로 마이그레이션해야 합니다. 이슈 646을 참조하세요.

백업을 가져올 때 백업이 생성된 GitLab 버전과 동일한 버전의 GitLab에 백업을 복원하는 것이 권장됩니다.

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

첫 번째로 복원을 실행하기 전에 [Toolbox가 object storage에 액세스할 수 있도록 정확하게 구성되었는지 확인해야 합니다.

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

  1. 인스턴스와 관련된 객체 저장소 서비스의 gitlab-backups 버킷. 이것이 기본 시나리오입니다.
  2. 팟에서 액세스할 수 있는 공개 URL
  3. kubectl cp를 사용하여 Toolbox 팟으로 복사할 수 있는 로컬 파일

비밀 복원

레일즈 비밀 복원

GitLab 차트는 레일즈 비밀이 YAML로 내용이 제공된 Kubernetes Secret을 예상합니다. Linux 패키지 인스턴스에서 레일즈 비밀을 복원하는 경우, 비밀은 /etc/gitlab/gitlab-secrets.json 파일에 JSON 형식으로 저장됩니다. 파일을 변환하고 YAML 형식의 비밀을 생성하려면 다음 명령을 실행하세요:

  1. /etc/gitlab/gitlab-secrets.json 파일을 kubectl 명령을 실행하는 워크스테이션으로 복사합니다.

  2. 워크스테이션에 yq 도구(version 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>

YAML 파일에서 레일즈 비밀을 복원하려면:

  1. 레일즈 비밀의 객체 이름을 찾으세요: 

    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

팟 재시작

새 비밀을 사용하려면 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 설치를 복원하기 위한 단계는 다음과 같습니다.

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

    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. 백업을 복원하기 위해 백업 유틸리티를 실행하세요: 

    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 형식과 같이 로컬 경로를 URL로 제공할 수 있습니다: file:///<path>

  6. 이 프로세스는 tarball의 크기에 따라 시간이 소요됩니다.

  7. 복원 프로세스는 데이터베이스의 기존 내용을 지우고 기존 리포지토리를 임시 위치로 이동한 후 tarball의 내용을 추출합니다. 리포지토리는 디스크의 해당 위치로 이동되고 다른 데이터, 예를 들어 artifacts, uploads, 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 팟은 필요한 크기의 디스크를 사용할 수 있어야 합니다. 자세한 내용 및 구성에 대해서는 Toolbox documentation을 참조하세요.

러너 등록 토큰 복원

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

Kubernetes 관련 설정 활성화

복원된 백업이 차트의 기존 설치에서 이루어지지 않은 경우, 복원 후 몇 가지 Kubernetes 특정 기능을 활성화해야 합니다. 예를 들어, 점진적 CI 작업 로깅과 같은 기능입니다.

  1. 다음 명령을 실행하여 Toolbox pod를 찾습니다 

    kubectl get pods -lrelease=RELEASE_NAME,app=toolbox

  2. 필요한 기능을 활성화하기 위해 인스턴스 설정 스크립트를 실행하세요 

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

Pods 재시작

새로운 변경 사항을 사용하려면 Webservice 및 Sidekiq pods를 다시 시작해야 합니다. 이러한 pods를 재시작하는 가장 안전한 방법은 다음 명령을 실행하는 것입니다: 

kubectl delete pods -lapp=sidekiq,release=<helm release name>
kubectl delete pods -lapp=webservice,release=<helm release name>

(선택 사항) 루트 사용자의 암호 재설정

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

  1. 다음 명령을 실행하여 Webservice pod에 연결합니다 

    kubectl exec <Webservice pod name> -it -- bash

  2. root 사용자의 비밀번호를 재설정하려면 다음 명령을 실행합니다. #{password}를 사용자가 선택한 비밀번호로 대체하세요 

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

추가 정보