보조 사이트의 Geo 프록싱

보조 사이트의 Geo 프록싱에 대해 설명합니다.

히스토리 별도 URL을 사용하는 보조 사이트의 HTTP 프록시가 GitLab 14.5에서 geo_secondary_proxy_separate_urls 라는 기능 플래그 와 함께 도입되었습니다 . 기본적으로 비활성화되어 있습니다. GitLab 15.1에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 활성화되었습니다 . Feature flag 이 기능의 제공 여부는 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다. geo_secondary_proxy_separate_urls 기능 플래그는 향후 릴리스에서 더 이상 사용되지 않고 제거될 예정입니다. 읽기 전용 Geo 보조 사이트 지원은 이슈 366810 에서 제안되었습니다. 보조 사이트는 읽기·쓰기가 모두 가능한 완전한 GitLab 인스턴스로 동작합니다. 몇 가지 주요 예외 를 제외한 모든 작업을 기본 사이트로 투명하게 프록시합니다. 이 동작으로 다음과 같은 사용 사례를 구현할 수 있습니다. 모든 Geo 사이트를 단일 URL 뒤에 두어, 사용자가 어느 사이트에 접속하든 일관되고 끊김 없는 전체 기능의 경험을 제공합니다. 사용자는 여러 GitLab URL을 번갈아 쓸 필요가 없습니다. 쓰기 액세스를 걱정하지 않고 트래픽을 지리적으로 분산합니다. 개요는 보조 사이트를 위한 Geo 프록시 를 참고합니다. 알려진 문제는 Geo 문서의 프록시 관련 항목 을 참고합니다. Geo 사이트용 통합 URL 설정 # 보조 사이트는 읽기·쓰기 트래픽을 투명하게 처리할 수 있습니다. 따라서 단일 외부 URL을 사용해 요청이 기본 Geo 사이트나 보조 Geo 사이트 어느 쪽으로든 도달하게 할 수 있습니다. 이렇게 하면 사용자가 어느 사이트에 접속하든 일관되고 끊김 없는 전체 기능의 경험을 제공합니다. 사용자는 여러 URL을 번갈아 쓸 필요도, 사이트가 여러 개라는 사실을 알 필요도 없습니다. Geo 사이트로 트래픽을 라우팅하는 방법은 다음과 같습니다. Geo 위치 인식 DNS. 기본 사이트든 보조 사이트든 가장 가까운 Geo 사이트로 트래픽을 라우팅합니다. 예시는 위치 인식 DNS 구성 을 참고합니다. 라운드 로빈 DNS. 로드 밸런서. 인증 실패와 교차 사이트 요청 오류를 막으려면 고정 세션을 사용해야 합니다. DNS 라우팅은 본래 고정적이므로 이 제약이 없습니다. 위치 인식 DNS 구성 # 기본 사이트든 보조 사이트든 가장 가까운 Geo 사이트로 트래픽을 라우팅하려면 다음 예시를 따릅니다. 사전 요구 사항 # 이 예시에서는 요청을 다음과 같이 자동으로 전달하는 gitlab.example.com 서브도메인을 만듭니다. 유럽에서 온 요청은 보조 사이트로 전달합니다. 그 외 지역에서 온 요청은 기본 사이트로 전달합니다. 이 예시에는 다음이 필요합니다. 동작 중인 Geo 기본 사이트와 보조 사이트. Geo 설정 안내 를 참고합니다. 도메인을 관리하는 DNS 영역. 다음 안내는 AWS Route53 과 GCP cloud DNS 를 사용하지만 Cloudflare