Geo 사이트를 위한 통합 URL 설정
- 위치인식 DNS 구성
  - AWS Route53
  - GCP
- 각 사이트를 동일한 외부 URL을 사용하도록 설정
별도의 URL을 이용하여 보조 Geo 사이트 설정하기
- 기본 사이트와 다른 외부 URL에 대한 별도의 Geo 사이트 구성
알려진 문제
기본 Geo 사이트가 다운된 경우의 보조 사이트 동작
보조 Geo 사이트에 의해 가속화된 기능
보조 사이트 HTTP 프록시 비활성화
- 사이트별 보조 사이트 HTTP 프록시 비활성화
- 보조 사이트 Git 프록시 비활성화

이차 사이트를 위한 지역 프록시

Tier: 프리미엄, 얼티메이트 Offering: Self-managed

별도의 URL로 이루어진 이차 사이트에 대한 HTTP 프록시는 기본적으로 기본적으로 활성화되어 있습니다 GitLab 15.1.

이차 사이트는 완전한 읽기-쓰기 GitLab 인스턴스로 작동합니다. 이들은 모든 작업을 기본 사이트로 투명하게 프록시하며, 일부 주목할만한 예외 사항이 있습니다.

이 동작으로 다음과 같은 사용 사례를 가능케 합니다:

모든 Geo 사이트를 단일 URL 뒤에 배치하여 사용자가 랜딩하는 사이트에 관계없이 일관되고 통합적인 경험을 제공합니다. 사용자는 여러 개의 GitLab URL을 번갈아 가며 사용할 필요가 없습니다.
쓰기 액세스에 대해 걱정할 필요 없이 지리적으로 로드 밸런싱된 트래픽을 처리합니다.

개요를 보려면: 지리적 로드 밸런서와 AWS Route53를 사용한 이차 프록시 설정.

Geo 사이트를 위한 통합 URL 설정

이차 사이트는 읽기-쓰기 트래픽을 투명하게 제공할 수 있습니다. 따라서 단일 외부 URL을 사용하여 요청이 기본 Geo 사이트 또는 이차 Geo 사이트 중 어느 쪽으로 이루어질지에 상관없이 일관되고 통합적인 경험을 제공할 수 있습니다. 사용자는 여러 개의 URL을 혼용할 필요가 없으며 여러 사이트의 개념조차 인식할 필요가 없습니다.

다음과 같은 방법으로 Geo 사이트로 트래픽을 라우팅할 수 있습니다:

지리 위치인식 DNS. 트래픽을 최근접 Geo 사이트(기본 또는 이차)로 라우팅합니다. 예제는 위치인식 DNS 구성을 참고하세요.
Round-robin DNS.
로드 밸런서. 인증 실패 및 사이트 간 요청 오류를 피하기 위해 sticky session을 사용해야 합니다. DNS 라우팅은 본질적으로 sticky하므로 이러한 주의사항을 공유하지 않습니다.

위치인식 DNS 구성

이 예제를 따라하면 모든 다음과 같은 경우에 요청을 자동으로 전달하는 gitlab.example.com 하위도메인을 생성합니다:

유럽에서는 이차 사이트로부터.
다른 모든 위치에서는 기본 사이트로부터.

이 예제를 위해서는 다음이 필요합니다:

작동 중인 Geo 기본 사이트 및 이차 사이트. 해당 지침은 Geo 설정 지침을 참조하세요.
도메인을 관리하는 DNS 영역. 다음 지침은 AWS Route53 및 GCP cloud DNS을 사용하지만 Cloudflare와 같은 다른 서비스도 사용할 수 있습니다.

AWS Route53

이 예제에서는 Route53 Hosted Zone을 사용하여 도메인을 관리하고 Route53 설정을 합니다.

Route53 Hosted Zone에서는 트래픽 정책을 사용하여 다양한 라우팅 구성을 설정할 수 있습니다. 다음 단계를 따라 traffic policy를 생성하세요:

Route53 dashboard로 이동하고 Traffic policies를 선택하세요.
Traffic policy 생성을 선택하세요.
Policy Name 필드에 Single Git Host를 입력하고 다음을 선택하세요.
DNS type를 A: IP Address in IPv4 format로 남겨두세요.
Connect to을 선택한 다음 Geolocation rule를 선택하세요.
첫 번째 Location에 대해:
1. Default로 남겨두세요.
2. Connect to을 선택한 다음 New endpoint를 선택하세요.
3. Type을 value로 선택하고 <귀하의 **기본** IP 주소>로 입력하세요.
두 번째 Location에 대해:
1. Europe를 선택하세요.
2. Connect to을 선택한 다음 New endpoint를 선택하세요.
3. Type을 value로 선택하고 <귀하의 **이차** IP 주소>로 입력하세요.
Traffic policy 생성을 선택하세요.
Policy record DNS name에 gitlab을 입력하세요.
Policy records 생성을 선택하세요.

귀하의 Geo 사이트로 트래픽을 지리적으로 라우팅하는 gitlab.example.com과 같은 단일 호스트를 성공적으로 설정했습니다.

GCP

이 예제에서는 도메인을 관리하는 GCP Cloud DNS zone을 생성합니다.

Geo-Based 레코드 세트를 생성할 때, GCP는 트래픽의 원본이 정확히 일치하지 않을 때 소스 지역의 가장 가까운 일치를 적용합니다. 다음 단계를 따라 Geo-Based 레코드 세트를 생성하세요:

네트워크 서비스 > Cloud DNS를 선택하세요.
도메인 구성에 대한 Zone을 선택하세요.
Record Set 추가를 선택하세요.
위치인식 가능한 공개 URL을 위한 DNS Name을 입력하세요. 예를 들어 gitlab.example.com.
루팅 정책: Geo-Based를 선택하세요.
Managed RRData 추가를 선택하세요.
1. 소스 지역: us-central1을 선택하세요.
2. 귀하의 <**기본** IP 주소>을 입력하세요.
3. 완료를 선택하세요.
Managed RRData 추가를 선택하세요.
1. 소스 지역: europe-west1을 선택하세요.
2. 귀하의 <**이차** IP 주소>을 입력하세요.
3. 완료를 선택하세요.
생성을 선택하세요.

귀하의 Geo 사이트로 트래픽을 위치인식 URL을 사용하여 분배하는 gitlab.example.com과 같은 단일 호스트를 성공적으로 설정했습니다.

각 사이트를 동일한 외부 URL을 사용하도록 설정

Geo 사이트가 모두 동일한 URL로부터 라우팅되도록 설정한 후, 사이트가 서로 다른 URL을 사용하는 경우 다음 단계를 따르세요:

각 GitLab 사이트에서, Rails(푸마, 사이드킥, 로그-커서)를 실행 중인 각 노드로 SSH하고 external_url을 해당 단일 URL로 설정합니다:
```
sudo -e /etc/gitlab/gitlab.rb
```
변경된 노드를 다시 구성하여 변경 사항이 적용되도록 합니다:
```
sudo gitlab-ctl reconfigure
```
이차 Geo 사이트에 설정된 새로운 외부 URL과 일치하도록, 기본 데이터베이스도 이 변경을 반영해야 합니다.
기본 사이트의 Geo 관리 페이지에서, 각 이차 프록시 사용 중인 Geo 이차 사이트를 편집하고 URL 필드를 해당 단일 URL로 설정하세요. 주의하세요. 주 기본 사이트도 이 URL을 사용하고 있는지 확인하세요.
사이트들이 서로 통신할 수 있도록 하려면, 각 사이트에 대해 Internal URL 필드가 고유한지 확인하세요.

Kubernetes에서는 기본 사이트와 동일한 도메인을 global.hosts.domain에 사용할 수 있습니다.

별도의 URL을 이용하여 보조 Geo 사이트 설정하기

사이트마다 다른 외부 URL을 사용할 수 있습니다. 이를 사용하여 특정 사용자 세트에게 특정 사이트를 제공할 수 있습니다. 또는 사용자가 선택한 사이트를 제어할 수 있지만, 그들의 선택이 의미하는 바를 이해해야 합니다.

참고: GitLab은 여러 외부 URL을 지원하지 않습니다. issue 21319를 참조하십시오. 사이트가 HTTP 요청의 문맥이 아닌 절대 URL을 생성해야 하는 경우가 많아 내재적인 문제가 있습니다. 예를 들어, 요청으로 유도되지 않은 이메일을 보낼 때입니다.

기본 사이트와 다른 외부 URL에 대한 별도의 Geo 사이트 구성

만약 보조 사이트가 기본 사이트와 같은 외부 URL을 사용하는 경우:

보조 사이트에서 Rails(Puma, Sidekiq, Log-Cursor)를 실행 중인 각 노드에 SSH로 접속하여 external_url을 원하는 보조 사이트의 URL로 설정합니다:
```
sudo -e /etc/gitlab/gitlab.rb
```
변경 사항이 적용되도록 업데이트된 노드를 재구성합니다:
```
sudo gitlab-ctl reconfigure
```
보조 Geo 사이트에 설정된 새로운 외부 URL과 일치하도록 기본 데이터베이스를 반영해야 합니다.
기본 사이트의 Geo 관리 페이지에서 대상 보조 사이트를 편집하고 URL 필드를 원하는 URL로 설정합니다.
사이트 간 통신을 허용하려면 각 사이트의 Internal URL 필드가 고유한지 확인하십시오. 원하는 URL이 이 사이트에 고유하다면 Internal URL 필드를 비울 수 있습니다. 저장하면 외부 URL로 기본값이 설정됩니다.

알려진 문제

Geo 제한 사항의 통합된 목록에서 프록시 관련 항목을 참조하십시오.

기본 Geo 사이트가 다운된 경우의 보조 사이트 동작

기본 사이트로의 웹 트래픽이 프록시로 전달되므로, 기본 사이트에 접근할 수 없는 경우 보조 사이트의 동작은 다음과 같이 다릅니다:

UI 및 API 트래픽은 프록시로 전달되므로 기본 사이트와 동일한 오류를 반환합니다(또는 기본 사이트에 접근할 수 없는 경우 실패합니다).
특정 보조 사이트에서 완전히 업데이트된 리포지토리의 경우, HTTP(s) 또는 SSH를 통한 인증을 포함하여 Git 읽기 작업은 여전히 예상대로 작동합니다. 그러나 GitLab 러너에 의해 실행되는 Git 읽기 작업은 실패합니다.
보조 사이트로 복제되지 않은 리포지토리의 Git 작업은 프록시로 전달되므로 기본 사이트와 동일한 오류를 반환합니다.
모든 Git 쓰기 작업은 프록시로 전달되므로 기본 사이트와 동일한 오류를 반환합니다.

보조 Geo 사이트에 의해 가속화된 기능

보조 Geo 사이트로 전송된 대부분의 HTTP 트래픽이 기본 Geo 사이트로 프록시됩니다. 이 아키텍처를 통해 보조 Geo 사이트는 쓰기 요청을 지원하고, 쓰기 후 읽기 문제를 피할 수 있습니다. 일부 읽기 요청은 가까운 곳에서 지연 시간과 대역폭을 개선하기 위해 보조 사이트에서 로컬로 처리됩니다.

다음 표는 Geo 보조 사이트 워크호스 프록시를 통해 테스트된 구성 요소에 대한 자세한 내용을 보여줍니다. 모든 데이터 유형을 다루지는 않습니다.

이 문맥에서 가속화된 읽기는 보조 사이트에서 제공되는 읽기 요청을 나타내며, 해당 구성 요소에 대한 데이터가 보조 사이트에서 최신 상태인 경우입니다. 보조 사이트의 데이터가 오래된 것으로 판명되는 경우 요청은 기본 사이트로 전달됩니다. 아래 표에 나열되지 않은 구성 요소에 대한 읽기 요청은 항상 자동으로 기본 사이트로 전달됩니다.

기능 / 구성 요소	가속화된 읽기여부?	비고
프로젝트, 위키, 디자인 리포지토리(웹 UI 사용)	No
프로젝트, 위키 리포지토리(Git 사용)	Yes	Git 읽기는 보조 사이트에서 로컬로 제공되며, 푸시는 기본 사이트로 프록시됩니다. 선택적 동기화 또는 보조 Geo에서 리포지토리가 존재하지 않는 경우 “찾을 수 없음” 오류가 발생합니다.
프로젝트, 개인 스니펫(웹 UI 사용)	No
프로젝트, 개인 스니펫(Git 사용)	Yes	Git 읽기는 보조 사이트에서 로컬로 제공되며, 푸시는 기본 사이트로 프록시됩니다. 선택적 동기화 또는 보조 Geo에서 리포지토리가 존재하지 않는 경우 “찾을 수 없음” 오류가 발생합니다.
그룹 위키 리포지토리(웹 UI 사용)	No
그룹 위키 리포지토리(Git 사용)	Yes	Git 읽기는 보조 사이트에서 로컬로 제공되며, 푸시는 기본 사이트로 프록시됩니다. 선택적 동기화 또는 보조 Geo에서 리포지토리가 존재하지 않는 경우 “찾을 수 없음” 오류가 발생합니다.
사용자 업로드	No
LFS 객체(웹 UI 사용)	No
LFS 객체(Git 사용)	Yes
페이지	No	페이지는 동일한 URL을 사용할 수 있지만(접근 제어 없음), 별도로 구성되어 있으며 프록시되지 않습니다.
고급 검색(웹 UI 사용)	No
컨테이너 레지스트리	No	컨테이너 레지스트리는 재해 복구 시나리오에만 권장됩니다. 보조 사이트의 컨테이너 레지스트리가 최신 상태가 아니면, 읽기 요청은 기본 사이트로부터 오래된 데이터로 제공됩니다. 컨테이너 레지스트리의 가속화는 계획 중이며, 관심이 있는 경우 issue에서 투표하거나 의견을 남기거나 GitLab 대표에게 요청할 수 있습니다.
의존성 프록시	No	보조 Geo 사이트의 의존성 프록시로의 읽기 요청은 항상 기본 사이트로 프록시됩니다.
기타 모든 데이터	No	이 표에 나열되지 않은 모든 구성 요소에 대한 읽기 요청은 항상 자동으로 기본 사이트로 전달됩니다.

보조 사이트 HTTP 프록시 비활성화

참고: 이 섹션에서 설명하는 기능 플래그는 향후 릴리스에서 폐기되고 제거될 예정입니다. 읽기 전용 Geo 보조 사이트의 지원은 이슈 366810에서 제안되었습니다. 해당 이슈에서 투표하고 사용 사례를 공유할 수 있습니다.

보조 사이트 HTTP 프록시는 기본적으로 통일된 URL을 사용하는 경우에 기본적으로 활성화됩니다. 즉, 기본 사이트와 동일한 external_url로 구성됩니다. 이 경우에 프록시를 비활성화하는 것은 경로에 따라 동일한 URL에서 완전히 다른 동작이 제공되기 때문에 도움이 되지 않을 수 있습니다.

GitLab 15.1에서도 보조 사이트에서 통일된 URL이 없어도 HTTP 프록시가 기본으로 활성화됩니다. 모든 보조 사이트에서 프록시를 비활성화해아한다면 기능 플래그를 비활성화하는 것이 가장 쉽습니다.

기본 Geo 사이트에서 Puma 또는 Sidekiq를 실행 중인 노드에 SSH로 로그인하고 다음을 실행합니다:
```
sudo gitlab-rails runner "Feature.disable(:geo_secondary_proxy_separate_urls)"
```
보조 Geo 사이트의 모든 노드에서 Puma를 다시 시작합니다:
```
sudo gitlab-ctl restart puma
```

Kubernetes에서는 도구 상자 파드에서 동일한 명령을 실행할 수 있습니다. 자세한 내용은 Kubernetes cheat sheet를 참조하세요.

사이트별 보조 사이트 HTTP 프록시 비활성화

여러 보조 사이트가 있는 경우, 다음 단계를 따라 각 보조 사이트에서 HTTP 프록시를 별도로 비활성화할 수 있습니다:

Linux package (Omnibus)

각 보조 Geo 사이트의 응용 프로그램 노드(직접 사용자 트래픽을 제공)에 SSH로 로그인하고 다음 환경 변수를 추가합니다:
```
sudo -e /etc/gitlab/gitlab.rb
```
```
gitlab_workhorse['env'] = {
  "GEO_SECONDARY_PROXY" => "0"
}
```
변경 사항이 적용되도록 업데이트된 노드를 다시 구성합니다:
```
sudo gitlab-ctl reconfigure
```

Helm chart (Kubernetes)

--set gitlab.webservice.extraEnv.GEO_SECONDARY_PROXY="0"을 사용할 수 있으며, 또는 값 파일에서 다음을 지정할 수 있습니다:

gitlab:
  webservice:
    extraEnv:
      GEO_SECONDARY_PROXY: "0"

보조 사이트 Git 프록시 비활성화

다음을 전달하는 것을 비활성화할 수 없습니다:

SSH를 통한 Git push
보조 사이트에서 Git 저장소가 오래된 상태일 때 SSH를 통한 Git pull
HTTP를 통한 Git push
보조 사이트에서 Git 저장소가 오래된 상태일 때 HTTP를 통한 Git pull

이차 사이트를 위한 지역 프록시

Geo 사이트를 위한 통합 URL 설정

위치인식 DNS 구성

AWS Route53

GCP

각 사이트를 동일한 외부 URL을 사용하도록 설정

별도의 URL을 이용하여 보조 Geo 사이트 설정하기

기본 사이트와 다른 외부 URL에 대한 별도의 Geo 사이트 구성

알려진 문제

기본 Geo 사이트가 다운된 경우의 보조 사이트 동작

보조 Geo 사이트에 의해 가속화된 기능

보조 사이트 HTTP 프록시 비활성화

사이트별 보조 사이트 HTTP 프록시 비활성화

보조 사이트 Git 프록시 비활성화

도움말

기능 사용 가능성과 제품 평가판

도움받기