Geo 클라이언트 및 HTTP 응답 코드 오류 해결
클라이언트 오류 수정
LFS HTTP(S) 클라이언트 요청의 인가 오류
Git LFS 2.4.2 이전 버전을 실행 중이면 문제가 발생할 수 있습니다.
이 인증 문제에 언급된대로, 보조 사이트에서 주 사이트로 리디렉션된 요청은 인가 헤더를 올바르게 전송하지 않습니다. 이로 인해 무한 인가 <-> 리디렉트 루프 또는 인가 오류 메시지가 발생할 수 있습니다.
Geo 보조 사이트에서 SSH를 통해 푸시할 때 Error: 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"
이 문제를 해결하려면 다음을 수행하세요:
- 모든 보조 사이트의 웹 노드의
/etc/gitlab.rb에서nginx['proxy_custom_buffer_size'] = '8k'를 설정합니다. -
sudo gitlab-ctl reconfigure를 사용하여 보조를 다시 구성합니다.
이 오류가 계속 발생하는 경우, 위의 단계를 반복하여 8k 크기를 더 크게 변경하여(예: 16k) 버퍼 크기를 늘릴 수 있습니다.
Geo Admin 영역이 건강 상태에 대해 Unknown를 표시하고 ‘상태 코드 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
이는 GitLab이 Geo 추적 데이터베이스에 대한 레지스트리를 표시하려고 시도하기 때문에 발생합니다. 주 사이트에는 이러한 데이터베이스가 존재하지 않으므로(기본 프로젝트만 존재하며 복제된 프로젝트는 없으므로 추적 데이터베이스도 없음) 이 오류는 무시해도 됩니다.
보조 사이트가 Request header or cookie too large 400 에러를 반환
이 오류는 주 사이트의 내부 URL이 잘못된 경우에 발생할 수 있습니다.
예를 들어, 통합 URL을 사용하고 주 사이트의 내부 URL이 외부 URL과 동일한 경우에 발생할 수 있습니다. 이는 보조 사이트가 주 사이트의 내부 URL로 요청을 프록시하면 루프가 발생시키기 때문입니다.
이 문제를 해결하려면 주 사이트의 내부 URL을 다음과 같이 설정합니다:
- 주 사이트와 고유한 URL로 설정합니다.
- 모든 보조 사이트에서 접근 가능한 URL로 설정합니다.
- 주 사이트를 방문합니다.
- 내부 URL을 설정합니다.
보조 사이트가 Received HTTP code 403 from proxy after CONNECT 반환
Linux 패키지(Omnibus)를 사용하여 GitLab을 설치한 경우, Gitaly를 위해 no_proxy 사용자 정의 환경 변수를 구성했고 다음과 같은 버전이 영향을 받았으며,이 문제를 경험할 수 있습니다:
15.4.6-
15.5.0-15.5.6 -
15.6.0-15.6.3 -
15.7.0-15.7.1
이는 Linux 패키지 15.4.6 및 이후 버전과 함께 제공된 버전의 cURL에서 발생한 버그로 인한 문제입니다. 이 버그로 인해 와일드카드 도메인(.example.com)을 제외하고는 모든 도메인이 no_proxy 환경 변수 목록에서 마지막 (n-1)으로 무시됩니다. 따라서 더 높은 버전으로 업그레이드할 수없는 경우 환경 변수 목록에서 와일드카드 도메인을 끝으로 이동하여 문제를 해결할 수 있습니다.
-
/etc/gitlab/gitlab.rb를 편집합니다:gitaly['env'] = { "no_proxy" => "sever.yourdomain.org, .yourdomain.com", } -
GitLab을 다시 구성합니다:
sudo gitlab-ctl reconfigure
no_proxy 목록에는 와일드카드 도메인이 하나만 있어야 합니다.
Geo 행정 영역에서 보조 사이트에 대한 404 오류 반환
가끔씩 sudo gitlab-rake gitlab:geo:check에서는 보조 사이트의 Rails 노드가 건강하다고 나타나지만, 기본 사이트의 웹 인터페이스에서 Geo Admin 영역에 보조 사이트에 대한 404 Not Found 오류 메시지가 표시됩니다.
이 문제를 해결하려면:
-
sudo gitlab-ctl restart을 사용하여 보조 사이트의 각 Rails, Sidekiq 및 Gitaly 노드를 다시 시작해 보세요. -
기본 사이트에서 IPv6를 사용하여 보조 사이트에 상태를 보내는지 확인하려면 Sidekiq 노드의
/var/log/gitlab/gitlab-rails/geo.log를 확인하세요. 그렇다면/etc/hosts파일에 IPv4를 이용해 기본 사이트에 항목을 추가하세요. 또는 기본 사이트에서 IPv6를 활성화해야 합니다.
도움말