• 아키텍처 개요
• 여러 노드용 Redis 및 PostgreSQL
• 사전 요구 사항: 두 개별로 작동하는 GitLab 멀티 노드 사이트
• GitLab 사이트를 Geo 기본 사이트로 구성하기
  • 단계 1: 기본 프론트엔드 노드 구성
  • 단계 2: 사이트를 기본 사이트로 정의
• 다른 GitLab 사이트를 Geo 보조 사이트로 구성하기
  • 단계 1: Geo 보조 사이트에서 Redis 및 Gitaly 서비스 구성하기
  • 단계 2: Geo 보조 사이트에서 Geo 추적 데이터베이스 구성하기
• 복제 데이터베이스로의 PostgreSQL 연결 구성
  • 단계 3: PostgreSQL 스트리밍 복제 구성
  • 단계 4: Geo secondary 사이트의 프런트엔드 애플리케이션 노드 구성
  • 단계 5: Geo secondary 사이트의 로드 밸런서 설정
  • 단계 6: Geo secondary 사이트의 백엔드 애플리케이션 노드 구성
  • 단계 7: 비밀 정보 복사 및 애플리케이션에 보조 사이트 추가

여러 노드용 Geo

이 문서는 멀티 노드 구성에서 Geo를 실행하기 위한 최소한의 참조 아키텍처를 설명합니다. 멀티 노드 설정이 여기서 설명된 구성과 다른 경우, 이 지침을 자신의 요구에 맞게 적응시킬 수 있습니다.

아키텍처 개요

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

위의 토폴로지는 기본 및 보조 Geo 사이트가 두 개의 별도 위치, 각자의 개인용 IP 주소를 가진 가상 네트워크에서 위치한다고 가정합니다. 네트워크는 한 지리적 위치에서 모든 기계가 자신들의 개인용 IP 주소를 사용하여 서로 통신할 수 있도록 구성되어 있습니다. 제공된 IP 주소는 예시이며, 배포의 네트워크 토폴로지에 따라 다를 수 있습니다.

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

참고: 기본 및 보조 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'] = '<사이트_이름_여기에>'
      
   ##
   ## 자동 마이그레이션 비활성화
   ##
   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 기본 사이트의 읽기 전용 복제본입니다.
• 각 Geo 보조 사이트에 대해 “Geo 추적 데이터베이스”라는 추가 PostgreSQL 데이터베이스가 있으며, 이는 다양한 자원의 복제 및 검증 상태를 추적합니다.
• 추가적으로 GitLab 서비스 geo-logcursor가 있습니다.

이에 따라 이 멀티 노드 컴포넌트들을 일일이 설정하고 일반 멀티 노드 설정으로부터의 이탈을 포함합니다. 그러나 Geo 보조 사이트로 사용하기 위해 수정되기 전에 새로운 GitLab 사이트를 세팅하고, 작동 중인 GitLab 사이트인지 확인하는 것이 좋습니다. 이렇게 하면 Geo 설정 문제와 무관한 다른 멀티 노드 구성 문제와 분리될 수 있습니다.

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

다음 서비스를 구성하세요. 다시 말씀드리지만, 이를 위해 멀티 노드가 아닌 Geo 멀티 노드 문서를 사용하세요.

• GitLab을 위한 Redis 구성을 위한 여러 노드 설정.
• Gitaly은 Geo 기본 사이트에서 동기화된 데이터를 저장합니다.

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

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

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

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

1. GitLab 애플리케이션이 추적 데이터베이스에 접근하는 데 사용하는 데이터베이스 사용자의 원하는 패스워드에 대한 MD5 해시를 생성합니다:

   해당 해시에는 (기본값으로 gitlab_geo)가 포함됩니다.

   gitlab-ctl pg-password-md5 gitlab_geo
   # 패스워드 입력: <여기에_원하는_추적_db_패스워드_입력>
   # 패스워드 다시 입력: <여기에_원하는_추적_db_패스워드_입력>
   # fca0b89a972d69f00eb3ec98a5838484
   

   다음 단계에서 <tracking_database_password_md5_hash>에 이 해시를 입력하세요.

2. Geo 추적 데이터베이스를 실행할 의도된 머신에 다음을 /etc/gitlab/gitlab.rb에 추가합니다:

   ```ruby ## ## Geo 보조 추적 데이터베이스 활성화 ## geo_postgresql[‘enable’] = true geo_postgresql[‘listen_address’] = ‘<이_호스트의_ip_주소>' geo_postgresql['sql_user_password'] = ''이_호스트의_ip_주소>

   #

   복제 데이터베이스로의 PostgreSQL 연결 구성

   #

   geo_postgresql[‘md5_auth_cidr_addresses’] = [‘<복제_데이터베이스_ip>/32'] gitlab_rails['db_host'] = '<복제_데이터베이스_ip>'복제_데이터베이스_ip>복제_데이터베이스_ip>

   변경 사항이 적용되도록 GitLab을 재구성합니다.

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

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

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

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

추가 지리적 위치 사이트의 읽기 복제 데이터베이스에서 스트리밍 복제가 활성화되면 gitlab-rake db:migrate:status:geo와 같은 명령이 추가 위치 사이트의 구성이 완료될 때까지 실패합니다. 특히 Geo 구성 - 단계 3. 추가 위치 사이트 추가로 이동하여 완료하십시오.

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

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

참고 아키텍처를 따라 GitLab Rails 애플리케이션 노드를 구성하고, 다음 수정 사항을 수행합니다.

1. Geo secondary 사이트의 각 애플리케이션 노드의 /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 다이제스트'를 설정한 경우, 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 secondary 사이트의 로드 밸런서 설정

위의 최소 아키텍처 다이어그램에서 각 지리적 위치에 로드 밸런서가 표시되어 있어 애플리케이션 노드로 트래픽을 라우팅합니다.

자세한 정보는 다중 노드용 GitLab 로드 밸런서를 참조하십시오.

단계 6: Geo secondary 사이트의 백엔드 애플리케이션 노드 구성

위의 최소 아키텍처 다이어그램에서 모든 애플리케이션 서비스가 동일한 기계에서 실행되는 것으로 표시됩니다. 그러나 여러 노드를 위해서는 모든 서비스가 별도로 실행되는 것이 강력히 권장됩니다.

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

1. Geo secondary 사이트의 각 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['enable'] = true로 노드를 구성하여 geo-logcursor 서비스만 실행하도록 하고, sidekiq['enable'] = false로 Sidekiq를 비활성화할 수 있습니다.

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

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

애플리케이션에 주 사이트 및 보조 사이트를 설정하려면 GitLab 구성을 수행하십시오.