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

다중 노드를 위한 Geo

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

아키텍처 개요

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

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

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

참고: primary 및 secondary Geo 사이트는 반드시 HTTPS를 통해 서로 통신할 수 있어야 합니다.

다중 노드용 Redis 및 PostgreSQL

PostgreSQL 및 Redis를 설정하는 데 추가 복잡성이 포함되어 있기 때문에, 이 Geo multi-node 문서에서 다루지 않습니다.

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

• Geo multi-node database replication
• Redis multi-node documentation

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

사전 요구 사항: 독립적으로 작동하는 두 개의 GitLab 다중 노드 사이트

한 GitLab 사이트는 Geo primary 사이트로 사용됩니다. 이를 위해 GitLab 참조 아키텍처 문서 을 참조하세요. 각 Geo 사이트에 대해 다른 참조 아키텍처 크기를 사용할 수 있습니다. 이미 사용 중인 작동 중인 GitLab 인스턴스가 있는 경우, 이를 primary 사이트로 사용할 수 있습니다.

두 번째 GitLab 사이트는 Geo secondary 사이트로 사용됩니다. 다시, 이를 설정하기 위해 GitLab 참조 아키텍처 문서 을 참조하세요. 이를 로그인하여 테스트하는 것이 좋습니다. 다만, primary 사이트에서 복제하는 과정 중에 해당 데이터가 삭제되니 유의하세요.

GitLab 사이트를 Geo primary 사이트로 구성

다음 단계를 통해 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 데이터베이스와 각종 리소스의 복제 및 확인 상태를 추적하는 데 사용되는 데이터베이스가 있습니다. 또한, 추가적인 GitLab 서비스 geo-logcursor가 있습니다.

따라서 우리는 일반적인 다중 노드 설정과의 차이점을 포함하여 하나씩 다중 노드 구성 요소를 설정하고 있습니다. 그러나 Geo secondary 사이트로 사용하려면 먼저 Geo 설정과 관련 없는 다중 노드 구성 문제와 분리하기 위해 새로운 GitLab 사이트를 구성하는 것이 좋습니다. 이를 통해 작동 중인 GitLab 사이트임을 확인한 후 Geo secondary 사이트로 사용하도록 수정하는 것이 좋습니다. 이는 Geo 설정 문제와 관련 없는 다중 노드 구성 문제와 분리하는 데 도움이 됩니다.

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

다음 서비스를 구성하십시오. 다시 말하지만, Geo 멀티 노드에 대한 문서를 사용합니다.

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

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

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

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

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

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

   기본 값은 (gitlab_geo) 해시를 통합합니다.

   gitlab-ctl pg-password-md5 gitlab_geo
   # 암호 입력: <your_password_here>
   # 암호 확인: <your_password_here>
   # fca0b89a972d69f00eb3ec98a5838484
   

   이 해시를 다음 단계의 <tracking_database_password_md5_hash>에 채우는 데 사용합니다.

2. Geo 추적 데이터베이스를 실행할 호스트에서 /etc/gitlab/gitlab.rb에 다음을 추가합니다.

   ##
   ## Geo secondary 추적 데이터베이스 활성화
   ##
   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. Geo 사이트 추가가 완료될 때까지 실패합니다.

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

참고: 단일 노드 사이트를 위해 의도된 geo_secondary_role를 사용하지 마십시오.

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

참조 아키텍처를 따라 GitLab Rails 애플리케이션 노드를 구성한 다음 다음 수정 사항을 적용하십시오.

1. Geo secondary 사이트의 각 애플리케이션 노드의 /etc/gitlab/gitlab.rb에서 다음을 추가하십시오.

   ##
   ## GitLab 애플리케이션 서비스 활성화. application_role은 많은 서비스를 활성화합니다.
   ## `application_role`은 이미 이것을 활성화합니다. Rails에 의존하는 개별 서비스를 선택적으로 활성화하는 경우에만 필요합니다
   ##
   roles ['application_role']
   
   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에서 관리되지 않는 사용자 사용 시 권장합니다. 클러스터의 노드 간에 권한 문제를 피하기 위해 아래와 같이 UIDs 및 GIDs를 지정해야 합니다.
   ##
   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 digest of secret'를 설정했다면, gitlab_rails['db_password']와 geo_secondary['db_password']에는 평문 암호가 포함되어 있음을 기억하세요. 이것은 레일스 노드가 데이터베이스에 연결하게 하는 데 사용됩니다.

현재 노드의 IP가 읽기 복제 데이터베이스의 postgresql['md5_auth_cidr_addresses'] 설정에 나열되어 있는지 확인하여 이 노드의 레일스가 PostgreSQL에 연결할 수 있게 하십시오.

이러한 변경 내용을 적용하고, 변경 사항이 적용되도록 GitLab을 재구성하십시오.

설치된 프론트엔드 어플리케이션 노드에서 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로 관리되지 않는 사용자를 사용하는 경우, 권한 문제를 피하기 위해 아래처럼 UIDs 및 GIDs를 지정하고 
    ## 클러스터 내 노드간에 일치하도록 확인해야 합니다.
    ##
    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: 비밀 정보 복사 및 애플리케이션에 secondary 사이트 추가

1. GitLab 구성을 참조하여 primary 및 secondary 사이트를 설정하세요.