두 개의 단일 노드 사이트를 위한 Geo 설정 (외부 PostgreSQL 서비스 사용)

Tier: Premium, Ultimate
Offering: Self-managed

다음 가이드는 두 개의 리눅스 패키지 인스턴스 및 RDS, Azure Database 또는 Google Cloud SQL과 같은 외부 PostgreSQL 데이터베이스를 사용하여 두 개의 단일 노드 사이트에 대한 GitLab Geo를 배포하는 방법에 대해 간결한 지침을 제공합니다.

전제 조건:

  • 최소 두 개의 독립적으로 작동하는 GitLab 사이트를 보유하고 있어야 합니다. 사이트를 생성하려면 GitLab 참조 아키텍처 문서를 참조하세요.
    • 하나의 GitLab 사이트는 Geo 기본 사이트로 사용됩니다. 각 Geo 사이트에 대해 다른 참조 아키텍처 크기를 사용할 수 있습니다. 작동하는 GitLab 인스턴스가 이미 있는 경우 이를 기본 사이트로 사용할 수 있습니다.
    • 두 번째 GitLab 사이트는 Geo 보조 사이트로 사용됩니다. Geo는 여러 보조 사이트를 지원합니다.
  • Geo 기본 사이트에는 적어도 GitLab Premium 라이선스가 있어야 합니다. 모든 사이트에 대해 라이선스가 하나만 필요합니다.
  • 모든 사이트가 Geo 실행 요구 사항을 충족하는지 확인하세요.

리눅스 패키지(Omnibus)용 Geo 설정

전제 조건:

  • PostgreSQL 12 이상을 사용합니다. 이에는 pg_basebackup 도구가 포함되어 있어야 합니다.

기본 사이트 구성

  1. GitLab 기본 사이트에 SSH를 하고 루트로 로그인합니다: 

    sudo -i

  2. /etc/gitlab/gitlab.rb에 고유한 Geo 사이트 이름을 추가합니다: 

    ##
## Geo 사이트의 고유 식별자. 자세한 내용은 다음을 참조하세요.
## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
##
gitlab_rails['geo_node_name'] = '<site_name_here>'

  3. 변경 사항을 적용하려면 기본 사이트를 다시 구성합니다: 

    gitlab-ctl reconfigure

  4. 사이트를 기본 Geo 사이트로 정의합니다: 

    gitlab-ctl set-geo-primary-node

    이 명령은 /etc/gitlab/gitlab.rb에 정의된 external_url을 사용합니다.

외부 데이터베이스 구성

외부 데이터베이스를 설정하는 경우 다음 중 하나를 수행할 수 있습니다.

  • 직접 스트리밍 복제(예: Amazon RDS 또는 리눅스 패키지가 관리하지 않는 베어 메탈)를 설정합니다.
  • Linux 패키지 설치를 매뉴얼으로 구성합니다.

클라우드 공급 업체의 도구를 활용하여 기본 데이터베이스 복제

예를 들어 RDS를 사용하는 AWS EC2에 기본 사이트를 설치했다고 가정합니다. 이제 다른 지역에 읽기 전용 복제본을 만들고 복제 프로세스를 AWS에서 관리합니다. Network ACL(Access Control List), Subnet 및 Security Group을 필요에 맞게 설정하여 보조 레일 노드가 데이터베이스에 액세스할 수 있도록 해야 합니다.

다음 지침은 일반적인 클라우드 공급 업체에서 읽기 전용 복제본을 만드는 방법에 대해 설명합니다:

읽기 전용 복제본이 설정되면 보조 사이트를 구성하는 단계로 이동할 수 있습니다.

외부 읽기 전용 복제본을 사용하도록 보조 사이트 구성

Linux 패키지 설치에서는 geo_secondary_role가 다음 세 가지 주요 기능을 합니다.

  1. 복제 데이터베이스 구성.
  2. 추적 데이터베이스 구성.
  3. Geo Log Cursor를 활성화합니다.

외부 읽기 전용 복제본 데이터베이스에 대한 연결을 구성하려면 다음을 수행하세요:

  1. 보조 사이트의 각 레일, Sidekiq 및 Geo Log Cursor 노드에 SSH하고 루트로 로그인합니다: 

    sudo -i

  2. /etc/gitlab/gitlab.rb 파일을 편집하고 다음을 추가합니다. 

    ##
## Geo 보조 역할
## - Geo를 가능하게 하기 위해 종속되는 플래그를 자동으로 구성합니다.
##
roles ['geo_secondary_role']
   
# 이 값은 두 데이터베이스 모두에서 공유됩니다.
# 두 데이터베이스에 동일한 암호를 정의해야 합니다.
gitlab_rails['db_password'] = '<your_password_here>'
   
gitlab_rails['db_username'] = 'gitlab'
gitlab_rails['db_host'] = '<database_read_replica_host>'
   
# 번들된 Omnibus PostgreSQL을 비활성화합니다. 외부 PostgreSQL을 사용하므로
# 이를 비활성화해야 합니다.
postgresql['enable'] = false

  3. 파일을 저장하고 GitLab을 다시 구성합니다: 

    gitlab-ctl reconfigure

복제본 데이터베이스에 대한 연결에 연결 문제가 있는 경우 다음 명령을 사용하여 서버에서 TCP 연결을 확인할 수 있습니다. 

gitlab-rake gitlab:tcp_check[<replica FQDN>,5432]

이 단계에서 실패하는 경우 잘못된 IP 주소를 사용하거나 방화벽이 사이트와의 액세스를 방해하는 것일 수 있습니다. 공용 주소와 사설 주소 사이의 차이에 주목하여 IP 주소를 확인하고 방화벽이 적용되어 있다면 보조 사이트가 포트 5432에서 기본 사이트에 연결할 수 있도록 허용됐는지 확인하세요.

비밀 GitLab 값을 매뉴얼으로 복제

GitLab은 /etc/gitlab/gitlab-secrets.json에 여러 비밀 값을 저장합니다. 이 JSON 파일은 각 사이트 노드 전체에서 동일해야 합니다. 일부 보조 사이트에 대해 파일을 매뉴얼으로 복제해야 하지만 issue 3789에서 이 동작을 변경하는 제안이 있습니다.

  1. 기본 사이트의 레일 노드에 SSH하고 다음 명령을 실행합니다: 

    sudo cat /etc/gitlab/gitlab-secrets.json

    이 명령은 JSON 형식으로 표시된 복제해야 하는 비밀 값을 표시합니다.

  2. 보조 Geo 사이트의 각 노드에 SSH하고 루트로 로그인합니다: 

    sudo -i

  3. 기존 비밀의 백업을 만듭니다: 

    mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`

  4. 기본 사이트 레일 노드의 /etc/gitlab/gitlab-secrets.json을 각 보조 사이트 노드로 복사합니다. 또는 파일 내용을 노드 간에 복사하여 붙여넣을 수 있습니다: 

    sudo editor /etc/gitlab/gitlab-secrets.json
   
# 기본 사이트에서 실행한 `cat` 명령의 출력을 붙여넣습니다.
# 저장하고 종료합니다.

  5. 파일 권한이 올바른지 확인합니다: 

    chown root:root /etc/gitlab/gitlab-secrets.json
chmod 0600 /etc/gitlab/gitlab-secrets.json

  6. 변경 사항을 적용하려면 각 레일, Sidekiq 및 Gitaly 보조 사이트 노드를 다시 구성하세요: 

    gitlab-ctl reconfigure
gitlab-ctl restart

기본 사이트 SSH 호스트 키 매뉴얼 복제

  1. 보조 사이트의 각 노드에 SSH로 로그인하여 root 사용자로 로그인합니다. 

    sudo -i

  2. 기존 SSH 호스트 키를 백업합니다. 

    find /etc/ssh -iname 'ssh_host_*' -exec cp {} {}.backup.`date +%F` \;

  3. 기본 사이트에서 OpenSSH 호스트 키를 복사합니다.

    • SSH 트래픽을 제공하는 기본 사이트 노드 중 하나(일반적으로 주요 GitLab Rails 애플리케이션 노드)에서 root 사용자로 액세스할 수 있는 경우: 

      # 이 명령은 보조 사이트에서 실행하지만, 서버의 IP 또는 FQDN으로 `<primary_site_fqdn>`을 변경하세요
scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh

    • sudo 권한이 있는 사용자를 통해 액세스할 수 있는 경우: 

      # 기본 사이트의 노드에서 실행하세요:
sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
     
# 보조 사이트의 각 노드에서 실행하세요:
scp <user_with_sudo>@<primary_site_fqdn>:geo-host-key.tar.gz .
tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh

  4. 각 보조 사이트 노드에서 파일 권한이 올바른지 확인합니다. 

    chown root:root /etc/ssh/ssh_host_*_key*
chmod 0600 /etc/ssh/ssh_host_*_key

  5. 키 지문이 일치하는지 확인하기 위해 각 사이트의 기본 및 보조 노드에서 다음 명령을 실행합니다. 

    for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done

    두 노드에서 동일한 출력을 받아야 합니다.

  6. 기존 개인 키에 대한 올바른 공개 키를 확인합니다. 

    # 이 명령은 개인 키의 지문을 인쇄합니다:
for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
   
# 이 명령은 공개 키의 지문을 인쇄합니다:
for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done

    공개 키 및 개인 키 명령의 출력은 동일한 지문을 생성해야 합니다.

  7. 각 보조 사이트 노드에서 sshd를 재시작합니다. 

    # Debian 또는 Ubuntu 설치의 경우
sudo service ssh reload
   
# CentOS 설치의 경우
sudo service sshd reload

  8. SSH가 여전히 정상 작동하는지 확인하려면 새 터미널에서 GitLab 보조 서버에 SSH로 접속합니다. 연결할 수 없으면 올바른 권한이 있는지 확인하세요.

인증된 SSH 키를 빠르게 조회 설정

복제 프로세스가 완료되면 인증된 SSH 키를 빠르게 조회 설정을 구성해야 합니다.

note
인증은 주 사이트에서 처리됩니다. 보조 사이트에 사용자 정의 인증을 설정하지 마세요. 관리 영역에 액세스가 필요한 변경 사항은 주 사이트에서 수행해야 합니다. 보조 사이트는 읽기 전용 복사본이기 때문입니다.

보조 사이트 추가

  1. 보조 사이트의 각 Rails 및 Sidekiq 노드에 SSH로 로그인하여 root 사용자로 로그인합니다. 

    sudo -i

  2. /etc/gitlab/gitlab.rb을 편집하고 사이트에 대한 고유한 이름을 추가합니다. 

    ##
## Geo 사이트의 고유 식별자. 자세한 내용은 다음을 참조하세요.
## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
##
gitlab_rails['geo_node_name'] = '<secondary_site_name_here>'

    다음 단계를 위해 고유 이름을 저장하세요.

  3. 변경 사항을 적용하기 위해 보조 사이트의 각 Rails 및 Sidekiq 노드를 재구성하세요. 

    gitlab-ctl reconfigure
  4. 주 사이트 GitLab 인스턴스로 이동합니다:
    1. 왼쪽 사이드바에서 맨 아래에서 관리자 영역을 선택합니다.
    2. Geo > 사이트를 선택합니다.

    3. 사이트 추가를 선택합니다.

      보조 사이트 추가

    4. 이름란에 /etc/gitlab/gitlab.rb의 gitlab_rails['geo_node_name'] 값을 입력합니다. 두 값은 정확히 일치해야 합니다.
    5. 외부 URL란에 /etc/gitlab/gitlab.rb의 external_url 값을 입력합니다. 한 값이 /로 끝나도 괜찮지만, 그렇지 않으면 두 값은 정확히 일치해야 합니다.
    6. 선택 사항. 내부 URL(선택 사항)에 주 사이트의 내부 URL을 입력합니다.
    7. 선택 사항. 보조 사이트에서 복제해야 하는 그룹 또는 스토리지 샤드를 선택합니다. 모두 복제하려면 해당 필드를 비워 둡니다. 선택적 동기화를 참조하세요.
    8. 변경 사항 저장을 선택합니다.

  5. 보조 사이트의 각 Rails 및 Sidekiq 노드에 SSH로 로그인하여 서비스를 재시작합니다. 

    sudo gitlab-ctl restart

  6. 다음 명령을 실행하여 Geo 설정에 일반적인 문제가 있는지 확인하세요. 

    sudo gitlab-rake gitlab:geo:check

    확인 사항에 일치하지 않는 것이 있으면 문제 해결 문서를 참조하세요.

  7. 보조 사이트가 도달 가능한지 확인하려면 주 사이트의 Rails 또는 Sidekiq 서버에 SSH로 로그인하여 다음을 실행합니다. 

    sudo gitlab-rake gitlab:geo:check

    확인 사항에 일치하지 않는 것이 있으면 문제 해결 문서를 확인하세요.

보조 사이트가 Geo 관리 페이지에 추가되고 서비스를 다시 시작하면 사이트는 자동으로 주 사이트에서 누락된 데이터를 백필 프로세스라고 하는 프로세스로 복제하기 시작합니다.

이와 동시에 주 사이트는 각 보조 사이트에 변경 사항을 알리기 시작하여 보조 사이트가 즉시 이에 대해 조치할 수 있도록 합니다.

보조 사이트가 작동 중이고 접근 가능한지 확인하세요. 보조 사이트에서는 주 사이트에 사용된 것과 동일한 자격 증명으로 로그인할 수 있습니다.

Git의 HTTP/HTTPS 및 SSH를 통한 액세스 활성화

Geo는 HTTP/HTTPS를 통해 리포지터리를 동기화합니다(새 설치에 대해 기본적으로 활성화됨) 따라서 이 복제 방법이 활성화되어 있어야 합니다. 기존 사이트를 Geo로 변환하는 경우에는 복제 방법이 활성화되어 있는지 확인해야 합니다.

기본 사이트에서:

  1. 왼쪽 사이드바에서 가장 아래에서 관리 영역을 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 가시성 및 액세스 제어를 확장합니다.
  4. Git을 SSH로 사용하는 경우:
    1. 활성화된 Git 액세스 프로토콜이 SSH 및 HTTP(S)로 설정되어 있는지 확인합니다.
    2. 기본 및 보조 사이트에서 데이터베이스 내에서 승인된 SSH 키의 빠른 검색이 활성화됩니다.
  5. Git을 SSH로 사용하지 않는 경우 활성화된 Git 액세스 프로토콜을 HTTP(S)만으로 설정합니다.

보조 사이트의 올바른 작동 확인

기본 사이트에서 사용한 자격 증명으로 보조 사이트에 로그인할 수 있습니다.

로그인한 후에:

  1. 왼쪽 사이드바에서 가장 아래에서 관리 영역을 선택합니다.
  2. Geo > 사이트를 선택합니다.
  3. 사이트가 올바르게 보조 Geo 사이트로 식별되었는지 및 Geo가 활성화되었는지 확인합니다.

초기 복제에는 시간이 걸릴 수 있습니다. 기본 사이트의 브라우저에서 각 Geo 사이트의 동기화 프로세스를 모니터링할 수 있습니다.

Geo 대시보드

추적 데이터베이스 구성

note
이 단계는 외부 서버에 추적 데이터베이스를 설정하기를 원하는 경우에만 선택사항입니다.

보조 사이트는 후속 복제 이슈에서 자동으로 회복하기 위해 복제 상태를 추적하기 위해 별도의 PostgreSQL 설치를 사용합니다. Linux 패키지는 roles ['geo_secondary_role']가 설정되면 추적 데이터베이스를 자동으로 구성합니다. 이 데이터베이스를 Linux 패키지 설치 외부에서 실행하려면 다음 지침을 사용하세요.

클라우드 관리형 데이터베이스 서비스

추적 데이터베이스에 클라우드 관리형 서비스를 사용하는 경우, 추적 데이터베이스 사용자(기본값으로 gitlab_geo)에 추가 역할을 부여해야 할 수 있습니다:

서버에 확장을 설치하려면 인스톨 및 업그레이드 중에 추가 역할이 필요합니다. 대안으로, 확장이 매뉴얼으로 설치되었는지 확인하고 향후 GitLab 업그레이드 중에 발생할 수 있는 문제에 대해 읽어보세요.

note
Amazon RDS를 추적 데이터베이스로 사용하려면 보조 데이터베이스에 액세스할 수 있도록 하십시오. 안타깝게도, 동일한 보안 그룹을 할당하는 것만으로는 충분하지 않습니다. 외부 규칙이 RDS PostgreSQL 데이터베이스에는 적용되지 않기 때문에 추적 데이터베이스의 보조 보안 그룹에게 5432 포트에서 추적 데이터베이스로부터의 어떠한 TCP 트래픽도 허용하도록 명시적으로 추가해야 합니다.

추적 데이터베이스 생성

PostgreSQL 인스턴스에서 추적 데이터베이스를 생성 및 구성합니다:

  1. 데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정합니다.
  2. 원하는 비밀번호로 gitlab_geo 사용자를 설정하고, gitlabhq_geo_production 데이터베이스를 생성하고, 해당 사용자를 해당 데이터베이스의 소유자로 만듭니다. 이 설정에 대한 예제는 셀프 컴파일된 설치 문서에서 확인할 수 있습니다.

  3. 원격 관리되는 PostgreSQL 데이터베이스를 사용하지 않는 경우, 보조 사이트가 데이터베이스와 통신할 수 있도록 데이터베이스와 연관된 pg_hba.conf를 매뉴얼으로 변경합니다. 변경 사항이 적용되도록 PostgreSQL을 재시작하는 것을 잊지 마십시오: 

    ##
## Geo 추적 데이터베이스 역할
## - pg_hba.conf
##
host    all         all               <신뢰할 수 있는 추적 IP>/32      md5
host    all         all               <신뢰할 수 있는 보조 IP>/32     md5

GitLab 구성

GitLab을 이 데이터베이스를 사용하도록 구성합니다. 이러한 단계는 Linux 패키지 및 Docker 배포용입니다.

  1. GitLab 보조 서버에 SSH로 로그인한 후 root 사용자로 로그인합니다: 

    sudo -i

  2. PostgreSQL 인스턴스가 있는 기기의 연결 매개변수와 자격 증명을 포함하여 /etc/gitlab/gitlab.rb를 편집합니다: 

    geo_secondary['db_username'] = 'gitlab_geo'
geo_secondary['db_password'] = '<여기에 비밀번호 입력>'
   
geo_secondary['db_host'] = '<추적_데이터베이스_호스트>'
geo_secondary['db_port'] = <추적_데이터베이스_포트>      # 올바른 포트로 변경
geo_postgresql['enable'] = false     # 내부 관리형 인스턴스를 사용하지 않음

  3. 파일을 저장하고 GitLab을 다시 구성합니다: 

    gitlab-ctl reconfigure

데이터베이스 스키마 매뉴얼으로 설정하기(선택사항)

상기의 단계에서 reconfigure은 이러한 단계를 자동으로 처리합니다. 여기에 제공된 이러한 단계는 무언가가 잘못된 경우를 대비하여 제공됩니다.

  1. 이 작업은 데이터베이스 스키마를 생성합니다. 데이터베이스 사용자가 수퍼 사용자여야 합니다. 

    sudo gitlab-rake db:create:geo

  2. Rails 데이터베이스 마이그레이션(스키마 및 데이터 업데이트)도 reconfigure에 의해 수행됩니다. geo_secondary['auto_migrate'] = false으로 설정되었거나 스키마가 매뉴얼으로 생성된 경우에는 이 단계가 필요합니다: 

    sudo gitlab-rake db:migrate:geo

문제 해결

Geo 문제 해결을 참조하세요.