InfoGrab Docs

새 서버로 마이그레이션

요약

GitLab 백업 및 복원을 사용하여 인스턴스를 새 서버로 마이그레이션할 수 있습니다. GitLab Geo를 실행 중인 경우 계획된 페일오버를 위한 Geo 재해 복구가 대안입니다. 새 서버와 이전 서버 모두에서 데이터를 처리하는 비조율된 데이터 처리를 피하세요.

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

GitLab Geo를 실행 중인 경우 계획된 페일오버를 위한 Geo 재해 복구가 대안입니다. Geo를 마이그레이션에 선택하기 전에 모든 사이트가 Geo 요구사항을 충족하는지 확인해야 합니다.

Warning

새 서버와 이전 서버 모두에서 데이터를 처리하는 비조율된 데이터 처리를 피하세요. 여러 서버가 동시에 연결되어 동일한 데이터를 처리할 수 있습니다. 예를 들어 수신 이메일을 사용할 때 두 GitLab 인스턴스가 동시에 이메일을 처리하면 두 인스턴스 모두 일부 데이터를 놓칩니다. 이 유형의 문제는 패키지되지 않은 데이터베이스, 패키지되지 않은 Redis 인스턴스, 패키지되지 않은 Sidekiq와 같은 다른 서비스에서도 발생할 수 있습니다.

사전 요구사항:

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

새 서버 준비#

새 서버를 준비하려면:

  1. 중간자 공격 경고를 피하기 위해 이전 서버에서 새 서버로 SSH 호스트 키를 복사합니다. 예시 단계는 기본 사이트의 SSH 호스트 키를 수동으로 복제를 참조하세요.

  2. GitLab 설치.

  3. 이전 서버에서 새 서버로 /etc/gitlab 파일을 복사하여 구성하고, 필요에 따라 업데이트합니다. 자세한 내용은 Linux 패키지 설치 백업 및 복원 지침을 읽으세요.

  4. 해당하는 경우 수신 이메일을 비활성화합니다.

  5. 백업 및 복원 후 초기 시작 시 새 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"

  6. GitLab 재구성:

    sudo gitlab-ctl reconfigure

  7. 불필요하고 의도하지 않은 데이터 처리를 방지하기 위해 GitLab 중지:

    sudo gitlab-ctl stop

  8. Redis 중지:

    sudo gitlab-ctl stop redis

  9. 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 job이 시작되지 않도록 차단합니다:

    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. 주기적인 백그라운드 job 비활성화:

    1. 오른쪽 상단 모서리에서 Admin을 선택합니다.
    2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택하여 Sidekiq 대시보드를 표시합니다.
    3. Sidekiq 대시보드에서 상단 메뉴의 Cron을 선택합니다.
    4. Sidekiq 대시보드에서 오른쪽 상단의 Disable All을 선택합니다.

  5. 실행 중인 CI/CD job이 완료되기를 기다리거나 완료되지 않은 job이 손실될 수 있음을 인정합니다. 모든 실행 중인 job을 보려면:

    1. 왼쪽 사이드바에서 CI/CD > Jobs를 선택합니다.
    2. 필터 바에서 Status > Running을 선택합니다.

  6. Sidekiq job이 완료되기를 기다립니다:

    1. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
    2. Sidekiq 대시보드에서 상단 메뉴의 Queues를 선택합니다.
    3. Sidekiq 대시보드에서 오른쪽 상단의 Live Poll을 선택합니다. Busy와 Enqueued가 0으로 떨어질 때까지 기다립니다. 이 큐에는 사용자가 제출한 작업이 포함되어 있으며 이 job이 완료되기 전에 종료하면 작업이 손실될 수 있습니다. 마이그레이션 후 검증을 위해 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
gitaly['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 데이터베이스와 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 디렉터리.
  • 사용자 프로필 사진과 같은 업로드 데이터가 포함된 /var/opt/gitlab/gitlab-rails/uploads 디렉터리.
  • 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을 선택하여 주기적인 백그라운드 job을 다시 활성화합니다.

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

  6. 이전에 활성화된 경우 유지 관리 모드를 비활성화합니다.

  7. GitLab 인스턴스가 예상대로 작동하는지 테스트합니다.

  8. 해당하는 경우 수신 이메일을 다시 활성화하고 예상대로 작동하는지 테스트합니다.

  9. 새 서버를 가리키도록 DNS 또는 로드 밸런서를 업데이트합니다.

  10. 이전에 추가한 커스텀 NGINX 구성을 제거하여 새 CI/CD job이 시작되지 않도록 하는 차단을 해제합니다:

    # The following line must be removed
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. 예약된 유지 관리 브로드캐스트 메시지 배너를 제거합니다.

새 서버로 마이그레이션

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

GitLab 백업 및 복원을 사용하여 인스턴스를 새 서버로 마이그레이션할 수 있습니다. GitLab Geo를 실행 중인 경우 계획된 페일오버를 위한 Geo 재해 복구가 대안입니다. 새 서버와 이전 서버 모두에서 데이터를 처리하는 비조율된 데이터 처리를 피하세요.

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

GitLab Geo를 실행 중인 경우 계획된 페일오버를 위한 Geo 재해 복구가 대안입니다. Geo를 마이그레이션에 선택하기 전에 모든 사이트가 Geo 요구사항을 충족하는지 확인해야 합니다.

Warning

새 서버와 이전 서버 모두에서 데이터를 처리하는 비조율된 데이터 처리를 피하세요. 여러 서버가 동시에 연결되어 동일한 데이터를 처리할 수 있습니다. 예를 들어 수신 이메일을 사용할 때 두 GitLab 인스턴스가 동시에 이메일을 처리하면 두 인스턴스 모두 일부 데이터를 놓칩니다. 이 유형의 문제는 패키지되지 않은 데이터베이스, 패키지되지 않은 Redis 인스턴스, 패키지되지 않은 Sidekiq와 같은 다른 서비스에서도 발생할 수 있습니다.

사전 요구사항:

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

새 서버 준비#

새 서버를 준비하려면:

  1. 중간자 공격 경고를 피하기 위해 이전 서버에서 새 서버로 SSH 호스트 키를 복사합니다. 예시 단계는 기본 사이트의 SSH 호스트 키를 수동으로 복제를 참조하세요.

  2. GitLab 설치.

  3. 이전 서버에서 새 서버로 /etc/gitlab 파일을 복사하여 구성하고, 필요에 따라 업데이트합니다. 자세한 내용은 Linux 패키지 설치 백업 및 복원 지침을 읽으세요.

  4. 해당하는 경우 수신 이메일을 비활성화합니다.

  5. 백업 및 복원 후 초기 시작 시 새 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"

  6. GitLab 재구성:

    sudo gitlab-ctl reconfigure

  7. 불필요하고 의도하지 않은 데이터 처리를 방지하기 위해 GitLab 중지:

    sudo gitlab-ctl stop

  8. Redis 중지:

    sudo gitlab-ctl stop redis

  9. 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 job이 시작되지 않도록 차단합니다:

    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. 주기적인 백그라운드 job 비활성화:

    1. 오른쪽 상단 모서리에서 Admin을 선택합니다.
    2. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택하여 Sidekiq 대시보드를 표시합니다.
    3. Sidekiq 대시보드에서 상단 메뉴의 Cron을 선택합니다.
    4. Sidekiq 대시보드에서 오른쪽 상단의 Disable All을 선택합니다.

  5. 실행 중인 CI/CD job이 완료되기를 기다리거나 완료되지 않은 job이 손실될 수 있음을 인정합니다. 모든 실행 중인 job을 보려면:

    1. 왼쪽 사이드바에서 CI/CD > Jobs를 선택합니다.
    2. 필터 바에서 Status > Running을 선택합니다.

  6. Sidekiq job이 완료되기를 기다립니다:

    1. 왼쪽 사이드바에서 Monitoring > Background jobs를 선택합니다.
    2. Sidekiq 대시보드에서 상단 메뉴의 Queues를 선택합니다.
    3. Sidekiq 대시보드에서 오른쪽 상단의 Live Poll을 선택합니다. Busy와 Enqueued가 0으로 떨어질 때까지 기다립니다. 이 큐에는 사용자가 제출한 작업이 포함되어 있으며 이 job이 완료되기 전에 종료하면 작업이 손실될 수 있습니다. 마이그레이션 후 검증을 위해 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
gitaly['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 데이터베이스와 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 디렉터리.
  • 사용자 프로필 사진과 같은 업로드 데이터가 포함된 /var/opt/gitlab/gitlab-rails/uploads 디렉터리.
  • 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을 선택하여 주기적인 백그라운드 job을 다시 활성화합니다.

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

  6. 이전에 활성화된 경우 유지 관리 모드를 비활성화합니다.

  7. GitLab 인스턴스가 예상대로 작동하는지 테스트합니다.

  8. 해당하는 경우 수신 이메일을 다시 활성화하고 예상대로 작동하는지 테스트합니다.

  9. 새 서버를 가리키도록 DNS 또는 로드 밸런서를 업데이트합니다.

  10. 이전에 추가한 커스텀 NGINX 구성을 제거하여 새 CI/CD job이 시작되지 않도록 하는 차단을 해제합니다:

    # The following line must be removed
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. 예약된 유지 관리 브로드캐스트 메시지 배너를 제거합니다.