이 문서는 다중 노드 구성에서 Geo를 실행하기 위한 최소 참조 아키텍처를 설명합니다. 다중 노드 설정이 여기에 설명된 것과 다른 경우 이러한 지침을 필요에 맞게 조정할 수 있습니다.

이 가이드는 여러 애플리케이션 노드(Sidekiq 또는 GitLab Rails)를 사용하는 설치에 적용됩니다. 외부 PostgreSQL이 있는 단일 노드 설치의 경우 두 단일 노드 사이트를 위한 Geo 설정(외부 PostgreSQL 서비스 포함)을 따르고 다른 외부 서비스를 사용하는 경우 구성을 조정합니다.

아키텍처 개요#

다이어그램 소스 - GitLab 팀원만 해당

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

이전 예제에서 두 Geo 사이트에 외부적으로 액세스하는 유일한 방법은 gitlab.us.example.com 및 gitlab.eu.example.com에서 HTTPS를 통해서입니다.

다중 노드를 위한 Redis 및 PostgreSQL#

다중 노드를 위한 PostgreSQL 및 Redis 설정의 추가적인 복잡성으로 인해 이 Geo 다중 노드 문서에서는 다루지 않습니다.

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

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

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

하나의 GitLab 사이트가 Geo 기본 사이트로 사용됩니다. 이를 설정하려면 GitLab 참조 아키텍처 문서를 사용합니다. 각 Geo 사이트에 다른 참조 아키텍처 크기를 사용할 수 있습니다. 이미 사용 중인 작동하는 GitLab 인스턴스가 있다면 기본 사이트로 사용할 수 있습니다.

두 번째 GitLab 사이트가 Geo 보조 사이트로 사용됩니다. 다시 GitLab 참조 아키텍처 문서를 사용하여 설정합니다. 로그인하여 테스트하는 것이 좋습니다. 그러나 기본 사이트에서 복제하는 과정의 일부로 데이터가 지워진다는 점을 알아두세요.

GitLab 사이트를 Geo 기본 사이트로 구성#

다음 단계는 GitLab 사이트가 Geo 기본 사이트로 사용될 수 있도록 합니다.

1단계: 기본 프론트엔드 노드 구성#

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

   ##
   ## The unique identifier for the Geo site. See
   ## https://docs.gitlab.com/administration/geo_sites/#common-settings
   ##
   gitlab_rails['geo_node_name'] = '<site_name_here>'
   
   ##
   ## Disable automatic migrations
   ##
   gitlab_rails['auto_migrate'] = false
   

이러한 변경 사항을 적용한 후 변경 사항이 효과를 발휘하도록 GitLab을 재구성합니다.

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

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

   sudo gitlab-ctl set-geo-primary-node
   

다른 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.

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

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

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

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

   사용자 이름(기본적으로 gitlab_geo)이 해시에 포함됩니다.

   gitlab-ctl pg-password-md5 gitlab_geo
   # Enter password: <your_tracking_db_password_here>
   # Confirm password: <your_tracking_db_password_here>
   # fca0b89a972d69f00eb3ec98a5838484
   

   이 해시를 사용하여 다음 단계의 <tracking_database_password_md5_hash>를 채웁니다.

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

   ##
   ## Enable the Geo secondary tracking database
   ##
   geo_postgresql['enable'] = true
   geo_postgresql['listen_address'] = '<ip_address_of_this_host>'
   geo_postgresql['sql_user_password'] = '<tracking_database_password_md5_hash>'
   
   ##
   ## Configure PostgreSQL connection to the replica database
   ##
   geo_postgresql['md5_auth_cidr_addresses'] = ['<replica_database_ip>/32']
   gitlab_rails['db_host'] = '<replica_database_ip>'
   
   # Prevent reconfigure from attempting to run migrations on the replica database
   gitlab_rails['auto_migrate'] = false
   

3. GitLab을 업그레이드할 때 의도치 않은 다운타임을 피하기 위해 자동 PostgreSQL 업그레이드를 옵트아웃합니다. Geo와 함께 PostgreSQL을 업그레이드할 때의 알려진 주의 사항에 주의하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드를 의식적으로 계획하고 실행해야 합니다. 결과적으로 앞으로는 PostgreSQL 업그레이드가 정기적인 유지 보수 활동의 일부가 되도록 합니다.

이러한 변경 사항을 적용한 후 변경 사항이 효과를 발휘하도록 GitLab을 재구성합니다.

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

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

Geo 데이터베이스 복제 지침을 따릅니다.

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

스트리밍 복제를 활성화한 후 애플리케이션에서 보조 사이트 구성이 완료될 때까지, 특히 Geo 구성 - 3단계. 보조 사이트 추가까지 gitlab-rake db:migrate:status:geo가 실패합니다.

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

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

참조 아키텍처에 설명된 관련 단계를 따라 GitLab Rails 애플리케이션 노드를 구성한 다음 다음과 같이 수정합니다:

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

   ##
   ## Enable GitLab application services. The application_role enables many services.
   ## Alternatively, you can choose to enable or disable specific services on
   ## different nodes to aid in horizontal scaling and separation of concerns.
   ##
   roles ['application_role']
   
   ## `application_role` already enables this. You only need this line if
   ## you selectively enable individual services that depend on Rails, like
   ## `puma`, `sidekiq`, `geo-logcursor`, and so on.
   gitlab_rails['enable'] = true
   
   ##
   ## Enable Geo Log Cursor service
   ##
   geo_logcursor['enable'] = true
   
   ##
   ## The unique identifier for the Geo site. See
   ## https://docs.gitlab.com/administration/geo_sites/#common-settings
   ##
   gitlab_rails['geo_node_name'] = '<site_name_here>'
   
   ##
   ## Disable automatic migrations
   ##
   gitlab_rails['auto_migrate'] = false
   
   ##
   ## Configure the connection to the tracking database
   ##
   geo_secondary['enable'] = true
   geo_secondary['db_host'] = '<geo_tracking_db_host>'
   geo_secondary['db_password'] = '<geo_tracking_db_password>'
   
   ##
   ## Configure connection to the streaming replica database, if you haven't
   ## already
   ##
   gitlab_rails['db_host'] = '<replica_database_host>'
   gitlab_rails['db_password'] = '<replica_database_password>'
   
   ##
   ## Configure connection to Redis, if you haven't already
   ##
   gitlab_rails['redis_host'] = '<redis_host>'
   gitlab_rails['redis_password'] = '<redis_password>'
   
   ##
   ## If you are using custom users not managed by Omnibus, you need to specify
   ## UIDs and GIDs like below, and ensure they match between nodes in a
   ## cluster to avoid permissions issues
   ##
   user['uid'] = 9000
   user['gid'] = 9000
   web_server['uid'] = 9001
   web_server['gid'] = 9001
   registry['uid'] = 9002
   registry['gid'] = 9002
   

이 노드의 IP가 Rails가 이 노드에서 PostgreSQL에 연결할 수 있도록 읽기 복제본 데이터베이스의 postgresql['md5_auth_cidr_addresses'] 설정에 나열되어 있는지 확인합니다.

이러한 변경 사항을 적용한 후 변경 사항이 효과를 발휘하도록 GitLab을 재구성합니다.

아키텍처 개요 토폴로지에서 "프론트엔드" 노드에서 다음 GitLab 서비스가 활성화됩니다:

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

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

5단계: Geo 보조 사이트를 위한 로드 밸런서 설정#

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

자세한 내용은 여러 노드가 있는 GitLab을 위한 로드 밸런서를 참조하세요.

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

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

예를 들어 Sidekiq 노드는 이전에 문서화된 프론트엔드 애플리케이션 노드와 유사하게 구성되며 sidekiq 서비스만 실행하도록 일부 변경이 있습니다:

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

   ##
   ## Enable the Sidekiq service
   ##
   sidekiq['enable'] = true
   gitlab_rails['enable'] = true
   
   ##
   ## The unique identifier for the Geo site. See
   ## https://docs.gitlab.com/administration/geo_sites/#common-settings
   ##
   gitlab_rails['geo_node_name'] = '<site_name_here>'
   
   ##
   ## Disable automatic migrations
   ##
   gitlab_rails['auto_migrate'] = false
   
   ##
   ## Configure the connection to the tracking database
   ##
   geo_secondary['enable'] = true
   geo_secondary['db_host'] = '<geo_tracking_db_host>'
   geo_secondary['db_password'] = '<geo_tracking_db_password>'
   
   ##
   ## Configure connection to the streaming replica database, if you haven't
   ## already
   ##
   gitlab_rails['db_host'] = '<replica_database_host>'
   gitlab_rails['db_password'] = '<replica_database_password>'
   
   ##
   ## Configure connection to Redis, if you haven't already
   ##
   gitlab_rails['redis_host'] = '<redis_host>'
   gitlab_rails['redis_password'] = '<redis_password>'
   
   ##
   ## If you are using custom users not managed by Omnibus, you need to specify
   ## UIDs and GIDs like below, and ensure they match between nodes in a
   ## cluster to avoid permissions issues
   ##
   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단계: 비밀 복사 및 애플리케이션에서 보조 사이트 추가#

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