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

Geo 클라이언트 및 HTTP 응답 코드 오류 문제 해결에 대해 설명합니다.

클라이언트 오류 수정 # LFS HTTP(S) 클라이언트 요청의 인증 오류 # 2.4.2 이전 버전의 Git LFS 를 실행하는 경우 문제가 발생할 수 있습니다. 이 인증 문제 에서 언급된 것처럼, 보조 사이트에서 기본 사이트로 리디렉션된 요청이 Authorization 헤더를 올바르게 전송하지 않습니다. 이로 인해 무한 Authorization <-> Redirect 루프 또는 Authorization 오류 메시지가 발생할 수 있습니다. Geo 보조 사이트에서 SSH를 통해 푸시할 때 Net::ReadTimeout 오류 # Geo 보조 사이트에서 SSH를 통해 대용량 리포지터리를 푸시할 때 타임아웃이 발생할 수 있습니다. 이는 Rails가 기본 사이트로 푸시를 프록시하며 이 Geo 문제 에 설명된 것처럼 60초 기본 타임아웃이 있기 때문입니다. 현재 해결 방법은 다음과 같습니다: HTTP를 통해 푸시합니다. 이 경우 Workhorse가 기본 사이트로 요청을 프록시하거나 (Geo 프록시가 활성화되지 않은 경우) 기본 사이트로 리디렉션합니다. 기본 사이트로 직접 푸시합니다. 예시 로그 ( 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/socke