• 새 서버 준비
• 예전 서버에서 콘텐츠 준비 및 이전
• 새 서버에서 데이터 복원

새 서버로 이전하기

GitLab 백업과 복원을 사용하여 인스턴스를 새 서버로 이전할 수 있습니다. 이 섹션에서는 단일 서버에서 실행 중인 GitLab 배포에 대한 전형적인 절차를 개요로 설명합니다. GitLab Geo를 실행 중이라면 Geo 재해 복구를 위한 계획된 장애 조치가 대안 옵션입니다.

경고: 새 서버와 예전 서버 양쪽에서 데이터 처리를 조정하지 않도록 주의하세요. 여러 서버가 동시에 연결되어 동일한 데이터를 처리할 수 있습니다. 예를 들어 수신 이메일을 사용할 때, 두 GitLab 인스턴스가 동시에 이메일을 처리하는 경우 둘 다 일부 데이터를 놓칠 수 있습니다. 이러한 문제는 패키지되지 않은 데이터베이스, 패키지되지 않은 Redis 인스턴스 또는 패키지되지 않은 Sidekiq와 같은 다른 서비스에서도 발생할 수 있습니다.

준비 사항: - 이전에 이전한 시간이 좀 있으면 예정된 유지보수를 알릴 수 있도록 사용자에게 방송 메시지 배너를 고려하세요. - 백업이 완료되고 최신 상태인지 확인하세요. 모든 관련 서버의 시스템 수준 백업을 만들거나, rm과 같은 파괴적인 명령이 잘못 실행되는 경우를 대비하여 마이그레이션에 관여하는 모든 서버의 스냅숏을 찍으세요.

새 서버 준비

새 서버를 준비하려면:

1. 중간자 공격 경고를 피하기 위해 SSH 호스트 키를 예전 서버에서 복사하세요. 예시 단계는 주요 사이트의 SSH 호스트 키 수동 복제를 참고하세요.
2. 수신 이메일을 제외하고 GitLab을 설치하고 구성하세요:
   1. GitLab을 설치하세요.
   2. 예전 서버에서 /etc/gitlab 파일을 새 서버로 복사하고 필요에 따라 업데이트하세요. 자세한 내용은 Linux 패키지 설치 백업 및 복원 지침을 참조하세요.
   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. 새 서버에서 레디스 데이터베이스와 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. GitLab 에디션에서 지원하는 경우 유지보수 모드를 활성화하세요.
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. 왼쪽 사이드바에서 맨 아래에서 관리 영역을 선택하세요.
   2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택하세요.
   3. Sidekiq 대시보드에서 Cron 탭을 선택한 다음 모두 비활성화를 선택하세요.
5. 현재 실행 중인 CI/CD 작업이 완료될 때까지 기다리거나 완료되지 않은 작업이 손실될 수 있다고 받아 들이세요. 현재 실행 중인 작업을 보려면 왼쪽 사이드바에서 개요 > 작업을 선택한 다음 실행 중을 선택하세요.
6. Sidekiq 작업이 완료될 때까지 기다리세요:
   1. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택하세요.
   2. Sidekiq 대시보드에서 대기열을 선택한 다음 실시간 폴링을 선택하세요. 바쁨 및 대기 중이 0으로 줄어들 때까지 기다리세요. 이러한 대기열에는 사용자가 제출한 작업이 포함되어 있으며, 이러한 작업이 완료되기 전에 종료하면 작업이 손실될 수 있습니다. 마이그레이션 후 확인을 위해 Sidekiq 대시보드에 표시된 숫자를 메모하세요.

7. 레디스 데이터베이스를 디스크에 플러시하고 마이그레이션에 필요한 서비스를 제외한 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. 레디스 데이터베이스 및 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
    

새 서버에서 데이터 복원

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
   

3. GitLab 백업을 복원하세요.
4. Redis 데이터베이스가 올바르게 복원되었는지 확인하세요:
   1. 왼쪽 사이드바에서 아래쪽에 있는 관리 영역을 선택하세요.
   2. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택하세요.
   3. Sidekiq 대시보드에서 숫자가 이전 서버에서 표시된 것과 일치하는지 확인하세요.
   4. 여전히 Sidekiq 대시보드 하에서, Cron을 선택한 후 모두 활성화를 선택하여 주기적 백그라운드 작업을 다시 활성화하세요.
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. 스케줄된 유지 관리 브로드캐스트 메시지 배너를 제거하세요.