GitLab 설치 복원

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

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

다른 인스턴스에서 가져온 백업을 복원하는 경우 백업을 수행하기 전에 기존 인스턴스를 객체 리포지터리를 사용하도록 마이그레이션해야 합니다. 이슈 646를 참조하세요.

백업이 생성된 GitLab 버전과 동일한 버전의 GitLab으로 복원하는 것이 좋습니다.

GitLab 백업을 복원하려면 차트에서 제공된 Toolbox pod에서 backup-utility 명령을 실행하여 백업을 가져와야 합니다.

처음으로 복원을 실행하기 전에 Toolbox가 정확하게 구성되어 있는지 확인해야 합니다. 객체 리포지터리에 액세스할 수 있도록 설정하세요.

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

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

시크릿 복원

레일스 시크릿 복원

GitLab 차트는 레일스 시크릿을 YAML 형식으로 제공되는 쿠버네티스 시크릿으로 예상합니다. Linux 패키지 인스턴스에서 레일스 비밀은 JSON 형식으로 /etc/gitlab/gitlab-secrets.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 파일에서 레일스 시크릿을 복원하려면:

  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

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
복원 중에는 백업 tar볼을 디스크로 해제해야 합니다. 따라서 Toolbox pod에 필요한 크기의 디스크가 있어야 합니다. 더 많은 세부 정보 및 구성에 대해서는 Toolbox 문서를 참조하세요.

Runner 등록 토큰 복원

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

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

Pod 재시작

새 변경 사항을 사용하려면 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!"

추가 정보