새 서버로 이주하기
GitLab 백업 및 복원을 사용하여 인스턴스를 새 서버로 마이그레이션할 수 있습니다. 이 섹션에서는 단일 서버에서 실행되는 GitLab 배포의 전형적인 절차를 개요로 설명합니다.
GitLab Geo를 실행 중이라면 계획된 재해복구를 위한 Geo disaster recovery를 대체 옵션으로 선택할 수 있습니다. 이전의 GitLab.com이 Azure에서 GCP로 옮겨가는 경우의 상세 내용을 확인하시려면 이 페이지를 참조하십시오.
이전 및 새 서버가 동시에 데이터 처리를 하는 것을 피하여, 여러 서버가 동시에 연결하여 동일한 데이터를 처리하지 않게 하십시오. 예를 들어, 수신 이메일을 사용하는 경우, 두 GitLab 인스턴스가 동시에 이메일을 처리하는 경우, 두 인스턴스 모두 일부 데이터를 놓칠 수 있습니다.
이러한 문제는 비 패키지화된 데이터베이스 또는 비 패키지화된 Redis 인스턴스 또는 비 패키지화된 Sidekiq과 같은 다른 서비스에서도 발생할 수 있습니다.
새 서버 준비
새 서버를 준비하려면:
- 중간자 공격 경고를 피하기 위해 이전 서버에서 SSH 호스트 키를 복사하십시오.
예제 단계는 기본 사이트의 SSH 호스트 키 매뉴얼 복제를 확인하십시오.- GitLab 설치 및 구성:
- GitLab 설치.
- 이전 서버의
/etc/gitlab
파일을 새 서버로 복사하고 필요에 따라 업데이트하십시오. 자세한 내용은 Linux 패키지 설치 백업 및 복원 지침을 참조하십시오. - 적용되는 경우, 수신 이메일 비활성화.
-
백업 및 복원 후 초기 시작 시 새 CI/CD 작업이 시작되지 않도록 차단하십시오.
/etc/gitlab/gitlab.rb
를 편집하고 다음을 설정하십시오:nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n deny all;\n return 503;\n }\n"
-
GitLab을 재구성하십시오:
sudo gitlab-ctl reconfigure
- GitLab 설치 및 구성:
-
불필요하고 의도하지 않은 데이터 처리를 피하기 위해 GitLab을 중지하십시오:
sudo gitlab-ctl stop
-
새 서버가 Redis 데이터베이스와 GitLab 백업 파일을 수신할 수 있도록 구성하십시오:
sudo rm -f /var/opt/gitlab/redis/dump.rdb sudo chown <your-linux-username> /var/opt/gitlab/redis /var/opt/gitlab/backups
[새 서버로부터 콘텐츠 준비 및 전송을 계속합니다…]