• 사용 사례
  • Gitaly 클러스터
• 작동 방식
  • 아키텍처
• Geo 실행에 필요한 요구 사항
  • 방화벽 규칙
    • 내부 URL
  • Geo 추적 데이터베이스
  • Geo 로그 커서
• 제한 사항
  • 복제/확인 제한 사항
• 설정 지침
• 설치 후 문서
  • Geo 구성
  • Geo 업그레이드
  • 복제 일시 중지 및 재개
  • 복수 노드를 위한 Geo 구성
  • 객체 저장소를 사용한 Geo 구성
  • 재해 복구
  • 컨테이너 레지스트리 복제
  • Geo 보조 프록시
  • 단일 로그인 (SSO)
    • LDAP
  • 보안 검토
  • Geo 튜닝
  • 위치 기반 Git URL 설정
  • 백필
• Geo 사이트 해제
• Geo 비활성화
• 자주 묻는 질문
• 로그 파일
• 문제 해결

Geo

Geo는 널리 분산된 개발팀 및 재해 복구 전략의 일환으로 웜 스탠바이를 제공함으로써 해결책입니다.

경고: Geo는 릴리스별로 중요한 변경 사항을 겪습니다. 업그레이드는 지원되며 문서화되어 있지만 설치한 버전에 맞는 문서를 사용하는지 확인해야 합니다.

대량 저장소를 가져오는 데 오랜 시간이 걸릴 수 있습니다. 팀 및 러너가 단일 GitLab 인스턴스에서 멀리 떨어진 위치에 있는 경우 이는 문제가 될 수 있습니다.

Geo는 원격 팀에 지리적으로 가까운 위치에 배치될 수 있는 지역 캐시를 제공합니다. 이를 통해 큰 저장소의 클론 및 가져오기 시간을 줄일 수 있어 개발 시간을 단축시키고 원격 팀의 생산성을 향상시킬 수 있습니다.

Geo 보조 사이트는 기본 사이트로의 쓰기 요청을 투명하게 프록시합니다. 모든 Geo 사이트는 통일된 GitLab URL에 응답하도록 구성될 수 있어 사용자가 착륙하는 사이트와 관계없이 일관되고 통합적인 경험을 제공할 수 있습니다.

적절한 버전의 문서를 사용하고 있는지 확인하려면 GitLab.com의 Geo 페이지로 이동하여 Switch branch/tag 드롭다운 목록에서 적절한 릴리스를 선택하십시오. 예를 들어, v13.7.6-ee.

Geo는 Geo 용어집에 설명된 일련의 정의된 용어를 사용합니다. 이러한 용어에 익숙해지는 것이 좋습니다.

사용 사례

Geo 구현은 다음과 같은 이점을 제공합니다:

• 분산된 개발자들이 대형 저장소 및 프로젝트를 복제하고 가져오는 데 걸리는 시간을 분에서 초로 줄입니다.
• 모든 개발자가 자신들의 위치에 관계없이 아이디어를 기여하고 병행하여 작업할 수 있도록 합니다.
• 기본 및 보조 사이트 간의 읽기 전용로드를 균형잡아줍니다.

또한 다음을 수행합니다:

• 제한 사항을 참조하여 GitLab 웹 인터페이스에서 제공되는 모든 데이터를 읽는 데 추가로 프로젝트 복제 및 가져오기에 사용될 수 있습니다.
• 먼 사무실 간 느린 연결을 극복하여 분산된 팀의 속도를 개선함으로써 시간을 절약합니다.
• 자동화된 작업, 사용자 정의 통합 및 내부 워크플로우의 로딩 시간을 줄이는 데 도움이 됩니다.
• 재해 복구 시나리오에서 빠르게 보조 사이트로 장애 조치를 수행할 수 있습니다.
• 보조 사이트로의 계획된 장애 조치를 허용합니다.

Geo는 다음을 제공합니다:

• 보조 사이트에서 완전한 GitLab 경험: 하나의 기본 GitLab 사이트를 유지하고 분산된 팀 중 각각에 대해 전체 읽기 및 쓰기 및 UI 경험을 활성화합니다.
• 인증 시스템 후크: 보조 사이트는 모든 인증 데이터(사용자 계정 및 로그인과 같은)를 기본 인스턴스로부터 수신합니다.

Gitaly 클러스터

Geo는 Gitaly 클러스터와 혼동해서는 안 됩니다. Geo와 Gitaly 클러스터의 차이에 대한 자세한 내용은 Geo와 비교를 참조하십시오.

작동 방식

Geo 인스턴스는 프로젝트의 복제 및 가져오기뿐만 아니라 모든 데이터의 읽기에 사용될 수 있습니다. 이를 통해 긴 거리를 이동하는 대형 저장소와 함께 작업하는 작업을 빠르게 만들 수 있습니다.

Geo를 활성화하면 다음과 같은 작업이 수행됩니다:

• 원본 인스턴스는 기본 사이트로 알려져 있습니다.
• 복제 사이트는 보조 사이트로 알려져 있습니다.

기억해야 할 사항:

• 보조 사이트는 기본 사이트에 다음을 위해 연락합니다:
  • 로그인을 위한 사용자 데이터 구하기(API).
  • 저장소, LFS 개체 및 첨부 파일 복제(HTTPS + JWT).
• 기본 사이트는 변경 사항을 알리기 위해 보조 사이트에 연락하지 않습니다(API).
• 보조 사이트로 직접 push할 수 있습니다(HTTP 및 SSH 모두에 대해, Git LFS를 포함합니다).
• Geo 사용 시 제한 사항이 있습니다.

아키텍처

다음 다이어그램은 Geo의 기본 아키텍처를 보여줍니다.

이 다이어그램에서:

• 기본 사이트 및 보조 사이트의 세부 정보가 있습니다.
• 데이터베이스에 대한 쓰기는 오직 기본 사이트에서만 수행될 수 있습니다. 보조 사이트는 PostgreSQL 스트리밍 복제를 사용하여 데이터베이스 업데이트를 받습니다.
• LDAP 서버가 존재하는 경우 재해 복구 시나리오를 위해 복제되도록 구성해야 합니다.
• 보조 사이트는 JWT로 보호되는 특수 권한을 사용하여 기본 사이트와 다양한 유형의 동기화를 수행합니다:
  • 저장소는 HTTPS를 통해 복제/업데이트됩니다.
  • 첨부 파일, LFS 개체 및 기타 파일은 HTTP를 통해 특수 API 엔드포인트를 사용하여 다운로드됩니다.

Git 작업을 수행하는 사용자 관점에서:

• 기본 사이트는 완전한 읽기-쓰기 GitLab 인스턴스처럼 행동합니다.
• 보조 사이트는 읽기 전용이지만 Git push 작업을 기본 사이트로 프록시합니다. 이로써 보조 사이트는 스스로 push 작업을 지원하는 것처럼 보입니다.
• 보조 사이트는 웹 UI 요청을 프록시하여 기본 사이트로 보냅니다. 이로써 보조 사이트는 완전한 UI 읽기/쓰기 작업을 지원하는 것처럼 보입니다.

다이어그램을 단순화하기 위해 필수적인 구성 요소가 생략되었습니다.

• Git SSH를 위해 gitlab-shell 및 OpenSSH가 필요합니다.
• Git HTTPS를 위해 gitlab-workhorse가 필요합니다.

보조 사이트에는 두 개의 다른 PostgreSQL 데이터베이스가 필요합니다:

• 중앙 GitLab 데이터베이스에서 데이터를 스트리밍하는 읽기 전용 데이터베이스 인스턴스.
• 보조 사이트에서 내부적으로 사용되는 읽기-쓰기 데이터베이스(추적 데이터베이스).

보조 사이트에는 추가적인 데몬이 필요합니다: Geo 로그 커서.

Geo 실행에 필요한 요구 사항

다음은 Geo를 실행하는 데 필요한 사항입니다.

• OpenSSH 6.9 이상을 지원하는 운영 체제(데이터베이스에서 SSH 키의 빠른 조회에 필요함) 다음 운영 체제에서 현재 버전의 OpenSSH가 제공됨이 확인되었습니다:
  • CentOS 7.4 이상
  • Ubuntu 16.04 이상
• 지원되는 PostgreSQL 버전 및 스트리밍 복제이 있는 GitLab 릴리스용 참고: PostgreSQL 논리 복제는 지원되지 않습니다.
• 모든 사이트는 동일한 PostgreSQL 버전을 실행해야 합니다.
  • 가능한 경우 모든 Geo 사이트에서 동일한 운영 체제 버전을 사용해야 합니다. Geo 사이트 간에 다른 운영 체제 버전을 사용하는 경우 데이터베이스 인덱스의 은폐화된 손상을 피하기 위해 반드시 OS 로캘 데이터 호환성을 확인해야 합니다.
• Git 2.9 이상
• LFS를 사용할 때 사용자 측에서 Git-lfs 2.4.2 이상
• 모든 사이트는 정확히 동일한 GitLab 버전을 실행해야 합니다. 주 버전, 부 버전, 패치 버전이 모두 일치해야 합니다.
• 모든 사이트는 동일한 저장소 저장소를 정의해야 합니다.

또한 GitLab 최소 요구 사항을 확인하고, 더 나은 경험을 위해 최신 버전의 GitLab을 사용하세요.

방화벽 규칙

다음 표는 Geo의 Primary 및 Secondary 사이트 간에 열어야 하는 기본 포트를 나열합니다. 장애 조치를 간소화하기 위해 양방향으로 포트를 열어야 합니다.

GitLab에서 사용하는 포트 전체 목록은 패키지 기본값에서 확인하세요.

참고: 웹 터미널 지원을 위해서는 로드 밸런서가 WebSocket 연결을 올바르게 처리해야 합니다. HTTP 또는 HTTPS 프록시를 사용하는 경우 로드 밸런서는 Connection 및 Upgrade 호프바이호프 헤더를 통과시키도록 구성되어야 합니다. 자세한 내용은 웹 터미널 통합 가이드를 참조하세요.

참고: 포트 443에 HTTPS 프로토콜을 사용하는 경우 로드 밸런서에 SSL 인증서를 추가해야 합니다. 만약 GitLab 응용 프로그램 서버에서 SSL을 종료하려면 TCP 프로토콜을 사용하세요.

내부 URL

Geo Secondary 사이트에서 주 Geo 사이트로부터의 HTTP 요청은 주 Geo 사이트의 내부 URL을 사용합니다. 이를 주 Geo 사이트의 관리 영역에서 명시적으로 정의하지 않았다면, 주 사이트의 공개 URL이 사용됩니다.

주 Geo 사이트의 내부 URL을 업데이트하려면:

1. 왼쪽 사이드바에서 맨 아래에서 관리자 영역을 선택합니다.
2. Geo > 사이트를 선택합니다.
3. 주 사이트에서 편집을 선택합니다.
4. 내부 URL을 변경한 후 변경 사항 저장을 선택합니다.

Geo 추적 데이터베이스

추적 데이터베이스 인스턴스는 로컬 인스턴스에서 업데이트해야 할 메타데이터로 사용됩니다. 예를 들어:

• 새로운 에셋을 다운로드합니다.
• 새로운 LFS 객체를 가져옵니다.
• 최근에 업데이트된 리포지토리에서 변경 사항을 가져옵니다.

복제된 데이터베이스 인스턴스는 읽기 전용이므로 각 Secondary 사이트에 대해 이 추가 데이터베이스 인스턴스가 필요합니다.

Geo 로그 커서

이 데몬은 다음을 수행합니다:

• Primary 사이트에서 Secondary 데이터베이스 인스턴스로 복제된 이벤트 로그를 읽습니다.
• 실행해야 할 변경 사항을 추적 데이터베이스 인스턴스에 업데이트합니다.

추적 데이터베이스 인스턴스에서 업데이트해야 할 사항이 표시되면 Secondary 사이트에서 비동기 작업이 해당 작업을 실행하고 상태를 업데이트합니다.

이 새로운 아키텍처를 통해 사이트 간의 연결 문제에 강건하게 대처할 수 있습니다. Secondary 사이트가 Primary 사이트와의 연결이 며칠 동안 끊겨 있더라도 올바른 순서로 모든 이벤트를 다시 재생하고 다시 Primary 사이트와 동기화될 수 있습니다.

제한 사항

경고: 이 제한 사항 목록은 GitLab의 최신 버전에만 적용됩니다. 이전 버전을 사용하는 경우 추가 제한 사항이 적용될 수 있습니다.

• HTTP에 대한 프라이머리 사이트로 직접 푸시하면 요청이 프라이머리 사이트로 리디렉션(HTTPS의 경우) 또는 프록시(SSH의 경우)되어 직접 처리되지 않습니다. 이 제한 사항은 예를 들어 https://user:personal-access-token@secondary.tld와 같이 URI에 포함된 자격 증명을 사용하여 HTTP를 통해 Git을 사용할 수 없다는 것입니다. 자세한 내용은 Geo 사이트 사용을 참조하세요.
• OAuth 로그인을 위해서는 프라이머리 사이트가 온라인 상태여야 합니다. 기존 세션 및 Git에는 영향을 미치지 않습니다. 세컨더리 사이트가 프라이머리와 독립된 OAuth 제공 업체를 사용할 수 있도록 하는 것이 계획 중입니다.
• 설치에는 여러 수동 단계가 필요하며, 상황에 따라 약 1시간 정도 걸릴 수 있습니다. GitLab Environment Toolkit Terraform 및 Ansible 스크립트를 사용하여 참조 아키텍처에 따라 프로덕션 GitLab 인스턴스를 배포하고 운영하는 것을 고려하십시오. 에픽 1465은 Geo 설치를 더 개선하기 위한 것을 제안합니다.
• 이슈/병합 요청의 실시간 업데이트(예: 롱 폴링을 통해)는 세컨더리 사이트에서 작동하지 않습니다.
• Geo 세컨더리 사이트를 사용하여 러너를 가속화하는 것은 공식적으로 지원되지 않습니다. 이 기능에 대한 지원은 에픽 9779에서 계획되었으며 추적할 수 있습니다. 프라이머리와 세컨더리 사이트 간에 복제 지연이 발생하고 파이프라인 참조가 작업 실행 시 세컨더리 사이트에 없는 경우 작업이 실패합니다.
• 선택적 동기화는 복제되는 리포지토리 및 파일을 제한합니다. 전체 PostgreSQL 데이터는 여전히 복제됩니다. 선택적 동기화는 규정 준수/수출 통제 사용 사례를 수용하도록 구축되지 않았습니다.
• 페이지 액세스 제어는 세컨더리에서 작동하지 않습니다. 자세한 내용은 GitLab issue #9336을 참조하세요.
• 다중 세컨더리 사이트가 있는 배포의 재해 복구는 모든 프로모션되지 않은 세컨더리의 완전한 재동기화와 재구성으로 인해 다운 타임이 발생합니다.
• Git over SSH의 경우, 어떤 사이트를 브라우징하더라도 프로젝트 클론 URL이 올바르게 표시되려면 세컨더리 사이트도 프라이머리와 동일한 포트를 사용해야 합니다. GitLab issue #339262은 이 제한을 제거하기로 제안합니다.
• SSH를 통해 세컨더리 사이트로 1.86GB를 초과하는 푸시는 작동하지 않습니다. 이 버그는 GitLab issue #413109를 추적합니다.
• 백업은 세컨더리에서 실행할 수 없습니다. (replication/troubleshooting.md#message-error-canceling-statement-due-to-conflict-with-recovery)
• –depth 옵션을 사용한 SSH를 통한 Git 클론 및 페치 요청은 세컨더리 사이트에서 작동하지 않으며 요청이 시작된 시점에 세컨더리 사이트가 최신 상태가 아닌 경우 무기한 대기합니다. 자세한 내용은 이슈 391980을 참조하세요.
• SSH를 통해 세컨더리 사이트로 옵션과 함께 Git 푸시하는 것은 작동하지 않으며 연결을 종료합니다. 자세한 내용은 이슈 417186을 참조하세요.
• 대부분의 경우, Geo 세컨더리 사이트는 대부분의 경우 파이프라인의 첫 번째 단계에 대한 클론 요청을 가속화(서빙)하지 않습니다. 후속 단계의 경우도 보장되지 않으며, 예를 들어 Git 변경이 크거나 대역폭이 작거나 파이프라인 단계가 짧은 경우도 해당합니다. 일반적으로 후속 단계에 대한 클론 요청은 서컨더리 사이트에서 제공됩니다. 이슈 446176에서 이에 대한 이유를 논의하고 러너 클론 요청이 세컨더리 사이트에서 제공되는 가능성을 높이기 위한 개선을 제안합니다.

복제/확인 제한 사항

모든 GitLab 데이터 유형 및 복제 및 확인에 대한 기존 지원의 완전한 목록이 있습니다.

설정 지침

설정 지침은 Geo 설정을 참조하세요.

설치 후 문서

GitLab을 secondary 사이트에 설치한 후 초기 구성을 수행한 후, 다음 설명서를 참조하여 설치 후 정보를 확인하십시오.

Geo 구성

Geo 구성에 대한 정보는 Geo 구성을 참조하십시오.

Geo 업그레이드

최신 GitLab 버전으로 Geo 사이트를 업데이트하는 방법에 대한 정보는 Geo 사이트 업그레이드를 참조하십시오.

복제 일시 중지 및 재개

• GitLab 13.2에 도입되었습니다.

경고: 복제 일시 중지 및 재개는 리눅스 패키지관리형 데이터베이스를 사용하는 Geo 설치에 대해서만 지원됩니다. 외부 데이터베이스는 지원되지 않습니다.

업그레이드나 계획된 장애 조치 중과 같은 일부 상황에서 필요할 수 있습니다. 주/보조 사이트 간의 복제를 일시 중지하는 것이 바람직합니다.

업그레이드 중에 보조 사이트에서 사용자 활동을 허용할 계획이라면 제로 다운타임 업그레이드를 위해 복제를 일시 중지하지 마십시오. 일시 중지되는 동안 보조 사이트는 점점 더 오래된 상태가 됩니다. 알려진 효과 중 하나는 점점 더 많은 Git 페치가 주 사이트로 리다이렉트되거나 프록시되는 것입니다. 추가로 알려진 효과가 있을 수 있습니다.

복제 일시 중지 및 재개는 보조 사이트의 특정 노드에서 명령줄 도구를 사용하여 수행됩니다. 데이터베이스 아키텍처에 따라, 이것은 postgresql 또는 patroni 서비스를 대상으로 할 것입니다:

• 보조 사이트의 모든 서비스에 대해 단일 노드를 사용하는 경우, 이러한 명령을 이 단일 노드에서 실행해야 합니다.
• 보조 PostgreSQL 노드를 독립적으로 사용하는 경우, 이 명령을 이 독립된 PostgreSQL 노드에서 실행해야 합니다.
• 보조 사이트에서 Patroni 클러스터를 사용하는 경우, 이 명령을 보조 Patroni 스탠바이 리더 노드에서 실행해야 합니다.

보조 사이트의 모든 서비스에 대해 단일 노드를 사용하지 않는 경우, PostgreSQL 또는 Patroni 노드의 /etc/gitlab/gitlab.rb에 gitlab_rails['geo_node_name'] = 'node_name' 구성 라인이 있는지 확인하십시오. 여기서 node_name은 응용 프로그램 노드의 geo_node_name와 동일해야 합니다.

일시 중지: (보조 사이트에서)

또한, 복제를 일시 중지한 후 PostgreSQL을 다시 시작하면(VM을 다시 시작하거나 gitlab-ctl restart postgresql 명령으로 서비스를 다시 시작한 후) PostgreSQL이 자동으로 복제를 재개하므로 업그레이드나 계획된 장애 조치 시에는 원치 않는 동작입니다.

gitlab-ctl geo-replication-pause

재개: (보조 사이트에서)

gitlab-ctl geo-replication-resume

복수 노드를 위한 Geo 구성

여러 노드에 대한 Geo 구성에 대한 정보는 여러 서버에 대한 Geo를 참조하십시오.

객체 저장소를 사용한 Geo 구성

객체 저장소를 사용한 Geo 구성에 대한 정보는 객체 저장소를 사용한 Geo를 참조하십시오.

재해 복구

재해 복구 상황에서 데이터 손실을 완화하고 서비스를 복원하기 위해 Geo를 사용하는 방법에 대한 정보는 재해 복구를 확인하십시오.

컨테이너 레지스트리 복제

컨테이너 레지스트리를 복제하는 방법에 대한 자세한 정보는 보조 사이트를 위한 컨테이너 레지스트리를 참조하십시오.

Geo 보조 프록시

보조 사이트에서 Geo 프록시 사용에 대한 자세한 정보는 보조 사이트를 위한 Geo 프록시를 참조하십시오.

단일 로그인 (SSO)

단일 로그인 (SSO) 구성에 대한 자세한 정보는 단일 로그인 (SSO)를 사용한 Geo를 참조하십시오.

LDAP

LDAP를 구성하는 자세한 정보는 단일 로그인 (SSO) > LDAP을 참조하십시오.

보안 검토

Geo 보안에 대한 자세한 정보는 Geo 보안 검토를 참조하십시오.

Geo 튜닝

Geo 튜닝에 대한 자세한 정보는 Geo 튜닝을 참조하십시오.

위치 기반 Git URL 설정

AWS Route53을 사용하여 위치 기반 Git 원격 URL을 설정하는 예제에 대한 정보는 AWS Route53를 사용한 위치 기반 Git 원격 URL을 참조하십시오.

백필

보조 사이트를 설정하면 주 사이트의 누락된 데이터를 복제하여 백필이라는 프로세스가 시작됩니다. 브라우저의 주 사이트의 Geo Nodes 대시보드에서 각 Geo 사이트의 동기화 프로세스를 모니터링할 수 있습니다.

백필 중 발생하는 실패는 백필의 끝에서 다시 시도되도록 예약됩니다.

Geo 사이트 해제

Geo 사이트를 제거하는 자세한 정보는 보조 Geo 사이트 제거를 참조하십시오.

Geo 비활성화

Geo를 비활성화하는 방법은 Geo 비활성화를 참조하세요.

자주 묻는 질문

자주 묻는 질문에 대한 답변은 Geo FAQ를 참조하세요.

로그 파일

Geo는 구조화된 로그 메시지를 geo.log 파일에 저장합니다.

Geo 로그에 액세스하고 사용하는 방법에 대한 자세한 정보는 로그 시스템 문서의 Geo 섹션을 참조하세요.

문제 해결

문제 해결 단계는 Geo 문제 해결을 참조하세요.