Geo는 광범위하게 분산된 개발 팀과 재해 복구 전략의 일환으로 웜 스탠바이를 제공하기 위한 솔루션입니다. Geo는 기본 제공 HA 솔루션이 아닙니다.

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

대규모 리포지토리를 가져오는 것은 단일 GitLab 인스턴스에서 멀리 떨어진 팀과 Runner에게 오랜 시간이 걸릴 수 있습니다.

Geo는 읽기 요청을 제공할 수 있는 원격 팀 근처에 지리적으로 배치할 수 있는 로컬 캐시를 제공합니다. 이를 통해 대규모 리포지토리를 clone하고 fetch하는 데 걸리는 시간을 줄여 개발 속도를 높이고 원격 팀의 생산성을 향상시킬 수 있습니다.

Geo 보조 사이트는 쓰기 요청을 기본 사이트로 투명하게 프록시합니다. 모든 Geo 사이트는 사용자가 어느 사이트에 접속하든 일관되고 원활하며 포괄적인 경험을 제공하기 위해 단일 GitLab URL에 응답하도록 구성할 수 있습니다.

Geo는 Geo 용어집에 설명된 정의된 용어 집합을 사용합니다. 해당 용어에 친숙해지세요.

사용 사례#

Geo 구현은 여러 사용 사례를 해결합니다. 이 섹션에서는 의도된 사용 사례 중 일부를 제공하고 이점을 강조합니다.

지역 재해 복구#

재해 복구 솔루션으로서의 Geo는 기본 사이트와 다른 지역의 웜 스탠바이 보조 사이트를 제공합니다. 데이터는 보조 사이트에 지속적으로 동기화되어 항상 최신 상태를 유지합니다. 데이터 센터나 네트워크 중단, 하드웨어 장애와 같은 재해 발생 시 완전히 운영 가능한 보조 사이트로 장애 조치할 수 있습니다. 계획된 장애 조치로 재해 복구 프로세스 및 인프라를 테스트할 수 있습니다.

이점:

• 지역 재해 발생 시 비즈니스 연속성.
• 낮은 RTO(복구 시간 목표) 및 RPO(복구 지점 목표).
• GitLab Environment Toolkit(GET)을 통한 자동화된(자동이 아닌) 장애 조치.
• 최소한의 운영 노력 - 무인 지속적인 복제 및 검증으로 보조 사이트가 최신 상태를 유지하고 복제된 데이터가 전송 및 저장 중에 손상되지 않도록 보장.

원격 팀 가속화#

원격 팀에 지리적으로 더 가까운 Geo 보조 사이트를 설정하여 읽기 작업을 가속화하는 로컬 캐시를 제공합니다. 각각 원격 팀이 필요로 하는 프로젝트만 동기화하도록 맞춤 설정된 여러 Geo 보조 사이트를 가질 수 있습니다. 투명한 프록시와 통합 URL을 통한 지리적 라우팅으로 일관되고 원활한 개발자 경험을 보장합니다.

이점:

• 지리적으로 분산된 팀의 GitLab 경험 향상. Geo는 보조 사이트에서 완전한 GitLab 경험을 제공합니다: 하나의 기본 GitLab 사이트를 유지하면서 분산 팀 각각에 읽기-쓰기 액세스와 완전한 UI 경험을 갖춘 보조 사이트를 활성화합니다.
• 분산된 개발자가 대규모 리포지토리와 프로젝트를 clone하고 fetch하는 데 걸리는 시간을 분에서 초로 단축.
• 모든 개발자가 위치에 관계없이 아이디어를 기여하고 병렬로 작업할 수 있도록 지원.
• 기본 사이트와 보조 사이트 간의 읽기 부하 분산.
• 먼 사무소 간의 느린 연결을 극복하고 분산 팀의 속도를 향상시켜 시간 절약.
• 자동화된 작업, 사용자 정의 통합 및 내부 워크플로우의 로딩 시간 단축.

CI/CD 트래픽 오프로드#

CI/CD Runner가 Geo 보조 사이트에서 clone하도록 구성할 수 있습니다. Runner 워크로드의 필요에 맞게 보조 사이트를 맞춤 설정할 수 있으며 기본 사이트를 미러링할 필요가 없습니다. 지원되는 읽기 요청은 보조 사이트의 캐시된 데이터로 제공되며, 보조 사이트의 데이터가 오래되었거나 사용할 수 없을 때 요청이 기본 사이트로 투명하게 전달됩니다.

이점:

• 기본 사이트에서 트래픽을 보조 사이트로 이동하여 사용자 경험에 대한 CI/CD 트래픽의 영향 감소.
• 교차 지역 트래픽을 줄이고 조직에 가장 경제적인 곳에 CI/CD 컴퓨팅을 배치. 데이터의 단일 교차 지역 사본을 생성하고 보조 사이트에 대한 반복 읽기 요청에 사용 가능하게 만들기.

추가 사용 사례#

인프라 마이그레이션#

Geo를 사용하여 새 인프라로 마이그레이션할 수 있습니다. GitLab 인스턴스를 새 서버나 데이터 센터로 이동하는 경우, Geo를 사용하여 기존 인스턴스가 사용자에게 계속 서비스를 제공하는 동안 백그라운드에서 GitLab 데이터를 새 인스턴스로 마이그레이션합니다. 활성 GitLab 데이터의 모든 변경 사항이 새 인스턴스에 복사되므로 전환 중 데이터 손실이 없습니다.

Geo를 사용하여 한 운영 체제에서 다른 운영 체제로 PostgreSQL 데이터베이스를 마이그레이션할 수 없습니다. PostgreSQL 운영 체제 업그레이드를 참조하세요.

이점:

• 백업 및 복원 마이그레이션 방법과 비교하여 마이그레이션 중 다운타임을 크게 줄입니다. 전환 다운타임 기간 전에 활성 GitLab 인스턴스를 중지하지 않고 백그라운드에서 새 인스턴스로 데이터를 복사합니다.

GitLab Dedicated로 마이그레이션#

Geo를 사용하여 GitLab Self-Managed를 GitLab Dedicated로 마이그레이션할 수도 있습니다. GitLab Dedicated로의 마이그레이션은 인프라 마이그레이션과 유사합니다.

자세한 내용은 Geo로 GitLab Dedicated로 마이그레이션을 참조하세요.

이점:

• 훨씬 낮은 다운타임으로 더 원활한 온보딩 경험. 데이터 마이그레이션이 백그라운드에서 진행되는 동안 팀이 GitLab Self-Managed를 계속 사용할 수 있습니다.

Geo가 다루도록 설계되지 않은 것#

Geo는 모든 사용 사례를 해결하도록 설계되지 않았습니다. 이 섹션에서는 Geo가 적절한 솔루션이 아닌 사용 사례의 예를 제공합니다.

데이터 내보내기 규정 준수 적용#

Geo의 선택적 동기화 기능은 보조 사이트에 동기화되는 프로젝트를 제한할 수 있지만, 이는 교차 지역 트래픽과 스토리지 요구 사항을 줄이기 위해 설계된 것이지 내보내기 규정 준수를 적용하기 위한 것이 아닙니다. 솔루션 및 문서를 기반으로 개인 정보 보호, 사이버 보안, 적용 가능한 무역 통제법에 관한 법적 의무를 독립적으로 지속적으로 결정해야 합니다. 솔루션과 문서 모두 변경될 수 있습니다.

액세스 제어 제공#

Geo 읽기 전용 보조 사이트 기능은 1급 기능이 아니며 향후 지원되지 않을 수 있습니다. 액세스 제어 목적으로 이 기능에 의존해서는 안 됩니다. GitLab은 이 목적에 더 잘 맞는 인증 및 권한 부여 컨트롤을 제공합니다.

제로 다운타임 업그레이드 대안#

Geo는 제로 다운타임 업그레이드를 위한 솔루션이 아닙니다. 보조 사이트를 업그레이드하기 전에 기본 Geo 사이트를 업그레이드해야 합니다.

악의적이거나 의도치 않은 손상으로부터 보호#

Geo는 기본 사이트의 손상을 모든 보조 사이트에 복제합니다. 악의적이거나 의도치 않은 손상으로부터 보호하려면 Geo를 백업으로 보완해야 합니다.

활성-활성, 고가용성 구성#

Geo는 활성-수동 고가용성 솔루션으로 설계되었습니다. 보조 사이트가 기본 사이트와 긴밀하게 동기화되지 않음을 의미하는 최종 일관성 동기화 모델을 운영합니다. 보조 사이트는 작은 지연을 두고 기본 사이트를 따라가는데, 이로 인해 재해 후 소량의 데이터 손실이 발생할 수 있습니다. 재해 발생 시 보조 사이트로의 장애 조치는 사람의 개입이 필요합니다. 그러나 GET을 사용하여 모든 사이트를 배포한 경우 보조 사이트를 기본으로 승격하는 과정의 대부분이 GitLab Environment Toolkit(GET)에 의해 자동화됩니다.

Gitaly 클러스터(Praefect)#

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

Geo 작동 방식#

이것은 GitLab 환경에서 Geo가 어떻게 작동하는지에 대한 간략한 요약입니다. 자세한 내용은 Geo 개발 문서를 참조하세요.

Geo 인스턴스는 데이터를 읽는 것 외에도 프로젝트를 clone하고 fetch하는 데 사용할 수 있습니다. 이로 인해 먼 거리에 걸쳐 대규모 리포지토리로 작업하는 것이 훨씬 빨라집니다.

Geo가 활성화되면:

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

다음을 염두에 두세요:

• 보조 사이트는 다음을 위해 기본 사이트와 통신합니다:
  • 로그인을 위한 사용자 데이터 가져오기(API).
  • 리포지토리, LFS 객체 및 첨부 파일 복제(HTTPS + JWT).
• 기본 사이트는 복제 세부 정보를 보기 위해 보조 사이트와 통신합니다. 기본 사이트는 동기화 및 검증 데이터를 위해 보조 사이트에 대해 GraphQL 쿼리를 수행합니다(API).
• 보조 사이트로 직접 push할 수 있으며(HTTP 및 SSH 모두, Git LFS 포함), 요청이 기본 사이트로 프록시됩니다.
• Geo를 사용할 때 몇 가지 알려진 문제가 있습니다.

아키텍처#

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

이 다이어그램에서:

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

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

• 기본 사이트는 완전한 읽기-쓰기 GitLab 인스턴스로 동작합니다.
• 보조 사이트는 완전한 읽기-쓰기 GitLab 인스턴스로 동작합니다. 보조 사이트는 일부 눈에 띄는 예외를 제외하고 모든 작업을 기본 사이트로 투명하게 프록시합니다. 특히 Git fetch는 보조 사이트가 최신 상태일 때 보조 사이트에 의해 제공됩니다.

GitLab UI를 탐색하거나 API를 사용하는 사용자의 관점에서:

• 기본 사이트는 완전한 읽기-쓰기 GitLab 인스턴스로 동작합니다.
• 보조 사이트는 완전한 읽기-쓰기 GitLab 인스턴스로 동작합니다. 보조 사이트는 일부 눈에 띄는 예외를 제외하고 모든 작업을 기본 사이트로 투명하게 프록시합니다. 특히 웹 UI 자산은 보조 사이트에 의해 제공됩니다.

다이어그램을 단순화하기 위해 일부 필요한 구성 요소는 생략되었습니다.

• SSH를 통한 Git은 gitlab-shell이 필요합니다.
• HTTPS를 통한 Git은 gitlab-workhorse가 필요합니다.

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

• 메인 GitLab 데이터베이스에서 데이터를 스트리밍하는 읽기 전용 데이터베이스 인스턴스.
• 복제된 데이터를 기록하기 위해 보조 사이트에서 내부적으로 사용되는 읽기/쓰기 데이터베이스 인스턴스(추적 데이터베이스).

보조 사이트는 추가 데몬도 실행합니다: Geo Log Cursor.

Geo 실행 요구 사항#

다음은 Geo를 실행하는 데 필요합니다:

• OpenSSH 6.9 이상을 지원하는 운영 체제(데이터베이스에서 승인된 SSH 키의 빠른 조회에 필요) 다음 운영 체제는 현재 버전의 OpenSSH와 함께 제공되는 것으로 알려져 있습니다:
  • CentOS 7.4 이상
  • Ubuntu 16.04 이상
• 가능하면 모든 Geo 사이트에서 동일한 운영 체제 버전을 사용해야 합니다. Geo 사이트 간에 다른 운영 체제 버전을 사용하는 경우, 데이터베이스 인덱스의 자동 손상을 방지하기 위해 Geo 사이트 간에 OS 로캘 데이터 호환성을 확인해야 합니다.
• 스트리밍 복제를 갖춘 GitLab 릴리스에 대한 지원되는 PostgreSQL 버전.
  • PostgreSQL 논리적 복제는 지원되지 않습니다.
• 모든 사이트는 동일한 PostgreSQL 버전을 실행해야 합니다.
• Git 2.9 이상
• LFS를 사용할 때 사용자 측에서 Git-lfs 2.4.2 이상
• 모든 사이트는 정확히 동일한 GitLab 버전을 실행해야 합니다. 메이저, 마이너, 패치 버전이 모두 일치해야 합니다.
• 모든 사이트는 동일한 리포지토리 스토리지를 정의해야 합니다.
• Geo와 함께 컨테이너 레지스트리를 사용하는 경우, 각 사이트의 컨테이너 레지스트리 메타데이터 데이터베이스에 대해 별도의 외부 PostgreSQL 인스턴스를 구성해야 합니다. 자세한 내용은 보조 사이트를 위한 컨테이너 레지스트리를 참조하세요.

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

Geo는 기본 GitLab 설치 위에 추적 데이터베이스와 복제 메타데이터를 추가하므로, 리포지토리 데이터가 없는 최소 Geo 배포를 위해 사이트당 최소 40GB의 디스크 공간을 계획하세요. 자세한 내용은 스토리지 요구 사항을 참조하세요.

방화벽 규칙#

다음 표는 Geo를 위해 기본 사이트와 보조 사이트 간에 열려야 하는 기본 포트를 나열합니다. 장애 조치를 단순화하려면 양방향으로 포트를 열어야 합니다.

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

또한:

• 웹 터미널 지원을 위해 로드 밸런서가 WebSocket 연결을 올바르게 처리해야 합니다. HTTP 또는 HTTPS 프록시를 사용할 때 로드 밸런서는 Connection 및 Upgrade 홉별 헤더를 통과하도록 구성되어야 합니다. 자세한 내용은 웹 터미널 통합 가이드를 참조하세요.
• 포트 443에 HTTPS 프로토콜을 사용하는 경우 로드 밸런서에 SSL 인증서를 추가해야 합니다. GitLab 애플리케이션 서버에서 SSL을 종료하려면 TCP 프로토콜을 사용하세요.
• 외부/내부 URL에 HTTPS만 사용하는 경우 방화벽에서 포트 80을 열 필요가 없습니다.

내부 URL#

Geo 보조 사이트에서 기본 Geo 사이트로의 HTTP 요청은 기본 Geo 사이트의 내부 URL을 사용합니다. 이것이 Admin 영역의 기본 Geo 사이트 설정에 명시적으로 정의되지 않은 경우 기본 사이트의 공개 URL이 사용됩니다.

필수 조건:

• 관리자 액세스.

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

1. 오른쪽 상단 모서리에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Geo > Sites를 선택합니다.
3. 기본 사이트에서 Edit를 선택합니다.
4. Internal URL을 변경하고 Save changes를 선택합니다.

Geo 추적 데이터베이스#

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

• 새 자산 다운로드.
• 새 LFS 객체 fetch.
• 최근에 업데이트된 리포지토리에서 변경 사항 fetch.

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

Geo Log Cursor#

이 데몬은:

• 기본 사이트에서 보조 데이터베이스 인스턴스로 복제된 이벤트 로그를 읽습니다.
• 실행해야 하는 변경 사항으로 Geo 추적 데이터베이스 인스턴스를 업데이트합니다.

추적 데이터베이스 인스턴스에서 업데이트로 표시된 것이 있으면 보조 사이트에서 실행 중인 비동기 작업이 필요한 작업을 실행하고 상태를 업데이트합니다.

이 새로운 아키텍처를 통해 GitLab은 사이트 간 연결 문제에 대한 탄력성을 가질 수 있습니다. 보조 사이트가 기본 사이트에서 얼마나 오래 연결이 끊어졌는지는 중요하지 않으며, 올바른 순서로 모든 이벤트를 재생하고 기본 사이트와 다시 동기화될 수 있습니다.

알려진 문제#

• 보조 Geo 사이트를 통한 SSH를 통한 Git이 안정적으로 작동하지 않습니다. 자세한 내용은 이슈 #413109, 이슈 #417186, 이슈 #454707, 이슈 585913을 참조하세요.
• 보조 사이트로 직접 push하면 직접 처리 대신 요청이 기본 사이트로 리디렉션(HTTP의 경우)되거나 프록시(SSH의 경우)됩니다. URI에 자격 증명이 내장된 HTTP를 통한 Git(예: https://user:personal-access-token@secondary.tld)을 사용할 수 없습니다. 자세한 내용은 Geo 사이트 사용을 참조하세요.
• 기본 사이트가 OAuth 로그인이 작동하려면 온라인 상태여야 합니다. 기존 세션과 Git은 영향을 받지 않습니다. 기본에 독립적인 OAuth 공급자를 사용하는 보조 사이트에 대한 지원이 계획 중입니다.
• 설치에는 상황에 따라 약 1시간이 걸릴 수 있는 여러 수동 단계가 있습니다. GitLab Environment Toolkit Terraform 및 Ansible 스크립트를 사용하여 참조 아키텍처를 기반으로 프로덕션 GitLab 인스턴스를 배포하고 운영하는 것을 고려하세요. 일반적인 일상 작업의 자동화를 포함합니다. 에픽 1465는 Geo 설치를 더욱 개선하기 위해 제안됩니다.
• http 프록시가 비활성화된 보조 사이트에서는 이슈/머지 리퀘스트의 실시간 업데이트(예: 롱 폴링을 통해)가 작동하지 않습니다.
• 선택적 동기화는 복제되는 리포지토리 및 파일만 제한합니다. 전체 PostgreSQL 데이터는 여전히 복제됩니다. 선택적 동기화는 규정 준수 / 수출 통제 사용 사례를 수용하도록 설계되지 않았습니다.
• Pages 액세스 제어는 보조 사이트에서 작동하지 않습니다. 자세한 내용은 이슈 9336을 참조하세요.
• 여러 보조 사이트가 있는 배포의 재해 복구는 승격되지 않은 모든 보조 사이트에서 새 기본 사이트를 따르도록 PostgreSQL 스트리밍 복제를 다시 초기화해야 하므로 다운타임이 발생합니다.
• SSH를 통한 Git의 경우, 어느 사이트를 탐색하든 프로젝트 clone URL이 올바르게 표시되도록 하려면 보조 사이트가 기본 사이트와 동일한 포트를 사용해야 합니다. 자세한 내용은 이슈 339262를 참조하세요.
• 백업은 Geo 보조 사이트에서 실행할 수 없습니다.
• Geo 보조 사이트는 대부분의 경우 파이프라인의 첫 번째 단계의 clone 요청을 가속화(제공)하지 않습니다. 나중 단계도 보조 사이트에 의해 제공된다는 보장이 없습니다. 예를 들어 Git 변경이 크거나, 대역폭이 작거나, 파이프라인 단계가 짧은 경우. 일반적으로 후속 단계에 대한 clone 요청을 제공합니다. 이슈 446176은 그 이유를 논의하고 Runner clone 요청이 보조 사이트에서 제공될 가능성을 높이는 개선 사항을 제안합니다.
• 단일 Git 리포지토리가 충분히 높은 속도로 push를 수신하면 보조 사이트의 로컬 사본이 영구적으로 오래될 수 있습니다. 이로 인해 해당 리포지토리의 모든 Git fetch가 기본 사이트로 전달됩니다. 자세한 내용은 이슈 455870을 참조하세요.
• 프록시는 Puma 서비스 또는 웹 서비스의 GitLab 애플리케이션에서만 구현되므로 다른 서비스는 이 동작의 이점을 얻지 못합니다. 요청이 항상 기본으로 전송되도록 하려면 별도의 URL을 사용해야 합니다. 이러한 서비스에는 다음이 포함됩니다:
  • GitLab 컨테이너 레지스트리 - registry.example.com과 같은 별도의 도메인을 사용하도록 구성할 수 있습니다. 보조 사이트 컨테이너 레지스트리는 재해 복구 전용입니다. 사용자는 특히 push의 경우 이에 라우팅되어서는 안 됩니다. 데이터가 기본 사이트로 전파되지 않기 때문입니다.
  • GitLab Pages - GitLab Pages 실행을 위한 전제 조건의 일환으로 항상 별도의 도메인을 사용해야 합니다.
• 통합 URL을 사용할 때 Let's Encrypt는 동일한 도메인을 통해 두 IP에 모두 도달할 수 없으면 인증서를 생성할 수 없습니다. Let's Encrypt로 TLS 인증서를 사용하려면 Geo 사이트 중 하나에 도메인을 수동으로 지정하고 인증서를 생성한 다음 다른 모든 사이트에 복사하면 됩니다.
• 보조 사이트가 기본 사이트와 별도의 URL을 사용하는 경우 SAML을 사용하여 보조 사이트에 로그인은 SAML IdP(Identity Provider)가 여러 콜백 URL로 애플리케이션을 구성할 수 있는 경우에만 지원됩니다.
• 보조 사이트가 요청이 시작된 시점에 최신 상태가 아닌 경우 --depth 옵션이 있는 SSH를 통한 Git clone 및 fetch 요청이 보조 사이트에서 작동하지 않고 무기한 중단됩니다. 이는 프록시 중 Git SSH를 Git HTTPS로 변환하는 것과 관련된 문제로 인한 것입니다. 자세한 내용은 이슈 391980을 참조하세요. 앞서 언급한 변환 단계가 포함되지 않은 새 워크플로우는 이제 기능 플래그로 활성화할 수 있는 Linux 패키지 GitLab Geo 보조 사이트에서 사용 가능합니다. 자세한 내용은 이슈 454707의 코멘트를 참조하세요. Cloud Native GitLab Geo 보조 사이트의 수정은 이슈 5641에서 추적됩니다.
• GitLab Geo에서 상대 URL을 사용하지 마세요. 사이트 간 프록시를 중단시키기 때문입니다. 자세한 내용은 이슈 456427을 참조하세요.

복제된 데이터 유형#

모든 GitLab 데이터 유형 및 복제된 데이터 유형의 전체 목록이 있습니다.

설치 후 문서#

보조 사이트에 GitLab을 설치하고 초기 구성을 수행한 후 설치 후 정보는 다음 문서를 참조하세요.

Geo 설정#

Geo 구성에 대한 자세한 내용은 Geo 설정을 참조하세요.

객체 스토리지로 Geo 구성#

객체 스토리지로 Geo를 구성하는 방법에 대한 자세한 내용은 객체 스토리지를 사용한 Geo를 참조하세요.

컨테이너 레지스트리 복제#

컨테이너 레지스트리를 복제하는 방법에 대한 자세한 내용은 보조 사이트를 위한 컨테이너 레지스트리를 참조하세요.

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

AWS Route53 또는 Google Cloud DNS로 단일 위치 인식 URL을 설정하는 방법의 예는 Geo 사이트를 위한 통합 URL 설정을 참조하세요.

싱글 사인 온(SSO)#

SSO(Single Sign-On) 구성에 대한 자세한 내용은 SSO가 있는 Geo(SSO)를 참조하세요.

LDAP#

LDAP 구성에 대한 자세한 내용은 SSO가 있는 Geo > LDAP를 참조하세요.

Geo 튜닝#

Geo 튜닝에 대한 자세한 내용은 Geo 튜닝을 참조하세요.

복제 일시 중지 및 재개#

자세한 내용은 복제 일시 중지 및 재개를 참조하세요.

백필#

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

백필 중에 발생하는 실패는 백필이 끝날 때 재시도되도록 예약됩니다.

Runner#

• Runner 플릿 배포를 위한 표준 모범 사례 외에도, 작업 부하를 분산하기 위해 Geo 보조 사이트에 연결하도록 Runner를 구성할 수 있습니다. 보조 사이트에 Runner 등록 방법을 참조하세요.
• 장애 조치 중 Runner 연결 처리 방법도 참조하세요.

Geo 업그레이드#

Geo 사이트를 최신 GitLab 버전으로 업데이트하는 방법에 대한 자세한 내용은 Geo 사이트 업그레이드를 참조하세요.

보안 검토#

Geo 보안에 대한 자세한 내용은 Geo 보안 검토를 참조하세요.

Geo 사이트 제거#

Geo 사이트를 제거하는 방법에 대한 자세한 내용은 보조 Geo 사이트 제거를 참조하세요.

Geo 비활성화#

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

로그 파일#

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

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

재해 복구#

데이터 손실을 완화하고 서비스를 복원하기 위한 재해 복구 상황에서 Geo 사용에 대한 자세한 내용은 재해 복구를 참조하세요.

자주 묻는 질문#

일반적인 질문에 대한 답변은 Geo FAQ를 참조하세요.

문제 해결#

• Geo 문제 해결 단계는 Geo 문제 해결을 참조하세요.
• 재해 복구 문제 해결 단계는 Geo 장애 조치 문제 해결을 참조하세요.