리포지터리 미러링 문제 해결

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

미러링이 실패하면 프로젝트 유지자는 프로젝트 세부 정보 페이지에서 풀 미러링이 1시간 전에 실패했습니다.와 유사한 링크를 볼 수 있습니다. 이 링크를 선택하여 미러링 설정 페이지로 직접 이동하면, GitLab이 미러링된 리포지터리에 대한 오류 배지를 표시합니다. 이 배지 위로 마우스 커서를 가져가면 오류 텍스트가 표시됩니다:

호버하면 표시되는 오류 메시지

GitHub에서 에러 코드 2가 포함된 RST_STREAM 수신

GitHub 리포지터리로 미러링을 하는 도중에 이 메시지를 받는 경우: 

13: RST_STREAM과 오류 코드 2 수신

다음 중 하나의 문제가 발생할 수 있습니다:

  1. GitHub 설정에서 커밋에 사용된 이메일 주소를 노출하는 푸시를 차단하도록 설정되어 있을 수 있습니다. 이 문제를 해결하려면 다음 중 하나를 수행하십시오:
  2. 귀하의 리포지터리가 GitHub의 100MB 파일 크기 제한을 초과했을 수 있습니다. 이 문제를 해결하려면 GitHub에서 구성된 파일 크기 제한을 확인하고, 대용량 파일을 관리하기 위해 Git Large File Storage를 사용하는 것을 고려할 수 있습니다.

마감 기한 초과

GitLab을 업그레이드할 때, 사용자 이름이 어떻게 표시되는지에 대한 변경으로, 미러링 사용자 이름과 암호를 업데이트하여 %40 문자가 @로 대체되도록 해야 합니다.

서버가 공개 키 인증만 허용하므로 연결이 차단됨

GitLab과 원격 리포지터리 간의 연결이 차단되었습니다. TCP 체크가 성공적이더라도, GitLab에서 원격 서버로의 경로에서 네트워킹 컴포넌트를 확인해야 합니다.

이러한 오류는 방화벽이 동일한 패킷에서 Deep SSH Inspection을 수행할 때 발생할 수 있습니다.

사용자 이름을 읽을 수 없음: 터미널 프롬프트가 비활성화됨

이 오류가 발생하는 경우, 새 프로젝트를 만든 후 외부 리포지터리용 GitLab CI/CD를 사용할 때:

  • Bitbucket Cloud에서: 

    "2:원격 가져오기: "fatal: could not read Username for 'https://bitbucket.org':
terminal prompts disabled\n": exit status 128."

  • Bitbucket Server (Self-managed): 

    "2:원격 가져오기: "fatal: could not read Username for 'https://lab.example.com':
terminal prompts disabled\n": exit status 128.

미러링된 리포지터리 URL에 소유자가 지정되어 있는지 확인하십시오:

  1. 왼쪽 사이드바에서 검색 또는 이동하여를 선택하여 프로젝트를 찾습니다.
  2. 설정 > 리포지터리를 선택합니다.
  3. 리포지터리 미러링을 확장합니다.

  4. 소유자가 지정되지 않은 경우, 다음 형식으로 URL을 삭제하고 다시 추가하십시오. 여기서 OWNER, ACCOUNTNAME, PATH_TO_REPO, 그리고 REPONAME을 각각의 값으로 바꿔 넣습니다:

    • Bitbucket Cloud에서: 

      https://OWNER@bitbucket.org/ACCOUNTNAME/REPONAME.git

    • Bitbucket Server (Self-managed): 

      https://OWNER@lab.example.com/PATH_TO_REPO/REPONAME.git

미러링할 클라우드 또는 Self-managed 비트버킷 리포지터리에는 URL에 소유자가 지정되어야 합니다.

풀 미러링에서 LFS 파일이 누락됨

경우에 따라 풀 미러링이 LFS 파일을 전송하지 않을 수 있습니다. 이 문제는 다음 경우에 발생합니다:

풀 미러링이 파이프라인을 활성화하지 않음

다음과 같은 이유로 파이프라인이 실행되지 않을 수 있습니다:

  • 미러링 업데이트를 활성화하여 파이프라인을 트리거함 설정이 비활성화되어 있을 수 있습니다. 이 설정은 초기 풀 미러링 구성시에만 활성화할 수 있습니다. 프로젝트를 확인한 후에는 상태가 표시되지 않음 . 외부 리포지터리용 CI/CD가 사용된 미러링이 매뉴얼으로 재구성되면, 파이프라인을 트리거하는 것이 기본적으로 꺼져 있고, 이로 인해 파이프라인이 실행되지 않을 수 있습니다.
  • rules 구성으로 인해 어떠한 작업도 파이프라인에 추가되지 않을 수 있습니다.
  • 파이프라인이 풀 미러링을 설정한 계정 을 사용하여 트리거되었을 수 있습니다. 계정이 더 이상 유효하지 않으면, 파이프라인이 실행되지 않습니다.
  • 브랜치 보호 설정이 미러링을 설정한 계정으로부터 파이프라인 실행을 방해할 수 있습니다.

리포지터리가 업데이트 중임이지만 실패 및 성공이 명확히 표시되지 않음

드물게, Redis에서의 미러링 슬롯이 고갈되는 경우가 발생할 수 있습니다. 이는 아웃오브메모리 (OoM) 이벤트로 인해 Sidekiq 워커가 종료되는 경우 등이 발생합니다. 이 경우, 미러링 작업이 빠르게 시작되고 완료되지만, 실패하거나 성공하지 않습니다. 또한 명확한 로그가 남지 않습니다. 이 문제를 확인하려면:

  1. Rails 콘솔로 들어가서 Redis의 미러링 용량을 확인합니다: 

    current = Gitlab::Redis::SharedState.with { |redis| redis.scard('MIRROR_PULL_CAPACITY') }.to_i
maximum = Gitlab::CurrentSettings.mirror_max_capacity
available = maximum - current

  2. 미러링용 용량이 0 또는 매우 낮으면 다음과 같이 모든 정체된 작업을 비워낼 수 있습니다: 

    Gitlab::Redis::SharedState.with { |redis| redis.smembers('MIRROR_PULL_CAPACITY') }.each do |pid|
  Gitlab::Redis::SharedState.with { |redis| redis.srem('MIRROR_PULL_CAPACITY', pid) }
end

  3. 명령을 실행한 후, 백그라운드 작업 페이지 에 새로운 미러링 작업이 예약되는 것을 확인할 수 있습니다, 특히 수동으로 트리거되었을 때.

잘못된 URL

이 오류가 발생하는 경우 SSH를 통해 미러링을 설정하는 동안 URL이 유효한 형식인지 확인하십시오.

미러링은 SSH 클론 URL의 짧은 버전인(git@gitlab.com:gitlab-org/gitlab.git)을 지원하지 않으며 프로토콜(ssh://git@gitlab.com/gitlab-org/gitlab.git)을 포함한 전체 버전이 필요합니다.

호스트 및 프로젝트 경로가 : 대신 /을 사용하여 분리되었는지 확인하십시오.

호스트 키 확인 실패

이 오류는 대상 호스트 공개 SSH 키가 변경될 때 반환됩니다. 공개 SSH 키는 거의 변경되지 않습니다. 호스트 키 확인이 실패하더라도 키가 여전히 유효하다고 의심되면 키 정보를 새로고침할 수 있습니다.

전제 조건:

  • 프로젝트의 최소 Maintainer 역할이 있어야 합니다.

문제 해결 방법:

  1. 호스트 키 확인을 확인합니다.
  2. 왼쪽 사이드 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  3. 설정 > 리포지터리를 선택합니다.
  4. 리포지터리 미러링을 확장합니다.

  5. 키를 새로 고치려면:

    • GitLab이 서버에서 호스트 키를 가져와 지문을 표시하도록 호스트 키 감지를 선택합니다.
    • 매뉴얼으로 호스트 키를 입력하려면 매뉴얼으로 호스트 키 입력을 선택하고 호스트 키를 SSH 호스트 키 필드에 입력합니다.
  • 리포지터리 미러링을 선택합니다.

Rails 콘솔에서 미러 사용자 및 토큰을 단일 서비스 계정으로 이전

이 작업에는 GitLab Rails 콘솔에 대한 액세스가 필요합니다.

사례: 여러 사용자가 자체 GitHub 자격 증명을 사용하여 리포지터리 미러링을 설정하는 경우, 사람들이 회사를 떠날 때 미러링이 깨집니다. 서로 다른 미러링 사용자 및 토큰을 하나의 서비스 계정으로 마이그레이션하려면 이 스크립트를 사용하세요:

caution
데이터를 변경하는 명령은 올바르게 실행되지 않거나 올바른 조건 하에서 실행되지 않을 경우에는 손상을 일으킬 수 있습니다. 항상 먼저 테스트 환경에서 명령을 실행하고 복원할 백업 인스턴스가 준비되어 있어야 합니다.
svc_user = User.find_by(username: 'ourServiceUser')
token = 'githubAccessToken'

Project.where(mirror: true).each do |project|
  import_url = project.import_url
  
  # 우리가 원하는 URL은 https://token@project/path.git입니다.
  repo_url = if import_url.include?('@')
               # Case 1: URL이 https://23423432@project/path.git과 같은 경우
               import_url.split('@').last
             elsif import_url.include?('//')
               # Case 2: URL이 https://project/path.git과 같은 경우
               import_url.split('//').last
             end
  
  next unless repo_url
  
  final_url = "https://#{token}@#{repo_url}"
  
  project.mirror_user = svc_user
  project.import_url = final_url
  project.username_only_import_url = final_url
  project.save
end

The requested URL returned error: 301

http:// 또는 https:// 프로토콜을 사용하여 미러링하는 경우 리포지터리의 정확한 URL을 지정해야 합니다: https://gitlab.example.com/group/project.git

HTTP 리디렉션이 따르지 않으며 .git을 생략하면 301 오류가 발생할 수 있습니다: 

13:fetch remote: "fatal: unable to access 'https://gitlab.com/group/project': The requested URL returned error: 301\n": exit status 128.

GitLab 인스턴스에서 Geo 보조 노드로 미러 푸시 실패: The requested URL returned error: 302

HTTP 또는 HTTPS 프로토콜을 사용하여 GitLab 리포지터리의 미러링을 Geo 보조 노드로 푸시하는 경우, 푸시 요청을 Geo 주 노드로 프록시하는 동안 실패하고 다음과 같은 오류가 표시됩니다: 

13:get remote references: create git ls-remote: exit status 128, stderr: "fatal: unable to access 'https://gitlab.example.com/group/destination.git/': The requested URL returned error: 302".

이는 Geo 통합 URL이 구성되어 있고 대상 호스트 이름이 보조 노드의 IP 주소로 변환될 때 발생합니다.

오류 해결 방법:

  • 푸시 미러링을 SSH 프로토콜을 사용하도록 구성합니다. 그러나 리포지터리에는 항상 HTTP 또는 HTTPS를 통해 전송되는 LFS 객체가 포함되어 있으면 안 됩니다.
  • 소스 인스턴스에서 모든 요청을 주 Geo 노드로 리디렉션하는 역방향 프록시를 사용합니다.
  • 소스에서 대상 호스트 이름을 주 Geo 노드의 IP 주소로 변환하도록 로컬 hosts 파일 항목을 추가합니다.
  • 대신 대상에서 pull 미러를 구성합니다.