새 서버로 마이그레이션

새 서버로 마이그레이션에 대해 설명합니다.

--> GitLab 백업 및 복원을 사용하여 인스턴스를 새 서버로 마이그레이션할 수 있습니다. 이 섹션에서는 Linux 패키지를 사용하는 단일 서버에서 실행되는 GitLab 배포의 일반적인 절차를 설명합니다. GitLab Geo를 실행 중인 경우 계획된 페일오버를 위한 Geo 재해 복구 가 대안입니다. Geo를 마이그레이션에 선택하기 전에 모든 사이트가 Geo 요구사항 을 충족하는지 확인해야 합니다. Warning 새 서버와 이전 서버 모두에서 데이터를 처리하는 비조율된 데이터 처리를 피하세요. 여러 서버가 동시에 연결되어 동일한 데이터를 처리할 수 있습니다. 예를 들어 수신 이메일 을 사용할 때 두 GitLab 인스턴스가 동시에 이메일을 처리하면 두 인스턴스 모두 일부 데이터를 놓칩니다. 이 유형의 문제는 패키지되지 않은 데이터베이스 , 패키지되지 않은 Redis 인스턴스, 패키지되지 않은 Sidekiq와 같은 다른 서비스에서도 발생할 수 있습니다. 사전 요구사항: 사용자에게 예정된 마이그레이션을 알리기 위해 미리 게시된 브로드캐스트 메시지 배너 . 완전하고 최신의 백업. 파괴적인 명령(예: rm )이 잘못 실행되는 경우를 대비하여 완전한 시스템 수준 백업을 생성하거나 마이그레이션에 관련된 모든 서버의 스냅샷을 찍으세요. 관리자 접근 권한. 새 서버 준비 # 새 서버를 준비하려면: 중간자 공격 경고를 피하기 위해 이전 서버에서 새 서버로 SSH 호스트 키 를 복사합니다. 예시 단계는 기본 사이트의 SSH 호스트 키를 수동으로 복제 를 참조하세요. GitLab 설치 . 이전 서버에서 새 서버로 /etc/gitlab 파일을 복사하여 구성하고, 필요에 따라 업데이트합니다. 자세한 내용은 Linux 패키지 설치 백업 및 복원 지침 을 읽으세요. 해당하는 경우 수신 이메일 을 비활성화합니다. 백업 및 복원 후 초기 시작 시 새 CI/CD job이 시작되지 않도록 차단합니다. /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 중지: sudo gitlab-ctl stop Redis 중지: sudo gitlab-ctl stop redis Redis 데이터베이스와 GitLab 백업 파일을 수신할 수 있도록 새 서버 구성: sudo rm -f /var/opt/gitlab/redis/dump.rdb sudo chown <your-linux-username> /var/opt/gitlab/redis /var/opt/gitlab/backups 이전 서버에서 콘텐츠 준비 및 전송 # 이전 서버의 최신 시스템 수준 백업 또는 스냅샷이 있는지 확인합니다. GitLab 에디션에서 지원하는 경우 유지 관리 모드