GitLab 설치 복원

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

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

다른 인스턴스에서 가져온 백업을 복원하는 경우, 백업을 수행하기 전에 기존 인스턴스를 객체 저장소를 사용하도록 마이그레이션해야 합니다. 자세한 내용은 이슈 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 시크릿으로 제공되었음을 기대합니다. 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

팟 다시 시작

새 시크릿을 사용하려면 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. 백업 유틸리티를 실행하여 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 팟은 필요한 크기의 디스크를 사용할 수 있어야 합니다. 자세한 내용 및 구성은 Toolbox 문서를 참조하세요.

러너 등록 토큰 복원

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

Kubernetes 관련 설정 활성화

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

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

    kubectl get pods -lrelease=릴리스_이름,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=<헬름 릴리스 이름>
kubectl delete pods -lapp=webservice,release=<헬름 릴리스 이름>

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

복원 프로세스는 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!"

추가 정보