Geo 클라이언트 및 HTTP 응답 코드 오류 해결

Tier: Premium, Ultimate Offering: Self-Managed

클라이언트 오류 수정

LFS HTTP(S) 클라이언트 요청의 권한 오류

만약 Git LFS v2.4.2 이전의 버전을 실행하고 있다면 문제가 발생할 수 있습니다. 이 인증 오류에서 언급된 대로, 보조 사이트에서 본 사이트로 리디렉션이 되는 경우 권한 헤더를 올바르게 보내지 않을 수 있습니다. 이로 인해 무한한 Authorization <-> Redirect 루프 또는 권한 오류 메시지가 발생할 수 있습니다.

오류: Geo 보조 사이트에서 SSH를 통한 푸시 시 Net::ReadTimeout

Geo 보조 사이트에서 SSH를 통해 대용량 리포지터리를 푸시하는 경우 시간 초과 오류가 발생할 수 있습니다. 이는 Rails가 푸시를 기본적으로 본 서버로 프록시하고 60초의 기본 시간 초과가 있기 때문입니다, 이 Geo 이슈에서 설명한 대로입니다.

현재 사용 가능한 해결책은:

  • Geo 프록시가 활성화되어 있지 않은 경우 Workhorse가 요청을 본 서버로 프록시하거나 본 서버로 리디렉션하는 HTTP를 통한 푸시
  • 본 서버로 직접 푸시

예시 로그 (gitlab-shell.log): 

Failed to contact primary https://primary.domain.com/namespace/push_test.git\\nError: Net::ReadTimeout\",\"result\":null}" code=500 method=POST pid=5483 url="http://127.0.0.1:3000/api/v4/geo/proxy_git_push_ssh/push"

Geo 사이트 간 OAuth 인증 복구

Geo 사이트를 업그레이드할 때, 인증에 OAuth만 사용하는 보조 사이트에 로그인할 수 없을 수 있습니다. 그런 경우, 본 사이트에서 Rails 콘솔 세션을 시작하고 다음 단계를 수행하세요:

  1. 영향 받는 노드를 찾기 위해 먼저 가지고 있는 모든 Geo 노드를 나열합니다: 

    GeoNode.all

  2. ID를 지정하여 영향받는 Geo 노드를 복구합니다: 

    GeoNode.find(<id>).repair

HTTP 응답 코드 오류

Geo 프록시를 사용하여 보조 사이트가 502 오류를 반환하는 경우

Geo 프록시를 위한 보조 사이트와 관련하여 502 오류가 발생하고 보조 사이트 사용자 인터페이스에서 반환되는 경우, 본 사이트로부터 프록시된 응답 헤더가 너무 큰 경우가 있을 수 있습니다.

다음 예제와 유사한 NGINX 로그를 확인하세요: 

2022/01/26 00:02:13 [error] 26641#0: *829148 upstream sent too big header while reading response header from upstream, client: 10.0.2.2, server: geo.staging.gitlab.com, request: "POST /users/sign_in HTTP/2.0", upstream: "http://unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket:/users/sign_in", host: "geo.staging.gitlab.com", referrer: "https://geo.staging.gitlab.com/users/sign_in"

이 문제를 해결하기 위해:

  1. secondary 사이트의 모든 웹 노드의 /etc/gitlab.rb에 nginx['proxy_custom_buffer_size'] = '8k'를 설정합니다.
  2. sudo gitlab-ctl reconfigure를 사용하여 secondary를 다시 구성합니다.

만약 이 오류가 계속된다면, 위의 단계를 반복하여 8k 크기를 두배인 16k로 변경하여 버퍼 크기를 더 크게 할 수 있습니다.

Geo Admin 영역이 건강 상태에 대한 ‘알 수 없음’ 및 ‘상태 코드 401으로 실패한 요청’을 표시

로드 밸런서를 사용하고 있는 경우, 로드 밸런서의 URL이 로드 밸런서 뒤의 노드들의 /etc/gitlab/gitlab.rb에 external_url로 설정되어 있는지 확인하세요.

본 서버가 /admin/geo/replication/projects에 액세스할 때 500 오류를 반환

기본 Geo 사이트에서 Admin > Geo > Replication (또는 /admin/geo/replication/projects)에 이동하면 500 오류가 표시되는 경우가 발생합니다. 반면 해당 링크를 클릭하면 보조 사이트에서는 작동하는 경우가 있습니다. 기본 사이트의 production.log에 다음과 유사한 항목이 있을 수 있습니다: 

Geo::TrackingBase::SecondaryNotConfigured: Geo secondary database is not configured
  from ee/app/models/geo/tracking_base.rb:26:in `connection'
  [..]
  from ee/app/views/admin/geo/projects/_all.html.haml:1

이는 기본 사이트에는 Geo 추적 데이터베이스가 존재하지 않기 때문에(기본 사이트에는 복제된 프로젝트가 없으므로 추적 데이터베이스도 존재하지 않음) 발생합니다.

이 오류는 기본 사이트의 내부 URL이 잘못된 경우 발생할 수 있습니다.

예를 들어, 통합 URL을 사용하고 기본 사이트의 내부 URL이 외부 URL과 동일한 경우에 발생합니다. 이 경우에 보조 사이트가 요청을 기본 사이트의 내부 URL로 프록시하면 루프가 발생합니다.

이 문제를 해결하려면 기본 사이트의 내부 URL을 다음과 같은 URL로 설정하세요:

  • 기본 사이트에만 해당되는 고유한 URL
  • 모든 보조 사이트에서 접근 가능한 URL
  1. 기본 사이트를 방문하세요.
  2. 내부 URL 설정을 수행하세요.

Geo Admin 영역이 보조 사이트에 대해 404 오류 반환

가끔씩 sudo gitlab-rake gitlab:geo:check 명령을 실행하면 Rails 노드가 보조 사이트에 대한 상태가 정상임에도 불구하고 기본 사이트의 웹 인터페이스에는 보조 사이트에 대한 404 Not Found 오류 메시지가 표시될 수 있습니다.

이 문제를 해결하기 위해:

  • sudo gitlab-ctl restart를 사용하여 보조 사이트의 각 Rails, Sidekiq 및 Gitaly 노드를 다시 시작하세요.
  • 기본 사이트의 hosts 파일에 IPv4를 사용하여 보조 사이트의 상태를 보내도록 설정되어 있는지 확인하기 위해 Sidekiq 노드의 /var/log/gitlab/gitlab-rails/geo.log를 확인하세요. 만약 그렇다면, hosts 파일에 IPv6 대신 IPv4로 각각 primary 사이트에 엔트리를 추가하세요. 또는 기본 사이트에서 IPv6를 활성화하세요.