• 아키텍처 개요
• 여러 노드를 위한 Redis 및 PostgreSQL
• 사전 준비 사항: 두 개의 독립적으로 작동하는 GitLab 멀티-노드 사이트
• Geo 주(primary) 사이트로 GitLab 사이트 구성
  • 단계 1: 주(primary) 프론트엔드 노드 구성
  • 단계 2: 사이트를 주(primary) 사이트로 정의합니다
• 다른 GitLab 사이트를 Geo 보조(secondary) 사이트로 구성
  • 단계 1: Geo 보조(secondary) 사이트에서 Redis 및 Gitaly 서비스 구성
  • 단계 2: Geo 보조(secondary) 사이트에서 Geo 트래킹 데이터베이스 구성
  • 단계 3: PostgreSQL 스트리밍 복제 구성
  • 단계 4: Geo 보조 사이트의 프론트엔드 애플리케이션 노드 구성
  • 단계 5: Geo 보조 사이트를 위한 로드 밸런서 설정
  • 단계 6: Geo 보조 사이트의 백엔드 애플리케이션 노드 구성
  • 7단계: 비밀 정보 복사 및 애플리케이션에 보조 사이트 추가

여러 노드를 위한 Geo

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

아키텍처 개요

다이어그램 소스 - GitLab 내부 근로자 전용

위의 토폴로지는 주(primary) 및 보조(secondary) Geo 사이트가 각각의 가상 네트워크에 위치하여 사설 IP 주소를 사용하는 두 개의 별도 위치를 가정합니다. 주어진 IP 주소는 예시로 실제 네트워크 토폴로지에 따라 달라질 수 있습니다.

두 Geo 사이트에 대한 유일한 외부 접속 방법은 위의 예시에서처럼 HTTPS를 통해 gitlab.us.example.com 및 gitlab.eu.example.com에 접속하는 것입니다.

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

여러 노드를 위한 Redis 및 PostgreSQL

PostgreSQL 및 Redis를 이 구성을 위해 설정하는 데 추가 복잡성이 있기 때문에, 이 Geo 멀티-노드 설명서에서는 다루지 않고 있습니다.

Linux 패키지를 사용하여 멀티-노드 PostgreSQL 클러스터 및 Redis 클러스터를 설정하는 자세한 정보는 다음을 참조하세요:

• 멀티-노드 데이터베이스 복제
• Redis 멀티-노드 설명서

참고: PostgreSQL 및 Redis를 클라우드 호스팅 서비스로 사용하는 것도 가능하지만, 이 문서의 범위를 벗어납니다.

사전 준비 사항: 두 개의 독립적으로 작동하는 GitLab 멀티-노드 사이트

하나의 GitLab 사이트는 Geo 주(primary) 사이트로 사용됩니다. 이를 설정하려면 GitLab 참조 아키텍처 문서를 참고하세요. 각 Geo 사이트에 대해 다른 참조 아키텍처 크기를 사용할 수 있습니다. 이미 사용 중인 작동 중인 GitLab 인스턴스가 있는 경우 해당 인스턴스를 주(primary) 사이트로 사용할 수도 있습니다.

두 번째 GitLab 사이트는 Geo 보조(secondary) 사이트로 사용됩니다. 다시 한번, GitLab 참조 아키텍처 문서를 참고하세요. 로그인하여 테스트하는 것이 좋습니다. 그러나 주(primary) 사이트에서 복제하는 과정의 일환으로 해당 데이터가 삭제되므로 이 점을 주의하세요.

Geo 주(primary) 사이트로 GitLab 사이트 구성

다음 단계는 GitLab 사이트를 Geo 주(primary) 사이트로 사용할 수 있도록 설정합니다.

단계 1: 주(primary) 프론트엔드 노드 구성

참고: 단일 노드 사이트에 대해 의도된 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: 사이트를 주(primary) 사이트로 정의합니다

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

   sudo gitlab-ctl set-geo-primary-node
   

참고: 일반적인 GitLab 멀티-노드 설치 중에 이미 PostgreSQL 및 Redis가 비활성화되어 있어야 합니다. 또한 애플리케이션 노드에서 백엔드 노드의 서비스로의 연결이 설정되어 있어야 합니다. PostgreSQL에 대한 멀티-노드 구성 설명서 여기, Redis에 대한 설명서 여기를 참조하세요.

다른 GitLab 사이트를 Geo 보조(secondary) 사이트로 구성

보조(secondary) 사이트는 기본 PostgreSQL 데이터베이스가 Geo 주(primary) 사이트의 읽기 전용 복제본이고, 각 Geo 보조(secondary) 사이트에는 “Geo 트래킹 데이터베이스”라는 추가 PostgreSQL 데이터베이스가 있으며, 이 데이터베이스는 다양한 리소스의 복제 및 검증 상태를 추적합니다. 또한 Geo-logcursor라는 추가 GitLab 서비스가 있습니다.

따라서 우리는 멀티-노드 구성 및 일반적인 멀티-노드 구성에서의 차이점을 포함하여 순차적으로 멀티-노드 구성 요소를 설정하게 됩니다. 그러나 우리는 먼저 새로운 GitLab 사이트를 Geo 설정의 일부가 아닌 것처럼 구성하는 것을 강력히 권장합니다. 이로써 작동하는 GitLab 사이트인지 확인이 가능합니다. 그리고 그 후에야 Geo 보조(secondary) 사이트로 사용하도록 수정해야 합니다. 이를 통해 Geo 설정 문제를 관련 없는 멀티-노드 구성 문제와 구분할 수 있습니다.

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

다음 서비스를 다음 문서를 참고하여 구성하세요:

• GitLab를 위한 Redis 구성 - 여러 노드로 구성
• 데이터를 동기화하는 Gitaly에 대해서는 여기를 참고하세요.

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

단계 2: Geo 보조(secondary) 사이트에서 Geo 트래킹 데이터베이스 구성

Geo 트래킹 데이터베이스를 멀티-노드 PostgreSQL 클러스터에서 실행할 수 없으므로, 패트로니 클러스터를 위한 트래킹 PostgreSQL 데이터베이스 구성를 참고하세요.

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

1. GitLab 애플리케이션이 트래킹 데이터베이스에 액세스하는 데 사용하는 데이터베이스 사용자의 비밀번호에 대한 MD5 해시를 생성하세요:

   사용자명(gitlab_geo가 기본값)이 해시에 통합됩니다.

   gitlab-ctl pg-password-md5 gitlab_geo
   # 비밀번호 입력: <여기에_트래킹_데이터베이스_비밀번호_입력>
   # 비밀번호 재입력: <여기에_트래킹_데이터베이스_비밀번호_입력>
   # fca0b89a972d69f00eb3ec98a5838484
   

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

2. Geo 트래킹 데이터베이스를 실행할 호스트의 머신에서 다음을 /etc/gitlab/gitlab.rb에 추가하세요:

   ##
   ## Geo 보조(secondary) 트래킹 데이터베이스 사용 설정
   ##
   geo_postgresql['enable'] = true
   geo_postgresql['listen_address'] = '<이_호스트의_IP_주소>'
   geo_postgresql['sql_user_password'] = '<tracking_database_password_md5_hash>'
   
   ##
   ## 복제 데이터베이스에 대한 PostgreSQL 연결 구성
   ##
   geo_postgresql['md5_auth_cidr_addresses'] = ['<복제_데이터베이스_IP>/32']
   gitlab_rails['db_host'] = '<복제_데이터베이스_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
   

참고: 리눅스 패키지를 사용하여 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 보조 사이트를 위한 로드 밸런서 설정

위의 최소한 아키텍처 다이어그램에는 각 지리적 위치에 로드 밸런서가 있어 응용 프로그램 노드로 트래픽을 라우팅하는 것이 표시됩니다.

자세한 내용은 다중 노드로 GitLab의 로드 밸런서 구성을 참조하십시오.

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

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

예를 들어, Sidekiq 노드는 프론트엔드 애플리케이션 노드와 유사하게 구성되어 sidekiq 서비스만 실행되도록 변경할 수 있습니다:

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['enable'] = true 및 sidekiq['enable'] = false로 설정하여 이러한 노드를 로드 밸런서에 연결할 필요는 없습니다.

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

1. GitLab 구성을 사용하여 주 사이트(primary) 및 보조 사이트(secondary)를 설정합니다.