• 새 서버 준비
• 이전 서버에서 콘텐츠 준비 및 전송
  • 대량의 Git 및 객체 데이터가 있는 경우
• 새 서버에 데이터 복원

새 서버로 이전하기

GitLab 백업 및 복원을 사용하여 인스턴스를 새 서버로 이전할 수 있습니다. 이 섹션에서는 단일 서버에서 실행되는 GitLab 배포에 대한 일반적인 절차를 개요합니다. GitLab Geo를 실행 중이라면, 계획된 장애 조치를 위한 Geo 재해 복구가 대체 옵션입니다. 이전에 Geo를 이전 대상으로 선택하기 전에 Geo 요구 사항이 모든 사이트에서 충족되었는지 확인해야 합니다.

경고: 새로운 서버와 이전 서버가 동시에 데이터 처리를 수행하여 동시에 동일한 데이터를 처리하는 것을 피하세요. 예를 들어, 수신 이메일을 사용할 때, 두 GitLab 인스턴스가 동시에 이메일을 처리하는 경우 둘 다 일부 데이터를 놓칠 수 있습니다. 이러한 유형의 문제는 기타 서비스에서도 발생할 수 있으며, 비패키지 데이터베이스, 패키지되지 않은 Redis 인스턴스 또는 패키지되지 않은 Sidekiq 등이 있습니다.

준비 사항:

• 이주 이전에 예정된 유지 보수를 사용하여 사용자에게 알리는 것을 고려하세요. 브로드캐스트 메시지 배너로 완전한 백업이 끝났는지 확인하세요. 이주 이전에 예정된 유지 보수를 사용하여 사용자에게 알리는 것을 고려하세요. 브로드캐스트 메시지 배너로 완전한 백업이 끝났는지 확인하세요.
• 백업이 완료되고 최신 상태인지 확인하세요. 이주 이전에 예정된 유지 보수를 사용하여 사용자에게 알리는 것을 고려하세요. 브로드캐스트 메시지 배너로 완전한 백업이 끝났는지 확인하세요. 이주 이전에 예정된 유지 보수를 사용하여 사용자에게 알리는 것을 고려하세요. 브로드캐스트 메시지 배너로 완전한 백업이 끝났는지 확인하세요.

새 서버 준비

새 서버를 준비하려면:

1. 중간자 공격 경고를 피하기 위해 이전 서버의 SSH 호스트 키를 복사하세요. 예제 단계는 Primary site의 SSH 호스트 키 수동 복제를 참조하세요.
2. GitLab 설치 및 구성을 수행하세요. 단, 수신 이메일은 제외합니다:
   1. GitLab 설치합니다.
   2. 이전 서버의 /etc/gitlab 파일을 새 서버로 복사하고 필요한 대로 업데이트합니다. 더 자세한 내용은 Linux package installation backup and restore instructions를 참조하세요.
   3. 해당하는 경우 수신 이메일을 비활성화합니다.

   4. 백업 및 복원 후 초기 시작 시 CI/CD 작업을 차단하세요. /etc/gitlab/gitlab.rb을 편집하고 다음을 설정하세요:

      nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"
      

   5. GitLab 다시 구성합니다:

      sudo gitlab-ctl reconfigure
      

3. 불필요한 데이터 처리를 피하기 위해 GitLab을 중지하세요:

   sudo gitlab-ctl stop
   

4. 새 서버가 Redis 데이터베이스와 GitLab 백업 파일을 받을 수 있도록 구성하세요:

   sudo rm -f /var/opt/gitlab/redis/dump.rdb
   sudo chown <your-linux-username> /var/opt/gitlab/redis /var/opt/gitlab/backups
   

이전 서버에서 콘텐츠 준비 및 전송

1. 이전 서버의 최신 시스템 수준 백업 또는 스냅샷이 있는지 확인하세요.
2. 지원되는 경우 유지 보수 모드를 활성화합니다.
3. 새로운 CI/CD 작업이 시작되는 것을 차단합니다:

   1. /etc/gitlab/gitlab.rb을 편집하고 다음을 설정하세요:

      nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"
      

   2. GitLab 다시 구성합니다:

      sudo gitlab-ctl reconfigure
      

4. 주기적인 백그라운드 작업을 비활성화합니다:
   1. 왼쪽 사이드바에서 Admin을 선택합니다.
   2. 왼쪽 사이드바에서 Monitoring > Background jobs을 선택합니다.
   3. Sidekiq 대시보드에서 Cron 탭을 선택한 다음 모두 비활성화합니다.
5. 실행 중인 CI/CD 작업이 완료될 때까지 기다리거나 완료되지 않은 작업이 손실될 수 있음을 수락하세요. 실행 중인 작업을 확인하려면 왼쪽 사이드바에서 개요 > Jobs를 선택한 다음 Running을 선택하세요.
6. Sidekiq 작업이 완료될 때까지 기다리세요:
   1. 왼쪽 사이드바에서 Monitoring > Background jobs을 선택합니다.
   2. Sidekiq 대시보드에서 대기열을 선택한 다음 실시간 폴링을 선택하세요. 바쁨 및 대기 중이 0으로 줄어들 때까지 기다리세요. 이러한 대기열에는 사용자가 제출한 작업이 포함되어 있으며; 이러한 작업이 완료되기 전에 종료하면 작업이 손실될 수 있습니다. 마이그레이션 후 확인을 위해 Sidekiq 대시보드에 표시된 숫자에 유의하세요.

7. Redis 데이터베이스를 디스크에 플러시하고 마이그레이션에 필요한 서비스 이외에 GitLab을 중지하세요:

   sudo /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket save && sudo gitlab-ctl stop && sudo gitlab-ctl start postgresql && sudo gitlab-ctl start gitaly
   

8. GitLab 백업을 생성하세요:

   sudo gitlab-backup create
   

9. 다음의 GitLab 서비스를 비활성화하고 /etc/gitlab/gitlab.rb의 맨 아래에 다음을 추가하여 잘못된 재시작을 방지하세요:

   alertmanager['enable'] = false
   gitlab_exporter['enable'] = false
   gitlab_pages['enable'] = false
   gitlab_workhorse['enable'] = false
   grafana['enable'] = false
   logrotate['enable'] = false
   gitlab_rails['incoming_email_enabled'] = false
   nginx['enable'] = false
   node_exporter['enable'] = false
   postgres_exporter['enable'] = false
   postgresql['enable'] = false
   prometheus['enable'] = false
   puma['enable'] = false
   redis['enable'] = false
   redis_exporter['enable'] = false
   registry['enable'] = false
   sidekiq['enable'] = false
   

10. GitLab을 다시 구성하세요:

    sudo gitlab-ctl reconfigure
    

11. 모든 것이 중지되었는지 확인하고 서비스가 실행 중이지 않은지 확인하세요:

    sudo gitlab-ctl status
    

12. Redis를 새 서버에서 전송하기 전에 중지하세요:

    sudo gitlab-ctl stop redis
    

13. Redis 데이터베이스 백업 및 GitLab 백업을 새 서버로 전송하세요:

    sudo scp /var/opt/gitlab/redis/dump.rdb <your-linux-username>@new-server:/var/opt/gitlab/redis
    sudo scp /var/opt/gitlab/backups/your-backup.tar <your-linux-username>@new-server:/var/opt/gitlab/backups
    

대량의 Git 및 객체 데이터가 있는 경우

당신의 GitLab 인스턴스에 로컬 볼륨에 많은 데이터가 있는 경우(예: 1TB 이상), 백업에는 오랜 시간이 걸릴 수 있습니다. 이 경우, 새로운 인스턴스의 적절한 볼륨으로 데이터를 전송하는 것이 더 쉬울 수 있습니다.

수동으로 마이그레이션해야 할 주요 볼륨은 다음과 같습니다:

• 모든 Git 데이터를 포함하는 /var/opt/gitlab/git-data 디렉토리입니다. Git 데이터 손상 가능성을 제거하기 위해 저장소 이동 문서 섹션를 반드시 읽어보세요.
• 아티팩트와 같은 객체 데이터를 포함하는 /var/opt/gitlab/gitlab-rails/shared 디렉토리입니다.
• Linux 패키지에 포함된 번들 PostgreSQL을 사용 중이라면, /var/opt/gitlab/postgresql/data 하위에 PostgreSQL 데이터 디렉토리를 마이그레이션해야 합니다.

모든 GitLab 서비스를 중지한 후, rsync나 볼륨 스냅샷을 마운트하는 등의 도구를 사용하여 데이터를 새 환경으로 이전할 수 있습니다.

새 서버에 데이터 복원

1. 적절한 파일 시스템 권한을 복원합니다:

   sudo chown gitlab-redis /var/opt/gitlab/redis
   sudo chown gitlab-redis:gitlab-redis /var/opt/gitlab/redis/dump.rdb
   sudo chown git:root /var/opt/gitlab/backups
   sudo chown git:git /var/opt/gitlab/backups/your-backup.tar
   

2. Redis를 시작합니다:

   sudo gitlab-ctl start redis
   

   Redis는 dump.rdb를 자동으로 가져오고 복원합니다.

3. GitLab 백업을 복원.
4. Redis 데이터베이스가 올바르게 복원되었는지 확인합니다:
   1. 왼쪽 사이드바에서 맨 아래 관리자를 선택합니다.
   2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
   3. Sidekiq 대시보드에서 숫자가 이전 서버에 표시된 것과 일치하는지 확인합니다.
   4. 여전히 Sidekiq 대시보드 하단에서 크론을 선택한 다음 모두 사용을 선택하여 주기적 백그라운드 작업을 다시 활성화합니다.
5. GitLab 인스턴스에서 읽기 전용 작업이 예상대로 작동하는지 테스트합니다. 예를 들어 프로젝트 저장소 파일, 병합 요청 및 이슈를 둘러봅니다.
6. 유지 보수 모드가 이전에 활성화되었다면 비활성화합니다.
7. GitLab 인스턴스가 예상대로 작동하는지 테스트합니다.
8. 해당되는 경우 수신 이메일을 다시 활성화하고 예상대로 작동하는지 확인합니다.
9. DNS 또는 로드 밸런서를 새 서버를 가리키도록 업데이트합니다.

10. 이전에 추가한 사용자 정의 NGINX 구성을 제거하여 새 CI/CD 작업이 시작되지 않도록 차단합니다:

    # 다음 줄은 제거되어야 합니다
    nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n    deny all;\n    return 503;\n  }\n"
    

11. GitLab을 다시 구성합니다:

    sudo gitlab-ctl reconfigure
    

12. 예정된 유지 보수 방송 메시지 배너를 제거합니다.