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

Tier: Premium, Ultimate Offering: Self-managed

클라이언트 오류 수정

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

Git LFS의 2.4.2 이전 버전을 사용하고 있다면 문제가 발생할 수 있습니다.
this authentication issue에서 언급한 바와 같이,
보조 사이트에서 기본 사이트로 리디렉션된 요청은
Authorization 헤더를 제대로 전송하지 않습니다. 이는 무한한 Authorization <-> Redirect
루프 또는 권한 부여 오류 메시지가 발생할 수 있습니다.

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

Geo 보조 사이트에서 SSH를 통해 대형 리포지토리를 푸시하면 시간 초과가 발생할 수 있습니다.
이는 Rails가 기본으로 푸시를 프록시하며 기본 60초 시간 초과가 있기 때문입니다.
이 Geo 이슈에서 설명되었습니다.

현재 우회 방법은 다음과 같습니다:

  • 대신 HTTP를 통해 푸시합니다. 이 경우 Workhorse가 요청을 기본으로 프록시합니다(또는 Geo 프록시가 활성화되지 않은 경우 기본으로 리디렉션합니다).
  • 기본(site)으로 직접 푸시합니다.

예시 로그 (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. 모든 웹 노드에서 /etc/gitlab.rb 파일에 nginx['proxy_custom_buffer_size'] = '8k'를 설정합니다.
  2. sudo gitlab-ctl reconfigure를 사용하여 보조 사이트의 구성을 다시 설정합니다.

여전히 이 오류가 발생하면, 위의 단계를 반복하여 버퍼 크기를 추가로 늘리면서 8k 크기를 변경합니다. 예를 들어, 16k로 두 배로 늘릴 수 있습니다.

Geo 관리 영역에서 건강 상태가 Unknown으로 표시되고 ‘요청이 401 상태 코드로 실패했습니다’라는 메시지 표시

로드 밸런서를 사용하는 경우, 로드 밸런서 뒤에 있는 노드의 /etc/gitlab/gitlab.rb에서 로드 밸런서의 URL이 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 기본 사이트에서는 이 오류를 무시할 수 있습니다.

이는 GitLab이 기본 사이트에는 존재하지 않는 Geo 추적 데이터베이스에서 레지스트리를 표시하려고 시도하기 때문에 발생합니다(기본 사이트에는 원래 프로젝트만 존재하며, 복제된 프로젝트는 없으므로 추적 데이터베이스도 존재하지 않습니다).

보조 사이트에서 400 오류 “요청 헤더 또는 쿠키가 너무 큽니다” 반환

이 오류는 기본 사이트의 내부 URL이 올바르지 않을 때 발생할 수 있습니다.

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

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

  • 기본 사이트에 고유한 URL.
  • 모든 보조 사이트에서 접근 가능해야 함.

  1. 기본 사이트에 방문합니다.

  2. 내부 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 버전에서 버그가 발생했기 때문입니다. 이 문제는 수정된 버전으로 업그레이드해야 합니다.

이 버그는 no_proxy 환경 변수 목록에서 마지막에 있는 것을 제외한 모든 와일드카드 도메인(.example.com)이 무시되는 문제를 일으킵니다. 따라서 어떤 이유로든 더 새로운 버전으로 업그레이드할 수 없다면, 와일드카드 도메인을 목록의 끝으로 이동하여 이 문제를 우회할 수 있습니다:

  1. /etc/gitlab/gitlab.rb 파일을 수정합니다:

    gitaly['env'] = {
  "no_proxy" => "sever.yourdomain.org, .yourdomain.com",
}

  2. GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

no_proxy 목록에는 와일드카드 도메인을 하나만 포함할 수 있습니다.

Geo 관리 영역이 보조 사이트에 대해 404 오류를 반환합니다

가끔 sudo gitlab-rake gitlab:geo:check가 보조 사이트의 Rails 노드가 건강하다고 나타내지만, 웹 인터페이스의 주요 사이트의 Geo 관리 영역에서 보조 사이트에 대한 404 Not Found 오류 메시지가 반환됩니다.

이 문제를 해결하려면:

  • sudo gitlab-ctl restart를 사용하여 각 Rails, Sidekiq 및 Gitaly 노드를 보조 사이트에서 재시작해 보세요.
  • Sidekiq 노드에서 /var/log/gitlab/gitlab-rails/geo.log를 확인하여 보조 사이트가 상태를 주요 사이트에 전송하기 위해 IPv6을 사용하고 있는지 확인하세요. 만약 그렇다면, /etc/hosts 파일에서 IPv4를 사용하여 주요 사이트에 항목을 추가하세요. 또는 주요 사이트에서 IPv6을 활성화하세요.