새 서버로 마이그레이션

GitLab 백업 및 복원을 사용하여 Linux 패키지 인스턴스를 새 서버로 마이그레이션하는 방법을 설명합니다.

새 서버로 마이그레이션 # - Tier: Free, Premium, Ultimate - Offering: GitLab Self-Managed --> GitLab 백업 및 복원을 사용하여 Linux 패키지 인스턴스를 새 서버로 마이그레이션하세요. 또한 Linux 패키지 GitLab 인스턴스를 Docker로 마이그레이션 하는 옵션도 있습니다. GitLab Geo를 사용 중인 경우, 대안으로 계획된 장애 조치를 위한 Geo 재해 복구 를 사용할 수 있습니다. 마이그레이션에 Geo를 선택하기 전에 모든 사이트가 Geo 요구 사항 을 충족하는지 확인해야 합니다. 새 서버와 기존 서버가 동시에 데이터를 처리하는 비조율 상태를 피하세요. 여러 서버가 동시에 연결되어 동일한 데이터를 처리할 수 있습니다. 예를 들어, [수신 이메일](/19.1/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-linu