새 서버로 이전

인스턴스를 새 서버로 마이그레이션하려면 GitLab 백업 및 복원을 사용할 수 있습니다. 이 섹션에서는 단일 서버에서 실행되는 GitLab 배포에 대한 전형적인 절차를 개요로 설명합니다. GitLab Geo를 실행 중인 경우 대체 옵션으로 계획된 장애 조치용 Geo 재해 복구가 있습니다.

caution
새 서버와 이전 서버가 혼란스럽게 데이터 처리를 하지 않도록하십시오. 여러 서버가 동시에 연결되어 동일한 데이터를 처리할 수 있습니다. 예를 들어 수신 이메일을 사용하는 경우 두 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. 새 서버에서 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 대시보드에서 크론 탭을 선택한 후 모두 비활성화를 선택합니다.
  5. 현재 실행 중인 CI/CD 작업이 완료될 때까지 기다리거나 완료되지 않은 작업이 손실될 수 있다는 사실을 받아들입니다. 현재 실행 중인 작업을 보려면 왼쪽 사이드바에서 개요 > 작업을 선택한 후 실행 중을 선택합니다.
  6. Sidekiq 작업이 완료될 때까지 기다립니다:
    1. 왼쪽 사이드바에서 모니터링 > 백그라운드 작업을 선택합니다.
    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를 중지하고 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

새 서버에 데이터 복원하기

  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. 왼쪽 사이드바에서 Monitoring > Background Jobs를 선택합니다.
    3. Sidekiq 대시보드에서 숫자가 이전 서버에 표시된 것과 일치하는지 확인합니다.
    4. 여전히 Sidekiq 대시보드에서 Cron을 선택한 다음 모두 켜기를 선택하여 주기적인 백그라운드 작업을 다시 활성화합니다.
  5. GitLab 인스턴스의 읽기 전용 작업이 예상대로 작동하는지 테스트합니다. 예를 들어, 프로젝트 리포지터리 파일, Merge Request 및 이슈를 둘러봅니다.
  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. 예약된 유지 보수 방송 메시지 배너를 제거합니다.