• 새 서버 준비
• 이전 서버에서 콘텐츠 준비 및 전송
  • 대량의 Git 및 객체 데이터가 있는 인스턴스
• 새 서버에 데이터 복원하기

새 서버로 마이그레이션

GitLab 백업 및 복원을 사용하여 인스턴스를 새 서버로 마이그레이션할 수 있습니다. 이 섹션은 단일 서버에서 실행되는 GitLab 배포에 대한 일반적인 절차를 설명합니다.

GitLab Geo를 실행 중이라면, 대안 옵션은 Geo 재해 복구를 통한 계획된 장애 조치입니다. 마이그레이션을 위해 Geo를 선택하기 전에 모든 사이트가 Geo 요구 사항을 충족하는지 확인해야 합니다.

경고: 새 서버와 이전 서버에서 비협조적으로 데이터 처리를 피하세요. 여러 서버가 동시에 연결되어 동일한 데이터를 처리할 수 있습니다. 예를 들어, 수신 이메일을 사용할 경우 두 GitLab 인스턴스가 동시에 이메일을 처리하면 두 인스턴스 모두 일부 데이터를 놓치게 됩니다. 이러한 문제는 패키지되지 않은 데이터베이스, 패키지되지 않은 Redis 인스턴스 또는 패키지되지 않은 Sidekiq와 같은 다른 서비스에서도 발생할 수 있습니다.

사전 요구 사항:

• 마이그레이션 전에 사용자에게 예정된 유지 관리에 대한 브로드캐스트 메시지 배너로 알리는 것을 고려하세요.
• 백업이 완전하고 최신인지 확인하세요. 파괴적인 명령(예: rm)이 잘못 실행될 경우를 대비하여 모든 서버의 시스템 수준 백업을 생성하거나 스냅샷을 찍으세요.

새 서버 준비

새 서버를 준비하려면:

1. 구 man-in-the-middle 공격 경고를 피하기 위해 이전 서버에서 SSH 호스트 키를 복사하세요. 예시 단계는 기본 사이트의 SSH 호스트 키 수동 복제를 참조하세요.
2. 수신 이메일을 제외하고 GitLab을 설치하고 구성하세요:
   1. GitLab을 설치하세요.
   2. 이전 서버에서 새 서버로 /etc/gitlab 파일을 복사하고 필요에 따라 업데이트하여 구성하세요. 자세한 내용은 리눅스 패키지 설치 백업 및 복원 지침을 참조하세요.
   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. 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 대시보드에서 큐를 선택한 후 실시간 투표를 선택합니다.
      Busy와 Enqueued가 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 데이터베이스 백업을 전송하기 전에 새 서버에서 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. 왼쪽 사이드바에서 하단의 Admin을 선택합니다.

   2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.

   3. Sidekiq 대시보드에서 숫자가 이전 서버에 보여진 것과 일치하는지 확인합니다.

   4. 여전히 Sidekiq 대시보드에 있을 때, Cron을 선택한 다음 Enable All을 선택하여 주기적인 백그라운드 작업을 다시 활성화합니다.

5. GitLab 인스턴스에서 읽기 전용 작업이 예상대로 작동하는지 테스트합니다. 예를 들어, 프로젝트 리포지토리 파일, merge requests, 및 issues를 탐색합니다.

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. 예정된 유지보수 전파 메시지 배너를 제거합니다.