보조 사이트의 Geo 프록싱

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

히스토리 별도 URL이 있는 보조 사이트의 HTTP 프록싱이 geo_secondary_proxy_separate_urls 라는 플래그 로 GitLab 14.5에서 도입 . 기본적으로 비활성화. 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 설정 # 보조 사이트는 읽기-쓰기 트래픽을 투명하게 처리할 수 있습니다. 따라서 요청이 기본 Geo 사이트나 보조 Geo 사이트 중 어디로든 연결될 수 있는 단일 외부 URL을 사용할 수 있습니다. 이렇게 하면 사용자가 어떤 사이트에 접속하든 일관되고, 원활하며, 포괄적인 경험을 제공합니다. 사용자는 여러 URL을 다루거나 여러 사이트의 개념을 인식할 필요가 없습니다. 다음을 사용하여 Geo 사이트로 트래픽을 라우팅할 수 있습니다: 지리적 위치 인식 DNS. 기본 또는 보조에 관계없이 가장 가까운 Geo 사이트로 트래픽을 라우팅합니다. 예시를 따르려면 지리적 위치 인식 DNS 구성 을 참조하세요. 라운드 로빈 DNS. 로드 밸런서. 인증 실패 및 크로스 사이트 요청 오류를 방지하려면 스티키 세션을 사용해야 합니다. DNS 라우팅은 본질적으로 스티키하므로 이러한 주의 사항이 없습니다. 지리적 위치 인식 DNS 구성 # 이 예시를 따라 기본 또는 보조에 관계없이 가장 가까운 Geo 사이트로 트래픽을 라우팅합니다. 사전 요구사항 # 이 예시에서는 자동으로 요청을 연결하는 gitlab.example.com 서브도메인을 생성합니다: 유럽에서의 요청을 보조 사이트로. 다른 모든 위치에서의 요청을 기본 사이트로. 이 예시를 위해 다음이 필요합니다: 작동하는 Geo 기본 사이트와 보조 사이트. Geo 설정 지침 을 참조하세요. 도메인을 관리하는 DNS 영역. 다음 지침은 AWS Route53 과 GCP 클라우드 DNS 를 사용하지만 Cloudflare 와 같은 다른 서비스도 사용할 수 있습니다. AWS Rout