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

2차 사이트를 위한 Geo 프록시

Tier: Premium, Ultimate Offering: Self-managed

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

2차 사이트는 전체 읽기-쓰기 GitLab 인스턴스로 동작합니다. 이들은 모든 작업을 원래 사이트에 투명하게 프록시하며, 몇 가지 주목할 만한 예외가 있습니다.

이 동작은 다음과 같은 사용 사례를 가능하게 합니다:

모든 Geo 사이트를 단일 URL 뒤에 두어 사용자가 어느 사이트에 들어가든 일관되고 매끄러운 포괄적인 경험을 제공합니다. 사용자는 여러 GitLab URL을 관리할 필요가 없습니다.
쓰기 권한에 대한 걱정 없이 트래픽을 지리적으로 부하 분산합니다.

개요를 보려면: 지리적 로드 밸런서와 AWS Route53을 사용한 2차 프록시를 참조하세요.

Geo 사이트에 대한 통합 URL 설정

2차 사이트는 읽기-쓰기 트래픽을 투명하게 제공할 수 있습니다. 따라서,

단일 외부 URL을 사용하여 요청이 기본 Geo 사이트 또는 모든 2차 Geo 사이트에 도달할 수 있습니다.

이것은 사용자가 어느 사이트에 도착하든 일관되고 매끄러운 포괄적인 경험을 제공합니다.

사용자는 여러 URL을 관리할 필요가 없으며, 여러 사이트의 개념을 인식할 필요도 없습니다.

Geo 사이트로 트래픽을 라우팅할 수 있습니다:

지리적 위치 인식 DNS. 가장 가까운 Geo 사이트로 트래픽을 라우팅합니다. 기본 또는 2차 사이트에 관계없이. 예시는 위치 인식 DNS 구성을 따르세요.
라운드로빈 DNS.
로드 밸런서. 인증 실패 및 교차 사이트 요청 오류를 방지하기 위해 세션을 유지해야 합니다. DNS 라우팅은 본질적으로 고정되어 있기 때문에 이 문제를 공유하지 않습니다.

위치 인식 DNS 구성

이 예시를 따르십시오. 가장 가까운 Geo 사이트에 트래픽을 라우팅합니다. 기본 사이트 또는 2차 사이트에 관계없이.

전제 조건

이 예시는 요청을 자동으로 리디렉션하는 gitlab.example.com 하위 도메인을 생성합니다:

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

이 예시에 필요합니다:

작동하는 Geo 기본 사이트 및 2차 사이트. Geo 설정 지침을 참조하세요.
귀하의 도메인을 관리하는 DNS 영역. 다음 지침에서는 AWS Route53 및 GCP 클라우드 DNS를 사용하지만, Cloudflare와 같은 다른 서비스도 사용할 수 있습니다.

AWS Route53

이 예시에서는 Route53 설정을 위해 도메인을 관리하는 Route53 호스팅 영역을 사용합니다.

Route53 호스팅 영역에서 트래픽 정책을 사용하여 다양한 라우팅 구성을 설정할 수 있습니다. 트래픽 정책을 생성하려면:

Route53 대시보드로 이동하여 트래픽 정책을 선택합니다.
트래픽 정책 생성을 선택합니다.
정책 이름 필드에 Single Git Host를 입력하고 다음을 선택합니다.
DNS 유형을 A: IPv4 형식의 IP 주소로 둡니다.
연결 방법을 선택한 후 지리적 위치 규칙을 선택합니다.
첫 번째 위치에 대해:
1. 기본값으로 둡니다.
2. 연결 방법을 선택한 후 새 엔드포인트를 선택합니다.
3. 유형을 값으로 선택하고 <your **primary** IP address>를 입력합니다.
두 번째 위치에 대해:
1. 유럽을 선택합니다.
2. 연결 방법을 선택한 후 새 엔드포인트를 선택합니다.
3. 유형을 값으로 선택하고 <your **secondary** IP address>를 입력합니다.
트래픽 정책 생성을 선택합니다.
정책 레코드 DNS 이름에 gitlab을 입력합니다.
정책 레코드 생성을 선택합니다.

이로써, gitlab.example.com과 같은 단일 호스트를 성공적으로 설정하였습니다. 이는 지리적 위치에 따라 귀하의 Geo 사이트로 트래픽을 분배합니다.

GCP

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

Geo-Based 레코드 세트를 생성할 때, GCP는 트래픽 출처가 정책 항목과 정확하게 일치하지 않을 경우 가장 가까운 출처 지역을 적용합니다. Geo-Based 레코드 세트를 생성하려면:

Network Services > Cloud DNS를 선택합니다.
도메인에 대해 구성된 영역을 선택합니다.
Add Record Set을 선택합니다.
위치 기반 공용 URL의 DNS 이름을 입력합니다. 예: gitlab.example.com.
Routing Policy를 선택합니다: Geo-Based.
Add Managed RRData를 선택합니다.
1. Source Region을 선택합니다: us-central1.
2. <**primary** IP address>를 입력합니다.
3. Done을 선택합니다.
Add Managed RRData를 선택합니다.
1. Source Region을 선택합니다: europe-west1.
2. <**secondary** IP address>를 입력합니다.
3. Done을 선택합니다.
Create를 선택합니다.

이제 gitlab.example.com과 같은 단일 호스트를 성공적으로 설정하였으며, 위치 기반 URL을 사용하여 Geo 사이트로 트래픽을 분배합니다.

각 사이트를 동일한 외부 URL로 구성

단일 URL에서 모든 Geo 사이트로 라우팅을 설정한 후, 사이트가 서로 다른 URL을 사용하는 경우 다음 단계를 따릅니다:

각 GitLab 사이트에서 Rails (Puma, Sidekiq, Log-Cursor)가 실행되는 각 노드에 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 아래 동일한 도메인을 사용할 수 있습니다.

보조 Geo 사이트를 위한 별도의 URL 설정

사이트마다 서로 다른 외부 URL을 사용할 수 있습니다. 이를 통해 특정 사용자 집합에 특정 사이트를 제공할 수 있습니다. 또는 사용자가 사용하는 사이트를 관리하도록 할 수 있지만, 선택의 의미를 이해해야 합니다.

참고: GitLab은 여러 개의 외부 URL을 지원하지 않습니다. 이슈 21319를 참조하세요. 고유한 문제는 사이트가 HTTP 요청의 맥락을 벗어난 절대 URL을 생성해야 하는 많은 경우가 있다는 것입니다. 예를 들어, 요청이 아닌 트리거로 발송되는 이메일과 같이 말입니다.

보조 Geo 사이트를 주 사이트와 다른 외부 URL로 구성

보조 사이트가 주 사이트와 동일한 외부 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 트래픽은 기본 사이트와 동일한 오류를 반환하거나, 기본에 전혀 접근할 수 없는 경우 실패합니다. 이는 프록시되기 때문입니다.
특정 보조 사이트에서 완전히 최신 상태인 리포지토리에 대해 Git 읽기 작업은 여전히 예상대로 작동하며, HTTP(s) 또는 SSH를 통한 인증이 포함됩니다. 그러나 GitLab 러너에 의해 수행된 Git 읽기는 실패합니다.
보조 사이트에 복제되지 않은 리포지토리에 대한 Git 작업은 기본 사이트와 동일한 오류를 반환합니다. 이는 프록시되기 때문입니다.
모든 Git 쓰기 작업은 기본 사이트와 동일한 오류를 반환합니다. 이는 프록시되기 때문입니다.

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

보조 Geo 사이트로 전송되는 대부분의 HTTP 트래픽은 기본 Geo 사이트로 프록시됩니다. 이 아키텍처를 통해 보조 Geo 사이트는 쓰기 요청을 지원하고, 쓰기 후 읽기(read-after-write) 문제를 피할 수 있습니다. 특정 읽기 요청은 근처의 대기 시간 및 대역폭 개선을 위해 보조 사이트에서 로컬로 처리됩니다.

다음 표는 Geo 보조 사이트 Workhorse 프록시를 통해 테스트된 구성 요소에 대한 세부정보를 제공합니다. 모든 데이터 유형을 포함하지는 않습니다.

이 맥락에서, 가속된 읽기는 보조 사이트에서 제공되는 읽기 요청을 의미하며, 보조 사이트의 구성 요소에 대한 데이터가 최신 상태일 때만 유효합니다. 보조 사이트의 데이터가 최신이 아닌 것으로 판단될 경우 요청은 기본 사이트로 전달됩니다. 아래 표에 나열되지 않은 구성 요소에 대한 읽기 요청은 항상 자동으로 기본 사이트로 전달됩니다.

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

기능 가속 요청을 하려면, 에픽 8239에서 이미 존재하는 이슈인지 확인하고, 관심을 표시하기 위해 업보팅하거나 댓글을 남기거나 귀하를 대신하여 GitLab 담당자에게 요청하십시오. 해당 이슈가 존재하지 않으면 하나를 열고 이를 에픽에 언급하십시오.

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

이 섹션에서 설명하는 기능 플래그는 향후 릴리스에서 사용 중단될 예정이며 제거될 것입니다. 읽기 전용 Geo 보조 사이트에 대한 지원은 이슈 366810에서 제안되었으며, 해당 이슈에서 찬성 투표를 하거나 사용 사례를 공유할 수 있습니다.

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

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

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

Kubernetes에서는 툴박스 팟에서 동일한 명령을 실행할 수 있습니다. 자세한 내용은
Kubernetes 치트 시트를 참조하세요.

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

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

Linux 패키지 (Omnibus)

보조 Geo 사이트에서 사용자 트래픽을 직접 제공하는 각 애플리케이션 노드에 SSH로 접속한 후 다음 환경 변수를 추가합니다:
```
sudo -e /etc/gitlab/gitlab.rb
```
```
gitlab_workhorse['env'] = {
  "GEO_SECONDARY_PROXY" => "0"
}
```
변경 사항이 적용되도록 업데이트된 노드를 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

Helm 차트 (Kubernetes)

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

gitlab:
  webservice:
    extraEnv:
      GEO_SECONDARY_PROXY: "0"

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

다음의 포워딩을 비활성화하는 것은 불가능합니다:

SSH를 통한 Git 푸시
보조 사이트에서 Git 리포지토리가 구식인 경우 SSH를 통한 Git 풀
HTTP를 통한 Git 푸시
보조 사이트에서 Git 리포지토리가 구식인 경우 HTTP를 통한 Git 풀

2차 사이트를 위한 Geo 프록시

Geo 사이트에 대한 통합 URL 설정

위치 인식 DNS 구성

전제 조건

AWS Route53

GCP

각 사이트를 동일한 외부 URL로 구성

보조 Geo 사이트를 위한 별도의 URL 설정

보조 Geo 사이트를 주 사이트와 다른 외부 URL로 구성

알려진 문제

기본 Geo 사이트가 다운될 때 보조 사이트의 동작

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

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

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

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

도움말

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

도움받기