Geo 프록시

GitLab Geo의 보조 사이트가 Workhorse를 통해 HTTP 요청을 기본 사이트로 프록시하는 방식과 Git 요청 흐름을 설명합니다.

보조 사이트는 거의 모든 HTTP 요청을 Workhorse를 통해 기본 사이트로 프록시하므로, 보조 사이트에 접속한 사용자에게는 읽기-쓰기 UI가 표시되며 기본 사이트에서 수행할 수 있는 모든 작업을 수행할 수 있습니다. 고수준 구성 요소 # GitLab UI 및 API HTTP 요청의 프록시 처리는 gitlab-workhorse 구성 요소가 담당합니다. Geo 보조 사이트의 Rails 애플리케이션으로 전송되는 트래픽은 기본 Geo 사이트의 내부 URL 로 프록시됩니다. HTTP를 통한 Git 요청의 프록시 처리는 gitlab-workhorse 구성 요소가 담당하지만, 프록시 여부에 대한 결정은 Rails 애플리케이션이 처리합니다. Rails는 요청이 push인지 pull인지, 그리고 원하는 Git 데이터가 최신 상태인지를 고려하여 결정합니다. SSH를 통한 Git 트래픽의 프록시 처리는 gitlab-shell 구성 요소가 담당하지만, 프록시 여부에 대한 결정은 Rails 애플리케이션이 처리합니다. Rails는 요청이 push인지 pull인지, 그리고 원하는 Git 데이터가 최신 상태인지를 고려하여 결정합니다. 요청 라이프사이클 # 최상위 수준 개요 # 프록시 상호 작용은 다음 다이어그램을 통해 높은 수준에서 설명할 수 있습니다: sequenceDiagram actor client participant secondary participant primary client->>secondary: GET /explore secondary-->>primary: GET /explore (proxied) primary-->>secondary: HTTP/1.1 200 OK [..] secondary->>client: HTTP/1.1 200 OK [..] 프록시 감지 메커니즘 # Geo가 활성화된 경우, Workhorse는 기본 사이트로 요청을 프록시해야 하는지 여부와 기본 사이트의 URL(데이터베이스에 저장됨)을 알기 위해 내부 API를 주기적으로 폴링합니다. 프록시가 활성화되어야 하는 경우, 내부 API는 기본 사이트 URL과 JWT 서명된 데이터를 응답합니다. 이 데이터는 모든 요청에서 기본 사이트로 전달됩니다. sequenceDiagram participant W as Workhorse (secondary) participant API as Internal Rails API W->API: GET /api/v4/geo/proxy (internal) loop Poll every 10 seconds API-->W: {geo_proxy_primary_url, geo_proxy_extra_data}, update config end 심층 요청 흐름 및 프록시와 로컬 데이터 가속 비교 # 구현을 자세히 살펴보면, 보조(요청) 사이트의 Workhorse가 데이터를 프록시할지 여부를 결정합니다. 데이터 유형을 "가속"할 수 있는 경우(즉, 왕복 요청을 절약하기 위해 로컬에서 제공할 수 있는 경우) 데이터를 즉시 반환합니다. 그렇지 않으면 트래픽은 기본 사이트의