Geo 클라이언트 및 HTTP 응답 코드 오류 해결
클라이언트 오류 수정
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 콘솔 세션을 시작하고 다음 단계를 수행하세요:
-
영향 받는 노드를 찾기 위해 먼저 가지고 있는 모든 Geo 노드를 나열합니다:
GeoNode.all
-
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"
이 문제를 해결하기 위해:
-
secondary 사이트의 모든 웹 노드의
/etc/gitlab.rb
에nginx['proxy_custom_buffer_size'] = '8k'
를 설정합니다. -
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 추적 데이터베이스가 존재하지 않기 때문에(기본 사이트에는 복제된 프로젝트가 없으므로 추적 데이터베이스도 존재하지 않음) 발생합니다.
보조 사이트에서 Request header or cookie too large
로 400 오류를 반환하는 경우
이 오류는 기본 사이트의 내부 URL이 잘못된 경우 발생할 수 있습니다.
예를 들어, 통합 URL을 사용하고 기본 사이트의 내부 URL이 외부 URL과 동일한 경우에 발생합니다. 이 경우에 보조 사이트가 요청을 기본 사이트의 내부 URL로 프록시하면 루프가 발생합니다.
이 문제를 해결하려면 기본 사이트의 내부 URL을 다음과 같은 URL로 설정하세요:
- 기본 사이트에만 해당되는 고유한 URL
- 모든 보조 사이트에서 접근 가능한 URL
- 기본 사이트를 방문하세요.
- 내부 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를 활성화하세요.