이 문서는 다중 노드 구성에서 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 보조 사이트마다 "Geo 추적 데이터베이스"라는 PostgreSQL 데이터베이스가 추가로 존재하며, 여러 리소스의 복제 및 검증 상태를 추적합니다.
• GitLab 서비스 geo-logcursor가 추가로 있습니다.

따라서 다중 노드 구성 요소를 하나씩 설정하면서 일반적인 다중 노드 설정과 다른 점을 함께 설명합니다. 다만 Geo 설정의 일부가 아닌 것처럼 완전히 새로운 GitLab 사이트를 먼저 구성하기를 강력히 권장합니다. 이렇게 하면 해당 사이트가 정상적으로 동작하는 GitLab 사이트인지 확인할 수 있고, 그다음에 Geo 보조 사이트로 쓰도록 수정하면 됩니다. 이 방식은 Geo 설정 문제와 관련 없는 다중 노드 구성 문제를 구분하는 데 도움이 됩니다.

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

다음 서비스를 구성합니다. 이때도 Geo가 아닌 다중 노드 문서를 사용합니다:

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

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
   

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

이 변경을 적용한 뒤 변경 사항이 반영되도록 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를 설정하고 sidekiq['enable'] = false로 Sidekiq를 비활성화하면 geo-logcursor 서비스만 실행하는 노드를 구성할 수 있습니다.

   이 노드들은 로드 밸런서에 연결할 필요가 없습니다.

7단계: 시크릿 복사 및 애플리케이션에 보조 사이트 추가#

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