• 아키텍처 개요
• 여러 노드를 위한 Redis 및 PostgreSQL
• 전제 조건: 두 개의 독립적으로 작동하는 GitLab 다중 노드 사이트
• GitLab 사이트를 Geo 주요 사이트로 구성
  • 1단계: 주요 프론트엔드 노드 구성
  • 2단계: 사이트를 기본 사이트로 정의하기
• 다른 GitLab 사이트를 Geo 보조 사이트로 구성하기
  • 1단계: Geo 보조 사이트에서 Redis 및 Gitaly 서비스 구성하기
  • 2단계: Geo 보조 사이트에서 Geo 추적 데이터베이스 구성하기
  • 3단계: PostgreSQL 스트리밍 복제 구성
  • 4단계: Geo 보조 사이트의 프론트엔드 애플리케이션 노드 구성
  • 5단계: Geo 보조 사이트에 대한 LoadBalancer 설정
  • 6단계: Geo 보조 사이트에서 백엔드 애플리케이션 노드 구성
  • 7단계: 비밀 복사 및 애플리케이션에 보조 사이트 추가

여러 노드를 위한 Geo

이 문서는 다중 노드 구성에서 Geo를 실행하기 위한 최소 참조 아키텍처를 설명합니다.

귀하의 다중 노드 설정이 설명된 것과 다르다면, 이러한 지침을 귀하의 필요에 맞게 조정할 수 있습니다.

아키텍처 개요

다이어그램 출처 - GitLab 직원 전용

위의 토폴로지는 주요 및 보조 Geo 사이트가 서로 다른 두 위치에 있으며, 각자의 가상 네트워크에서 개인 IP 주소를 사용하고 있다고 가정합니다.

네트워크는 한 지리적 위치 내의 모든 머신이 개인 IP 주소를 사용하여 서로 통신할 수 있도록 구성되어 있습니다.

제공된 IP 주소는 예시이며, 배포의 네트워크 토폴로지에 따라 다를 수 있습니다.

두 Geo 사이트에 접근하는 유일한 외부 방법은 위의 예에서 gitlab.us.example.com 및 gitlab.eu.example.com의 HTTPS입니다.

참고:
주요 및 보조 Geo 사이트는 HTTPS를 통해 서로 통신할 수 있어야 합니다.

여러 노드를 위한 Redis 및 PostgreSQL

PostgreSQL 및 Redis에 대한 이 구성을 설정하는 데 추가 복잡성이 있으므로, 이 Geo 다중 노드 문서에서는 다루지 않습니다.

Linux 패키지를 사용하여 다중 노드 PostgreSQL 클러스터 및 Redis 클러스터를 설정하는 방법에 대한 자세한 내용은 다음을 참조하세요:

• Geo 다중 노드 데이터베이스 복제
• Redis 다중 노드 문서

참고:
PostgreSQL 및 Redis에 대해 클라우드 호스팅 서비스를 사용할 수 있지만, 이는 이 문서의 범위를 벗어납니다.

전제 조건: 두 개의 독립적으로 작동하는 GitLab 다중 노드 사이트

한 GitLab 사이트는 Geo 주요 사이트로 사용됩니다. 이 설정을 위해 GitLab 참조 아키텍처 문서를 사용하세요.

각 Geo 사이트에 대해 서로 다른 참조 아키텍처 크기를 사용할 수 있습니다.
이미 사용 중인 GitLab 인스턴스가 있다면, 이를 주요 사이트로 사용할 수 있습니다.

두 번째 GitLab 사이트는 Geo 보조 사이트로 사용됩니다. 마찬가지로, GitLab 참조 아키텍처 문서를 사용하여 설정합니다.

로그인하고 테스트하는 것이 좋습니다. 하지만 주요 사이트에서 복제되는 과정의 일부로 데이터가 삭제된다는 점에 유의하세요.

GitLab 사이트를 Geo 주요 사이트로 구성

다음 단계는 GitLab 사이트가 Geo 주요 사이트로 작동할 수 있도록 합니다.

1단계: 주요 프론트엔드 노드 구성

참고:
단일 노드 사이트를 위해 의도된 geo_primary_role을 사용하지 마세요.

1. /etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다:

   ##  
   ## Geo 사이트의 고유 식별자입니다.  
   ## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings  
   ##  
   gitlab_rails['geo_node_name'] = '<site_name_here>'  
   
   ##  
   ## 자동 마이그레이션 비활성화  
   ##  
   gitlab_rails['auto_migrate'] = false  
   

이 변경을 한 후, 변경 사항이 적용되도록 GitLab 재구성하기를 수행합니다.

2단계: 사이트를 기본 사이트로 정의하기

1. 프론트엔드 노드 중 하나에서 다음 명령을 실행합니다:

   sudo gitlab-ctl set-geo-primary-node
   

참고: PostgreSQL과 Redis는 일반적인 GitLab 다중 노드 설정 중에 애플리케이션 노드에서 이미 비활성화되어 있어야 합니다. 애플리케이션 노드에서 백엔드 노드의 서비스로의 연결도 구성되어야 합니다. PostgreSQL 및 Redis의 다중 노드 구성 문서를 참조하세요.

다른 GitLab 사이트를 Geo 보조 사이트로 구성하기

보조 사이트는 기타 GitLab 다중 노드 사이트와 유사하지만 세 가지 주요 차이점이 있습니다:

• 주요 PostgreSQL 데이터베이스는 Geo 기본 사이트의 PostgreSQL 데이터베이스의 읽기 전용 복제본입니다.
• 각 Geo 보조 사이트에 대해 추가 PostgreSQL 데이터베이스가 있으며, 이를 “Geo 추적 데이터베이스”라고 하며, 다양한 리소스의 복제 및 검증 상태를 추적합니다.
• 추가 GitLab 서비스 geo-logcursor가 있습니다.

따라서 다중 노드 구성 요소를 하나씩 설정하고 일반적인 다중 노드 설정에서의 편차를 포함합니다. 그러나 우리는 먼저 Geo 설정의 일부가 아닌 것처럼 전혀 새로운 GitLab 사이트를 구성할 것을 강력히 권장합니다. 그렇게 하면 작동하는 GitLab 사이트인지 확인할 수 있습니다. 그런 다음에만 Geo 보조 사이트로 사용할 수 있도록 수정해야 합니다. 이는 Geo 설정 문제를 관계없는 다중 노드 구성 문제와 분리하는 데 도움이 됩니다.

1단계: Geo 보조 사이트에서 Redis 및 Gitaly 서비스 구성하기

다음 서비스를 구성합니다. 다시 한 번 비Geo 다중 노드 문서를 사용하세요:

• GitLab을 위한 Redis 구성 다중 노드에 대한.
• Geo 기본 사이트에서 동기화된 데이터를 저장하는 Gitaly.

참고: NFS는 Gitaly 대신 사용할 수 있지만 권장되지 않습니다.

2단계: Geo 보조 사이트에서 Geo 추적 데이터베이스 구성하기

Geo 추적 데이터베이스는 다중 노드 PostgreSQL 클러스터에서 실행할 수 없습니다. 추적 PostgreSQL 데이터베이스를 위한 Patroni 클러스터 구성을 참조하세요.

Geo 추적 데이터베이스는 다음과 같이 단일 노드에서 실행할 수 있습니다:

1. GitLab 애플리케이션이 추적 데이터베이스에 액세스하는 데 사용하는 데이터베이스 사용자의 원하는 비밀번호에 대한 MD5 해시를 생성합니다:

   사용자 이름(gitlab_geo 기본값)은 해시에 포함됩니다.

   gitlab-ctl pg-password-md5 gitlab_geo
   # 비밀번호 입력: <your_tracking_db_password_here>
   # 비밀번호 확인: <your_tracking_db_password_here>
   # fca0b89a972d69f00eb3ec98a5838484
   

   이 해시를 사용하여 다음 단계에서 <tracking_database_password_md5_hash>를 채우세요.

2. Geo 추적 데이터베이스가 실행될 머신에서 /etc/gitlab/gitlab.rb에 다음을 추가합니다:

   ##
   ## Geo 보조 추적 데이터베이스 활성화
   ##
   geo_postgresql['enable'] = true
   geo_postgresql['listen_address'] = '<ip_address_of_this_host>'
   geo_postgresql['sql_user_password'] = '<tracking_database_password_md5_hash>'
   
   ##
   ## 복제 데이터베이스에 대한 PostgreSQL 연결 구성
   ##
   geo_postgresql['md5_auth_cidr_addresses'] = ['<replica_database_ip>/32']
   gitlab_rails['db_host'] = '<replica_database_ip>'
   
   # 복제 데이터베이스에서 마이그레이션을 실행하려고 시도하는
   # 재구성 방지
   gitlab_rails['auto_migrate'] = false
   

이 변경 사항을 만든 후, GitLab 재구성을 수행하여 변경 사항을 적용합니다.

외부 PostgreSQL 인스턴스를 사용하는 경우, 외부 PostgreSQL 인스턴스를 사용하는 Geo도 참조하세요.

3단계: PostgreSQL 스트리밍 복제 구성

Geo 데이터베이스 복제 지침을 따르세요.

외부 PostgreSQL 인스턴스를 사용하는 경우, 또한 외부 PostgreSQL 인스턴스와 함께하는 Geo를 참조하세요.

보조 Geo 사이트의 읽기-복제 데이터베이스에서 스트리밍 복제가 활성화된 후, gitlab-rake db:migrate:status:geo와 같은 명령은 실패하게 됩니다. 보조 사이트 구성 완료 전까지는, 특히 Geo 구성 - 3단계. 보조 사이트 추가를 완료해야 합니다.

4단계: Geo 보조 사이트의 프론트엔드 애플리케이션 노드 구성

참고: 단일 노드 사이트를 위해 의도된 geo_secondary_role을 사용하지 마세요.

위의 최소 아키텍처 다이어그램에서, GitLab 애플리케이션 서비스가 실행되는 두 대의 기계가 있습니다. 이러한 서비스는 구성에서 선택적으로 활성화됩니다.

관련 단계에 따라 GitLab Rails 애플리케이션 노드를 구성하세요 참조 아키텍처에 설명된 대로, 그런 다음 다음과 같이 수정하세요:

1. Geo 보조 사이트의 각 애플리케이션 노드에서 /etc/gitlab/gitlab.rb를 편집하고 다음을 추가하세요:

   ##
   ## GitLab 애플리케이션 서비스를 활성화합니다. application_role은 많은 서비스를 활성화합니다.
   ## 또는, 수평 확장 및 관심사 분리를 도움을 주기 위해 
   ## 다른 노드에서 특정 서비스를 선택적으로 활성화하거나 비활성화할 수 있습니다.
   ##
   roles ['application_role']
   
   ## `application_role`이 이미 이 기능을 활성화합니다. 
   ## `puma`, `sidekiq`, `geo-logcursor` 등과 같이 Rails에 의존하는 개별 서비스 
   ##를 선택적으로 활성화하는 경우에만 이 줄이 필요합니다.
   gitlab_rails['enable'] = true
   
   ##
   ## Geo Log Cursor 서비스를 활성화합니다
   ##
   geo_logcursor['enable'] = true
   
   ##
   ## Geo 사이트의 고유 식별자. 
   ## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
   ## 을 참조하세요
   ##
   gitlab_rails['geo_node_name'] = '<site_name_here>'
   
   ##
   ## 자동 마이그레이션 비활성화
   ##
   gitlab_rails['auto_migrate'] = false
   
   ##
   ## 추적 데이터베이스와의 연결 구성
   ##
   geo_secondary['enable'] = true
   geo_secondary['db_host'] = '<geo_tracking_db_host>'
   geo_secondary['db_password'] = '<geo_tracking_db_password>'
   
   ##
   ## 스트리밍 복제 데이터베이스와의 연결 구성, 
   ## 아직 구성하지 않은 경우
   ##
   gitlab_rails['db_host'] = '<replica_database_host>'
   gitlab_rails['db_password'] = '<replica_database_password>'
   
   ##
   ## Redis와의 연결 구성, 아직 구성하지 않은 경우
   ##
   gitlab_rails['redis_host'] = '<redis_host>'
   gitlab_rails['redis_password'] = '<redis_password>'
   
   ##
   ## Omnibus에서 관리되지 않는 사용자에 대한 
   ## 사용자 UID 및 GID를 아래와 같이 지정해야 하며, 
   ## 클러스터 내에서 노드 간의 일치를 보장하여 
   ## 권한 문제를 피해야 합니다.
   ##
   user['uid'] = 9000
   user['gid'] = 9000
   web_server['uid'] = 9001
   web_server['gid'] = 9001
   registry['uid'] = 9002
   registry['gid'] = 9002
   

참고: Linux 패키지를 사용하여 PostgreSQL 클러스터를 설정하고, postgresql['sql_user_password'] = 'md5 digest of secret'를 설정했다면, gitlab_rails['db_password']와 geo_secondary['db_password']에는 평문 비밀번호가 포함된다는 점을 유의하시기 바랍니다. 이는 Rails 노드가 데이터베이스에 연결할 수 있도록 하기 위해 사용됩니다.

참고: 현재 노드의 IP가 읽기-복제 데이터베이스의 postgresql['md5_auth_cidr_addresses'] 설정에 나열되어 있어야 Rails가 이 노드에서 PostgreSQL에 연결할 수 있습니다.

이러한 변경을 한 후, GitLab 재구성하여 변경 사항이 적용되도록 하세요.

아키텍처 개요 토폴로지에서, “프론트엔드” 노드에서 활성화된 GitLab 서비스는 다음과 같습니다:

• geo-logcursor
• gitlab-pages
• gitlab-workhorse
• logrotate
• nginx
• registry
• remote-syslog
• sidekiq
• puma

프론트엔드 애플리케이션 노드에서 sudo gitlab-ctl status를 실행하여 이러한 서비스가 존재하는지 확인하세요.

5단계: Geo 보조 사이트에 대한 LoadBalancer 설정

위의 최소 아키텍처 다이어그램은 트래픽을 애플리케이션 노드로 라우팅하기 위해 각 지리적 위치에 로드 밸런서를 배치하는 것을 보여줍니다.

자세한 내용은 여러 노드가 있는 GitLab에 대한 Load Balancer를 참조하세요.

6단계: Geo 보조 사이트에서 백엔드 애플리케이션 노드 구성

위의 최소 아키텍처 다이어그램은 모든 애플리케이션 서비스가 동일한 머신에서 함께 실행되는 것을 보여줍니다. 그러나 여러 노드의 경우 우리는 모든 서비스를 별도로 실행할 것을 강력히 권장합니다.

예를 들어, Sidekiq 노드는 위의 프론트엔드 애플리케이션 노드와 유사하게 구성될 수 있으며, sidekiq 서비스만 실행하도록 일부 변경이 필요합니다:

1. Geo 보조 사이트의 각 Sidekiq 노드에서 /etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다:

   ##
   ## Sidekiq 서비스를 활성화합니다
   ##
   sidekiq['enable'] = true
   gitlab_rails['enable'] = true
   
   ##
   ## Geo 사이트의 고유 식별자입니다. 참조하세요
   ## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
   ##
   gitlab_rails['geo_node_name'] = '<site_name_here>'
   
   ##
   ## 자동 마이그레이션 비활성화
   ##
   gitlab_rails['auto_migrate'] = false
   
   ##
   ## 추적 데이터베이스에 대한 연결 구성
   ##
   geo_secondary['enable'] = true
   geo_secondary['db_host'] = '<geo_tracking_db_host>'
   geo_secondary['db_password'] = '<geo_tracking_db_password>'
   
   ##
   ## 스트리밍 복제 데이터베이스에 대한 연결을 구성합니다.
   ## 아직 구성하지 않은 경우
   ##
   gitlab_rails['db_host'] = '<replica_database_host>'
   gitlab_rails['db_password'] = '<replica_database_password>'
   
   ##
   ## Redis에 대한 연결을 구성합니다. 아직 구성하지 않은 경우
   ##
   gitlab_rails['redis_host'] = '<redis_host>'
   gitlab_rails['redis_password'] = '<redis_password>'
   
   ##
   ## Omnibus에서 관리되지 않는 사용자 사용 시, 아래와 같이
   ## UID 및 GID를 지정해야 하며, 클러스터 간에 일치하는지 확인해야 
   ## 권한 문제를 피할 수 있습니다.
   ##
   user['uid'] = 9000
   user['gid'] = 9000
   web_server['uid'] = 9001
   web_server['gid'] = 9001
   registry['uid'] = 9002
   registry['gid'] = 9002
   

   geo-logcursor 서비스만 실행하도록 노드를 유사하게 구성할 수 있으며, geo_logcursor['enable'] = true로 설정하고 Sidekiq는 sidekiq['enable'] = false로 비활성화할 수 있습니다.

   이러한 노드는 로드 밸런서에 연결될 필요가 없습니다.

7단계: 비밀 복사 및 애플리케이션에 보조 사이트 추가

1. GitLab 구성을 설정하여 기본 및 보조 사이트를 설정합니다.