InfoGrab DocsInfoGrab Docs

새 서버로 마이그레이션

요약

- Offering: GitLab Self-Managed --> GitLab 백업 및 복원을 사용하여 Linux 패키지 인스턴스를 새 서버로 마이그레이션하세요. GitLab Geo를 사용 중인 경우, 대안으로 계획된 장애 조치를 위한 Geo 재해 복구를 사용할 수 있습니다.

새 서버로 마이그레이션#

  - 
  Tier: Free, Premium, Ultimate

- Offering: GitLab Self-Managed

--> GitLab 백업 및 복원을 사용하여 Linux 패키지 인스턴스를 새 서버로 마이그레이션하세요. 또한 Linux 패키지 GitLab 인스턴스를 Docker로 마이그레이션하는 옵션도 있습니다.

GitLab Geo를 사용 중인 경우, 대안으로 계획된 장애 조치를 위한 Geo 재해 복구를 사용할 수 있습니다. 마이그레이션에 Geo를 선택하기 전에 모든 사이트가 Geo 요구 사항을 충족하는지 확인해야 합니다.

새 서버와 기존 서버가 동시에 데이터를 처리하는 비조율 상태를 피하세요. 여러 서버가 동시에 연결되어 동일한 데이터를 처리할 수 있습니다. 예를 들어, [수신 이메일](/19.2/administration/incoming_email/)을 사용하는 경우 두 GitLab 인스턴스가 동시에 이메일을 처리하면 두 인스턴스 모두 일부 데이터를 놓치게 됩니다.

이러한 문제는 비패키지 데이터베이스, 비패키지 Redis 인스턴스, 비패키지 Sidekiq 등 다른 서비스에서도 발생할 수 있습니다.

Prerequisites:

  • 사전에 게시된 브로드캐스트 메시지 배너로 사용자에게 예정된 마이그레이션을 알립니다.

  • 완전하고 최신 상태의 백업. 잘못된 명령어(예: rm)가 실행될 경우에 대비해 전체 시스템 수준 백업을 생성하거나 마이그레이션에 관련된 모든 서버의 스냅샷을 찍으세요.

  • 관리자 액세스 권한.

새 서버 준비#

새 서버를 준비하려면:

중간자 공격(man-in-the-middle attack) 경고를 피하기 위해 기존 서버에서 새 서버로 SSH 호스트 키를 복사하세요. 예시 단계는 기본 사이트의 SSH 호스트 키를 수동으로 복제하기를 참조하세요.

GitLab 설치.

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

해당되는 경우 수신 이메일을 비활성화하세요.

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

GitLab을 재구성하세요:

sudo gitlab-ctl reconfigure

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

sudo gitlab-ctl stop

Redis를 중지하세요:

sudo gitlab-ctl stop redis

Redis 데이터베이스와 GitLab 백업 파일을 수신할 수 있도록 새 서버를 구성하세요:

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

기존 서버에서 콘텐츠 준비 및 전송#

기존 서버의 최신 시스템 수준 백업 또는 스냅샷이 있는지 확인하세요.

GitLab 에디션에서 지원하는 경우 유지 보수 모드를 활성화하세요.

새 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"

GitLab을 재구성하세요:

sudo gitlab-ctl reconfigure

주기적 백그라운드 job을 비활성화하세요:

오른쪽 상단에서 Admin을 선택하세요.

  • 왼쪽 사이드바에서 Monitoring > Background jobs를 선택하여 Sidekiq 대시보드를 표시하세요.

  • Sidekiq 대시보드의 상단 메뉴에서 Cron을 선택하세요.

  • Sidekiq 대시보드의 오른쪽 상단에서 Disable All을 선택하세요.

실행 중인 CI/CD job이 완료될 때까지 기다리거나, 완료되지 않은 job이 손실될 수 있음을 감수하세요. 실행 중인 모든 job을 보려면:

왼쪽 사이드바에서 CI/CD > Jobs를 선택하세요.

  • 필터 바에서 Status > Running을 선택하세요.

Sidekiq job이 완료될 때까지 기다리세요:

왼쪽 사이드바에서 Monitoring > Background jobs를 선택하세요.

  • Sidekiq 대시보드의 상단 메뉴에서 Queues를 선택하세요.

  • Sidekiq 대시보드의 오른쪽 상단에서 Live Poll을 선택하세요. Busy와 Enqueued가 0으로 떨어질 때까지 기다리세요. 이 큐에는 사용자가 제출한 작업이 포함되어 있으며, 이 job들이 완료되기 전에 종료하면 작업이 손실될 수 있습니다. 마이그레이션 후 검증을 위해 Sidekiq 대시보드에 표시된 숫자를 기록해 두세요.

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

GitLab 백업을 생성하세요:

sudo gitlab-backup create

백업이 완료된 후 다음 GitLab 서비스를 비활성화하고 의도치 않은 재시작을 방지하기 위해 /etc/gitlab/gitlab.rb 하단에 다음을 추가하세요:

alertmanager['enable'] = false
gitaly['enable'] = false
gitlab_exporter['enable'] = false
gitlab_pages['enable'] = false
gitlab_workhorse['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

GitLab을 재구성하세요:

sudo gitlab-ctl reconfigure

모든 것이 중지되었는지 확인하고 실행 중인 서비스가 없음을 확인하세요:

sudo gitlab-ctl status

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 인스턴스에 로컬 볼륨에 대용량 데이터(예: 1 TB 이상)가 있는 경우, 백업에 오랜 시간이 걸릴 수 있습니다. 이 경우 새 인스턴스의 적절한 볼륨으로 데이터를 직접 전송하는 것이 더 쉬울 수 있습니다.

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

  • 모든 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나 볼륨 스냅샷 마운트와 같은 도구를 사용하여 데이터를 새 환경으로 이동할 수 있습니다.

새 서버에서 데이터 복원#

적절한 파일 시스템 권한을 복원하세요:

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

Redis를 시작하세요:

sudo gitlab-ctl start redis

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

GitLab 백업 복원.

Redis 데이터베이스가 올바르게 복원되었는지 확인하세요:

오른쪽 상단에서 Admin을 선택하세요.

  • 왼쪽 사이드바에서 Monitoring > Background jobs를 선택하세요.

  • Sidekiq 대시보드에서 숫자가 기존 서버에 표시되었던 숫자와 일치하는지 확인하세요.

  • Sidekiq 대시보드에서 Cron을 선택한 다음 Enable All을 선택하여 주기적 백그라운드 job을 다시 활성화하세요.

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

이전에 활성화된 경우 유지 보수 모드를 비활성화하세요.

GitLab 인스턴스가 예상대로 작동하는지 테스트하세요.

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

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

이전에 추가한 사용자 정의 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"

GitLab을 재구성합니다:

sudo gitlab-ctl reconfigure

예약된 유지 보수 공지 메시지 배너를 제거합니다.

새 서버로 마이그레이션

GitLab v19.2
원문 보기
요약

- Offering: GitLab Self-Managed --> GitLab 백업 및 복원을 사용하여 Linux 패키지 인스턴스를 새 서버로 마이그레이션하세요. GitLab Geo를 사용 중인 경우, 대안으로 계획된 장애 조치를 위한 Geo 재해 복구를 사용할 수 있습니다.

새 서버로 마이그레이션#

  - 
  Tier: Free, Premium, Ultimate

- Offering: GitLab Self-Managed

--> GitLab 백업 및 복원을 사용하여 Linux 패키지 인스턴스를 새 서버로 마이그레이션하세요. 또한 Linux 패키지 GitLab 인스턴스를 Docker로 마이그레이션하는 옵션도 있습니다.

GitLab Geo를 사용 중인 경우, 대안으로 계획된 장애 조치를 위한 Geo 재해 복구를 사용할 수 있습니다. 마이그레이션에 Geo를 선택하기 전에 모든 사이트가 Geo 요구 사항을 충족하는지 확인해야 합니다.

새 서버와 기존 서버가 동시에 데이터를 처리하는 비조율 상태를 피하세요. 여러 서버가 동시에 연결되어 동일한 데이터를 처리할 수 있습니다. 예를 들어, [수신 이메일](/19.2/administration/incoming_email/)을 사용하는 경우 두 GitLab 인스턴스가 동시에 이메일을 처리하면 두 인스턴스 모두 일부 데이터를 놓치게 됩니다.

이러한 문제는 비패키지 데이터베이스, 비패키지 Redis 인스턴스, 비패키지 Sidekiq 등 다른 서비스에서도 발생할 수 있습니다.

Prerequisites:

  • 사전에 게시된 브로드캐스트 메시지 배너로 사용자에게 예정된 마이그레이션을 알립니다.

  • 완전하고 최신 상태의 백업. 잘못된 명령어(예: rm)가 실행될 경우에 대비해 전체 시스템 수준 백업을 생성하거나 마이그레이션에 관련된 모든 서버의 스냅샷을 찍으세요.

  • 관리자 액세스 권한.

새 서버 준비#

새 서버를 준비하려면:

중간자 공격(man-in-the-middle attack) 경고를 피하기 위해 기존 서버에서 새 서버로 SSH 호스트 키를 복사하세요. 예시 단계는 기본 사이트의 SSH 호스트 키를 수동으로 복제하기를 참조하세요.

GitLab 설치.

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

해당되는 경우 수신 이메일을 비활성화하세요.

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

GitLab을 재구성하세요:

sudo gitlab-ctl reconfigure

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

sudo gitlab-ctl stop

Redis를 중지하세요:

sudo gitlab-ctl stop redis

Redis 데이터베이스와 GitLab 백업 파일을 수신할 수 있도록 새 서버를 구성하세요:

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

기존 서버에서 콘텐츠 준비 및 전송#

기존 서버의 최신 시스템 수준 백업 또는 스냅샷이 있는지 확인하세요.

GitLab 에디션에서 지원하는 경우 유지 보수 모드를 활성화하세요.

새 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"

GitLab을 재구성하세요:

sudo gitlab-ctl reconfigure

주기적 백그라운드 job을 비활성화하세요:

오른쪽 상단에서 Admin을 선택하세요.

  • 왼쪽 사이드바에서 Monitoring > Background jobs를 선택하여 Sidekiq 대시보드를 표시하세요.

  • Sidekiq 대시보드의 상단 메뉴에서 Cron을 선택하세요.

  • Sidekiq 대시보드의 오른쪽 상단에서 Disable All을 선택하세요.

실행 중인 CI/CD job이 완료될 때까지 기다리거나, 완료되지 않은 job이 손실될 수 있음을 감수하세요. 실행 중인 모든 job을 보려면:

왼쪽 사이드바에서 CI/CD > Jobs를 선택하세요.

  • 필터 바에서 Status > Running을 선택하세요.

Sidekiq job이 완료될 때까지 기다리세요:

왼쪽 사이드바에서 Monitoring > Background jobs를 선택하세요.

  • Sidekiq 대시보드의 상단 메뉴에서 Queues를 선택하세요.

  • Sidekiq 대시보드의 오른쪽 상단에서 Live Poll을 선택하세요. Busy와 Enqueued가 0으로 떨어질 때까지 기다리세요. 이 큐에는 사용자가 제출한 작업이 포함되어 있으며, 이 job들이 완료되기 전에 종료하면 작업이 손실될 수 있습니다. 마이그레이션 후 검증을 위해 Sidekiq 대시보드에 표시된 숫자를 기록해 두세요.

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

GitLab 백업을 생성하세요:

sudo gitlab-backup create

백업이 완료된 후 다음 GitLab 서비스를 비활성화하고 의도치 않은 재시작을 방지하기 위해 /etc/gitlab/gitlab.rb 하단에 다음을 추가하세요:

alertmanager['enable'] = false
gitaly['enable'] = false
gitlab_exporter['enable'] = false
gitlab_pages['enable'] = false
gitlab_workhorse['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

GitLab을 재구성하세요:

sudo gitlab-ctl reconfigure

모든 것이 중지되었는지 확인하고 실행 중인 서비스가 없음을 확인하세요:

sudo gitlab-ctl status

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 인스턴스에 로컬 볼륨에 대용량 데이터(예: 1 TB 이상)가 있는 경우, 백업에 오랜 시간이 걸릴 수 있습니다. 이 경우 새 인스턴스의 적절한 볼륨으로 데이터를 직접 전송하는 것이 더 쉬울 수 있습니다.

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

  • 모든 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나 볼륨 스냅샷 마운트와 같은 도구를 사용하여 데이터를 새 환경으로 이동할 수 있습니다.

새 서버에서 데이터 복원#

적절한 파일 시스템 권한을 복원하세요:

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

Redis를 시작하세요:

sudo gitlab-ctl start redis

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

GitLab 백업 복원.

Redis 데이터베이스가 올바르게 복원되었는지 확인하세요:

오른쪽 상단에서 Admin을 선택하세요.

  • 왼쪽 사이드바에서 Monitoring > Background jobs를 선택하세요.

  • Sidekiq 대시보드에서 숫자가 기존 서버에 표시되었던 숫자와 일치하는지 확인하세요.

  • Sidekiq 대시보드에서 Cron을 선택한 다음 Enable All을 선택하여 주기적 백그라운드 job을 다시 활성화하세요.

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

이전에 활성화된 경우 유지 보수 모드를 비활성화하세요.

GitLab 인스턴스가 예상대로 작동하는지 테스트하세요.

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

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

이전에 추가한 사용자 정의 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"

GitLab을 재구성합니다:

sudo gitlab-ctl reconfigure

예약된 유지 보수 공지 메시지 배너를 제거합니다.