보조 사이트는 완전한 읽기-쓰기 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 Route53#

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

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

1. Route53 대시보드로 이동하여 Traffic policies를 선택합니다.

2. Create traffic policy를 선택합니다.

3. Policy Name 필드에 Single Git Host를 입력하고 Next를 선택합니다.

4. DNS type을 A: IP Address in IPv4 format으로 유지합니다.

5. Connect to를 선택한 다음 Geolocation rule을 선택합니다.

6. 첫 번째 Location에서:

   1. Default로 유지합니다.
   2. Connect to를 선택한 다음 New endpoint를 선택합니다.
   3. Type을 value로 선택하고 <기본 IP 주소>를 입력합니다.

7. 두 번째 Location에서:

   1. Europe을 선택합니다.
   2. Connect to를 선택한 다음 New endpoint를 선택합니다.
   3. Type을 value로 선택하고 <보조 IP 주소>를 입력합니다.

   

8. Create traffic policy를 선택합니다.

9. Policy record DNS name에 gitlab을 입력합니다.

   

10. Create policy records를 선택합니다.

gitlab.example.com과 같은 단일 호스트가 성공적으로 설정되어 지리적 위치별로 Geo 사이트로 트래픽을 분산합니다.

GCP#

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

지리적 기반 레코드 세트를 생성할 때 GCP는 트래픽 소스가 정책 항목과 정확히 일치하지 않을 경우 소스 지역에 대해 가장 가까운 매칭을 적용합니다. 지리적 기반 레코드 세트를 생성하려면:

1. Network Services > Cloud DNS를 선택합니다.
2. 도메인에 구성된 영역을 선택합니다.
3. Add Record Set을 선택합니다.
4. 위치 인식 공개 URL의 DNS 이름을 입력합니다. 예: gitlab.example.com.
5. Routing Policy: Geo-Based를 선택합니다.
6. Add Managed RRData를 선택합니다.
   1. Source Region: us-central1을 선택합니다.
   2. <기본 IP 주소>를 입력합니다.
   3. Done을 선택합니다.
7. Add Managed RRData를 선택합니다.
   1. Source Region: europe-west1을 선택합니다.
   2. <보조 IP 주소>를 입력합니다.
   3. Done을 선택합니다.
8. Create를 선택합니다.

gitlab.example.com과 같은 단일 호스트가 성공적으로 설정되어 위치 인식 URL을 사용하여 Geo 사이트로 트래픽을 분산합니다.

동일한 외부 URL을 사용하도록 각 사이트 구성#

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

1. 각 GitLab 사이트에서 Rails(Puma, Sidekiq, Log-Cursor)를 실행하는 각 노드에 SSH로 접속하고 external_url을 단일 URL로 설정합니다:

   sudo -e /etc/gitlab/gitlab.rb
   

2. 변경 사항이 적용되도록 업데이트된 노드를 재구성합니다:

   sudo gitlab-ctl reconfigure
   

3. 보조 Geo 사이트에 설정된 새 외부 URL과 일치시키기 위해 기본 데이터베이스가 이 변경 사항을 반영해야 합니다.

   기본 사이트의 Geo 관리 페이지에서 보조 프록싱을 사용하는 각 Geo 보조 사이트를 편집하고 URL 필드를 단일 URL로 설정합니다. 기본 사이트도 이 URL을 사용하고 있는지 확인합니다.

   사이트들이 서로 통신할 수 있도록 각 사이트의 Internal URL 필드가 고유한지 확인합니다.

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

보조 Geo 사이트에 별도의 URL 설정#

사이트별로 다른 외부 URL을 사용할 수 있습니다. 이를 사용하여 특정 사용자 집합에 특정 사이트를 제공할 수 있습니다. 또는 사용자에게 사용할 사이트를 선택할 수 있는 권한을 줄 수 있지만 선택의 의미를 이해해야 합니다.

기본 사이트와 다른 외부 URL로 보조 Geo 사이트 구성#

보조 사이트가 기본 사이트와 동일한 외부 URL을 사용하지만 다른 URL로 변경하려는 경우:

1. 보조 사이트에서 Rails(Puma, Sidekiq, Log-Cursor)를 실행하는 각 노드에 SSH로 접속하고 external_url을 보조 사이트의 원하는 URL로 설정합니다:

   sudo -e /etc/gitlab/gitlab.rb
   

2. 변경 사항이 적용되도록 업데이트된 노드를 재구성합니다:

   sudo gitlab-ctl reconfigure
   

3. 보조 Geo 사이트에 설정된 새 외부 URL과 일치시키기 위해 기본 데이터베이스가 이 변경 사항을 반영해야 합니다.

   기본 사이트의 Geo 관리 페이지에서 대상 보조 사이트를 편집하고 URL 필드를 원하는 URL로 설정합니다.

   사이트들이 서로 통신할 수 있도록 각 사이트의 Internal URL 필드가 고유한지 확인합니다. 원하는 URL이 이 사이트에 고유한 경우 Internal URL 필드를 지울 수 있습니다. 저장 시 외부 URL이 기본값으로 설정됩니다.

기본 Geo 사이트가 다운되었을 때 보조 사이트의 동작#

웹 트래픽이 기본 사이트로 프록싱되는 점을 고려하면 기본 사이트가 접근 불가능할 때 보조 사이트의 동작은 다음과 같이 달라집니다:

• UI 및 API 트래픽은 기본 사이트와 동일한 오류를 반환합니다(또는 기본 사이트에 전혀 액세스할 수 없는 경우 실패합니다). 이는 프록싱되기 때문입니다.
• 특정 보조 사이트에서 완전히 최신 상태인 리포지토리의 경우 HTTP(s) 또는 SSH를 통한 인증을 포함한 Git 읽기 작업이 여전히 예상대로 작동합니다. 그러나 GitLab Runner가 수행하는 Git 읽기는 실패합니다.
• 보조 사이트로 복제되지 않은 리포지토리의 Git 작업은 프록싱되기 때문에 기본 사이트와 동일한 오류를 반환합니다.
• 모든 Git 쓰기 작업은 프록싱되기 때문에 기본 사이트와 동일한 오류를 반환합니다.

보조 Geo 사이트로 가속되는 기능#

보조 Geo 사이트로 전송된 대부분의 HTTP 트래픽은 기본 Geo 사이트로 프록싱됩니다. 이 아키텍처를 사용하면 보조 Geo 사이트는 쓰기 요청을 지원하고 쓰기 후 읽기 문제를 방지할 수 있습니다. 특정 읽기 요청은 인근 지역의 향상된 지연 시간 및 대역폭을 위해 보조 사이트에서 로컬로 처리됩니다.

다음 표는 Geo 보조 사이트 Workhorse 프록시를 통해 테스트된 구성 요소를 자세히 설명합니다. 모든 데이터 유형을 다루지는 않습니다.

이 컨텍스트에서 가속 읽기는 보조 사이트에서 해당 구성 요소의 데이터가 최신 상태인 경우 보조 사이트에서 처리되는 읽기 요청을 의미합니다. 보조 사이트의 데이터가 최신이 아닌 것으로 확인되면 요청이 기본 사이트로 전달됩니다. 아래 표에 나열되지 않은 구성 요소에 대한 읽기 요청은 항상 자동으로 기본 사이트로 전달됩니다.

기능 가속을 요청하려면 에픽 8239에 이슈가 이미 있는지 확인하고 업보트하거나 댓글을 달아 관심을 표시하거나 GitLab 담당자에게 요청하세요. 해당 이슈가 없으면 이슈를 열고 에픽에 언급합니다.

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

보조 사이트 HTTP 프록싱은 기본 사이트와 동일한 external_url로 구성된, 즉 통합 URL을 사용하는 보조 사이트에서 기본적으로 활성화됩니다. 라우팅에 따라 동일한 URL에서 완전히 다른 동작이 제공되므로 이 경우 프록싱을 비활성화하는 것은 도움이 되지 않습니다. 보조 Geo 사이트에서 HTTP 프록싱이 비활성화된 경우 사이트는 읽기 전용 모드로 작동하며 알아두어야 할 몇 가지 중요한 제한이 있습니다.

보조 프록싱을 비활성화하면 발생하는 일#

프록싱 기능 플래그를 비활성화하면 다음과 같은 일반적인 효과가 있습니다.

HTTP 및 Git 요청#

• 보조 사이트는 HTTP 요청을 기본 사이트로 프록싱하지 않습니다. 대신 자체적으로 처리하거나 실패합니다.
• Git 요청은 일반적으로 성공합니다. Git 푸시는 기본 사이트로 리디렉션되거나 프록싱됩니다.
• Git 요청 이외에 데이터를 쓸 수 있는 모든 HTTP 요청은 실패합니다. 읽기 요청은 일반적으로 성공합니다.

GEO_SECONDARY_PROXY 환경 변수보다 기능 플래그를 사용해야 합니다.

HTTP 프록싱은 통합 URL 없이도 GitLab 15.1의 보조 사이트에서 기본적으로 활성화됩니다.

서비스 약관 동의#

프록싱이 비활성화된 경우 보조 사이트에만 액세스하는 사용자는 서비스 약관이나 기타 법적 계약을 제대로 수락할 수 없습니다. 이로 인해 다음과 같은 문제가 발생합니다:

• 수락 기록 없음: 직원이 보조 사이트에만 로그인하는 경우 보조 프록싱이 비활성화되어 있을 때 쓰기 작업(약관 수락 포함)이 프록싱되지 않으므로 약관 메시지가 표시되더라도 약관 수락이 기본 데이터베이스에 기록되지 않습니다.
• 법적 준수 문제: 직원이 보조 전용 액세스 패턴을 통해 GitLab 서비스를 사용하는 경우 약관에 대한 동의의 검증 가능한 기록이 없으므로 조직이 적절한 법적 보호를 받지 못할 수 있습니다.

해결 방법으로 약관을 제대로 수락하려면 최소한 한 번은 기본 사이트에 액세스해야 합니다. 기본 사이트에서 수락한 후 이 정보는 일반적인 Geo 동기화를 통해 보조 사이트로 복제됩니다.

모든 보조 사이트에서 프록시 비활성화#

모든 보조 사이트에서 프록싱을 비활성화해야 하는 경우 기능 플래그를 비활성화하는 것이 가장 쉽습니다:

보조 사이트 프록싱이 다시 활성화되도록 변경 사항을 되돌리려면:

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

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

gitlab:
  webservice:
    extraEnv:
      GEO_SECONDARY_PROXY: "0"

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

다음의 전달을 비활성화하는 것은 불가능합니다:

• SSH를 통한 Git 푸시
• 보조 사이트에서 Git 리포지토리가 최신 상태가 아닐 때 SSH를 통한 Git 풀
• HTTP를 통한 Git 푸시
• 보조 사이트에서 Git 리포지토리가 최신 상태가 아닐 때 HTTP를 통한 Git 풀