여러 노드용 Geo
Offering: Self-managed
이 문서는 멀티 노드 구성에서 Geo를 실행하기 위한 최소한의 참조 아키텍처를 설명합니다. 만약 여러분의 멀티 노드 설정이 여기서 설명된 것과 다르다면, 이 지침을 여러분의 요구에 맞게 적응시키는 것이 가능합니다.
아키텍처 개요
위의 위상은 기본 및 보조 Geo 사이트가 두 개의 별도 위치에 위치하고 있는 것을 전제로 합니다. 각자의 사설 IP 주소로 자체 가상 네트워크에 위치하고 있습니다. 네트워크는 한 지리적 위치의 모든 장비가 그들의 사설 IP 주소를 사용하여 서로 통신할 수 있도록 구성되어 있습니다. 여기 제공된 IP 주소는 예시이며, 배포의 네트워크 위상에 따라 다를 수 있습니다.
두 Geo 사이트에 대한 유일한 외부 액세스 방법은 위 예에서와 같이 HTTPS를 통한 gitlab.us.example.com
및 gitlab.eu.example.com
입니다.
멀티 노드용 Redis 및 PostgreSQL
PostgreSQL 및 Redis의 추가 복잡성으로 인해, 이러한 Geo 멀티 노드 문서에 포함되어 있지 않습니다.
리눅스 패키지를 사용하여 멀티 노드 PostgreSQL 클러스터 및 Redis 클러스터를 설정하는 자세한 정보는 다음에서 확인할 수 있습니다. - Geo 멀티 노드 데이터베이스 복제 - Redis 멀티 노드 문서
사전 요구 사항: 독립적으로 작동하는 두 개의 GitLab 멀티 노드 사이트
한 개의 GitLab 사이트는 Geo 기본 사이트로 사용됩니다. 이를 설정하기 위해 GitLab 참조 아키텍처 문서를 사용하십시오. 각 Geo 사이트에 대해 다양한 참조 아키텍처 크기를 사용할 수 있습니다. 이미 사용 중인 작동 중인 GitLab 인스턴스가 있는 경우, 이를 기본 사이트로 사용할 수 있습니다.
두 번째 GitLab 사이트는 Geo 보조 사이트로 사용됩니다. 다시, GitLab 참조 아키텍처 문서를 사용하여 이를 설정하십시오. 로그인하여 테스트 하는 것이 좋습니다. 그러나 기본 사이트로부터 복제 프로세스의 일부로 데이터가 지워진다는 것을 염두에 두십시오.
GitLab 사이트를 Geo 기본 사이트로 구성
다음 단계에서 GitLab 사이트를 Geo 기본 사이트로 사용할 수 있도록 설정합니다.
단계 1: 기본 프론트엔드 노드 구성
geo_primary_role
을 사용하지 마십시오.-
/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: 사이트를 기본 사이트로 정의
다음 명령을 프론트엔드 노드 중 하나에서 실행하십시오:
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 구성. - Geo 기본 사이트에서 동기화된 데이터를 저장하는 Gitaly.
단계 2: Geo 보조 사이트에서 Geo 추적 데이터베이스 구성
Geo 추적 데이터베이스는 멀티 노드 PostgreSQL 클러스터에서 실행될 수 없으며, 추적 PostgreSQL 데이터베이스용 Patroni 클러스터 구성을 참조하십시오.
다음과 같이 Geo 추적 데이터베이스를 단일 노드에서 실행할 수 있습니다:
-
GitLab 응용 프로그램이 추적 데이터베이스에 액세스하는 데 사용되는 데이터베이스 사용자의 원하는 암호의 MD5 해시를 생성하십시오:
해당 해시는 사용자명 (
gitlab_geo
가 기본)이 해시에 포함됩니다.gitlab-ctl pg-password-md5 gitlab_geo # 암호 입력: <your_password_here> # 암호 확인: <your_password_here> # fca0b89a972d69f00eb3ec98a5838484
다음 단계에서
<tracking_database_password_md5_hash>
를 채우기 위해 이 해시를 사용하십시오. -
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 애플리케이션 노드를 구성한 후 다음 수정 사항을 적용하십시오.
-
Geo 보조 사이트의 각 애플리케이션 노드의
/etc/gitlab/gitlab.rb
를 편집하고 다음을 추가하십시오:## ## GitLab 애플리케이션 서비스를 활성화합니다. application_role은 많은 서비스를 활성화합니다. ## 또는 수평 확장 및 관심 분리를 위해 서로 다른 노드에서 특정 서비스를 선택적으로 활성화 또는 비활성화할 수 있습니다. ## roles ['application_role'] ## `application_role`은 이미 이것을 활성화합니다. Rails에 의존하는 개별 서비스를 선택적으로 활성화하는 경우에만 이 줄이 필요합니다. 예: `puma`, `sidekiq`, `geo-logcursor` 등 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['sql_user_password'] = '비밀의 md5 다이제스트'
를 설정한 경우, gitlab_rails['db_password']
와 geo_secondary['db_password']
에는 암호가 평문으로 포함되어 있다는 사실을 기억하십시오. 이는 Rail 노드가 데이터베이스에 연결할 수 있도록 해주는 데 사용됩니다.postgresql['md5_auth_cidr_addresses']
설정에 나열되어 있는지 확인하여 이 노드의 Rail이 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
로 Sidekiq을 비활성화하는 것과 유사하게 geo-logcursor
서비스만 실행하도록 구성할 수 있습니다.
이러한 노드는 부하 분산기에 연결할 필요가 없습니다.
단계 7: 시크릿 복사 및 애플리케이션에 보조 사이트 추가
- GitLab 구성을 설정하여 주 및 보조 사이트를 설정합니다.