InfoGrab Docs

AWS Route53을 사용한 위치 인식 Git 원격 URL

요약

GitLab Geo는 웹 UI 및 API 트래픽을 포함한 위치 인식 DNS를 지원합니다. 사용자에게 자동으로 가장 가까운 Geo 사이트를 사용하는 단일 원격 URL을 제공할 수 있습니다. 이것이 가능한 이유는 Git push 요청이 보조 사이트에서 기본 사이트로 자동으로 리디렉션(HTTP)되거나 프록시(SSH)될 수 있기 때문입니다.

Note

GitLab Geo는 웹 UI 및 API 트래픽을 포함한 위치 인식 DNS를 지원합니다. 이 구성은 이 문서에 설명된 위치 인식 Git 원격 URL보다 권장됩니다.

사용자에게 자동으로 가장 가까운 Geo 사이트를 사용하는 단일 원격 URL을 제공할 수 있습니다. 이는 사용자가 이동하면서 더 가까운 Geo 사이트를 활용하기 위해 Git 구성을 업데이트할 필요가 없음을 의미합니다.

이것이 가능한 이유는 Git push 요청이 보조 사이트에서 기본 사이트로 자동으로 리디렉션(HTTP)되거나 프록시(SSH)될 수 있기 때문입니다.

이 지침은 AWS Route53을 사용하지만, Cloudflare와 같은 다른 서비스도 사용할 수 있습니다.

필수 조건#

이 예제에서는 이미 다음을 설정했습니다:

  • primary.example.com을 Geo 기본 사이트로.
  • secondary.example.com을 Geo 보조 사이트로.

자동으로 요청을 다음으로 지시하는 git.example.com 서브도메인을 만듭니다:

  • 유럽에서 보조 사이트로.
  • 다른 모든 위치에서 기본 사이트로.

어떤 경우든 다음이 필요합니다:

  • 자체 주소에서 접근 가능한 작동하는 GitLab 기본 사이트.
  • 작동하는 GitLab 보조 사이트.
  • 도메인을 관리하는 Route53 호스팅 영역.

아직 Geo 기본 사이트와 보조 사이트를 설정하지 않은 경우 Geo 설정 지침을 참조하세요.

트래픽 정책 만들기#

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

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

    Route53 대시보드의 트래픽 정책 섹션

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

    트래픽 정책 이름 지정

  3. Policy Name 필드를 Single Git Host로 채우고 Next를 선택합니다.

    트래픽 정책에 대한 DNS 유형 선택

  4. DNS typeA: IP Address in IPv4 format으로 그대로 둡니다.

  5. Connect to를 선택하고 Geolocation rule을 선택합니다.

    지리적 위치 규칙 추가

  6. 첫 번째 Location으로 Default로 그대로 둡니다.

  7. Connect to를 선택하고 New endpoint를 선택합니다.

  8. Type으로 value를 선택하고 <your **primary** IP address>를 입력합니다.

  9. 두 번째 Location으로 Europe을 선택합니다.

  10. Connect to를 선택하고 New endpoint를 선택합니다.

  11. Type으로 value를 선택하고 <your **secondary** IP address>를 입력합니다.

    지리적 위치 규칙에 위치 및 엔드포인트 설정

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

    트래픽 정책에서 정책 레코드 설정

  13. Policy record DNS namegit으로 채웁니다.

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

    정책 레코드가 있는 트래픽 정책이 성공적으로 생성됨

예를 들어 git.example.com과 같이 지리적 위치로 Geo 사이트로 트래픽을 분배하는 단일 호스트를 성공적으로 설정했습니다!

특별 Git URL을 사용하도록 Git clone URL 구성#

사용자가 처음으로 리포지토리를 clone할 때 일반적으로 프로젝트 페이지에서 Git 원격 URL을 복사합니다. 기본적으로 이러한 SSH 및 HTTP URL은 현재 호스트의 외부 URL을 기반으로 합니다. 예를 들어:

  • git@secondary.example.com:group1/project1.git
  • https://secondary.example.com/group1/project1.git

리포지토리의 SSH 및 HTTPS URL

다음을 사용자 정의할 수 있습니다:

  • SSH 원격 URL을 위치 인식 git.example.com을 사용하도록. 이를 위해 웹 노드의 gitlab.rb에서 gitlab_rails['gitlab_ssh_host']를 설정하여 SSH 원격 URL 호스트를 변경합니다.
  • HTTP 원격 URL은 HTTP(S)의 사용자 정의 Git clone URL에 표시된 것처럼.

Git 요청 처리 동작 예제#

이전에 문서화된 구성 단계를 따른 후 Git 요청에 대한 처리가 이제 위치를 인식합니다. 요청에 대해:

  • 유럽 외부에서는 모든 요청이 기본 사이트로 지시됩니다.
  • 유럽 내에서는 다음을 통해:
    • HTTP:
      • git clone http://git.example.com/foo/bar.git보조 사이트로 지시됩니다.
      • git push는 초기에 보조로 지시되며, 이는 자동으로 primary.example.com으로 리디렉션됩니다.
    • SSH:
      • git clone git@git.example.com:foo/bar.git보조로 지시됩니다.
      • git push는 초기에 보조로 지시되며, 이는 자동으로 primary.example.com으로 요청을 프록시합니다.

AWS Route53을 사용한 위치 인식 Git 원격 URL

Tier: Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

GitLab Geo는 웹 UI 및 API 트래픽을 포함한 위치 인식 DNS를 지원합니다. 사용자에게 자동으로 가장 가까운 Geo 사이트를 사용하는 단일 원격 URL을 제공할 수 있습니다. 이것이 가능한 이유는 Git push 요청이 보조 사이트에서 기본 사이트로 자동으로 리디렉션(HTTP)되거나 프록시(SSH)될 수 있기 때문입니다.

Note

GitLab Geo는 웹 UI 및 API 트래픽을 포함한 위치 인식 DNS를 지원합니다. 이 구성은 이 문서에 설명된 위치 인식 Git 원격 URL보다 권장됩니다.

사용자에게 자동으로 가장 가까운 Geo 사이트를 사용하는 단일 원격 URL을 제공할 수 있습니다. 이는 사용자가 이동하면서 더 가까운 Geo 사이트를 활용하기 위해 Git 구성을 업데이트할 필요가 없음을 의미합니다.

이것이 가능한 이유는 Git push 요청이 보조 사이트에서 기본 사이트로 자동으로 리디렉션(HTTP)되거나 프록시(SSH)될 수 있기 때문입니다.

이 지침은 AWS Route53을 사용하지만, Cloudflare와 같은 다른 서비스도 사용할 수 있습니다.

필수 조건#

이 예제에서는 이미 다음을 설정했습니다:

  • primary.example.com을 Geo 기본 사이트로.
  • secondary.example.com을 Geo 보조 사이트로.

자동으로 요청을 다음으로 지시하는 git.example.com 서브도메인을 만듭니다:

  • 유럽에서 보조 사이트로.
  • 다른 모든 위치에서 기본 사이트로.

어떤 경우든 다음이 필요합니다:

  • 자체 주소에서 접근 가능한 작동하는 GitLab 기본 사이트.
  • 작동하는 GitLab 보조 사이트.
  • 도메인을 관리하는 Route53 호스팅 영역.

아직 Geo 기본 사이트와 보조 사이트를 설정하지 않은 경우 Geo 설정 지침을 참조하세요.

트래픽 정책 만들기#

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

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

    Route53 대시보드의 트래픽 정책 섹션

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

    트래픽 정책 이름 지정

  3. Policy Name 필드를 Single Git Host로 채우고 Next를 선택합니다.

    트래픽 정책에 대한 DNS 유형 선택

  4. DNS typeA: IP Address in IPv4 format으로 그대로 둡니다.

  5. Connect to를 선택하고 Geolocation rule을 선택합니다.

    지리적 위치 규칙 추가

  6. 첫 번째 Location으로 Default로 그대로 둡니다.

  7. Connect to를 선택하고 New endpoint를 선택합니다.

  8. Type으로 value를 선택하고 <your **primary** IP address>를 입력합니다.

  9. 두 번째 Location으로 Europe을 선택합니다.

  10. Connect to를 선택하고 New endpoint를 선택합니다.

  11. Type으로 value를 선택하고 <your **secondary** IP address>를 입력합니다.

    지리적 위치 규칙에 위치 및 엔드포인트 설정

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

    트래픽 정책에서 정책 레코드 설정

  13. Policy record DNS namegit으로 채웁니다.

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

    정책 레코드가 있는 트래픽 정책이 성공적으로 생성됨

예를 들어 git.example.com과 같이 지리적 위치로 Geo 사이트로 트래픽을 분배하는 단일 호스트를 성공적으로 설정했습니다!

특별 Git URL을 사용하도록 Git clone URL 구성#

사용자가 처음으로 리포지토리를 clone할 때 일반적으로 프로젝트 페이지에서 Git 원격 URL을 복사합니다. 기본적으로 이러한 SSH 및 HTTP URL은 현재 호스트의 외부 URL을 기반으로 합니다. 예를 들어:

  • git@secondary.example.com:group1/project1.git
  • https://secondary.example.com/group1/project1.git

리포지토리의 SSH 및 HTTPS URL

다음을 사용자 정의할 수 있습니다:

  • SSH 원격 URL을 위치 인식 git.example.com을 사용하도록. 이를 위해 웹 노드의 gitlab.rb에서 gitlab_rails['gitlab_ssh_host']를 설정하여 SSH 원격 URL 호스트를 변경합니다.
  • HTTP 원격 URL은 HTTP(S)의 사용자 정의 Git clone URL에 표시된 것처럼.

Git 요청 처리 동작 예제#

이전에 문서화된 구성 단계를 따른 후 Git 요청에 대한 처리가 이제 위치를 인식합니다. 요청에 대해:

  • 유럽 외부에서는 모든 요청이 기본 사이트로 지시됩니다.
  • 유럽 내에서는 다음을 통해:
    • HTTP:
      • git clone http://git.example.com/foo/bar.git보조 사이트로 지시됩니다.
      • git push는 초기에 보조로 지시되며, 이는 자동으로 primary.example.com으로 리디렉션됩니다.
    • SSH:
      • git clone git@git.example.com:foo/bar.git보조로 지시됩니다.
      • git push는 초기에 보조로 지시되며, 이는 자동으로 primary.example.com으로 요청을 프록시합니다.