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

Tier: 프리미엄, 얼티메이트 Offering: Self-managed

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

전제 조건:

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

리눅스 패키지(Omnibus)를 위한 Geo 설정

전제 조건:

기본 사이트 구성

  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'] = '<여기에_사이트_이름_입력>'

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

    gitlab-ctl reconfigure

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

    gitlab-ctl set-geo-primary-node

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

복제할 외부 데이터베이스 구성

외부 데이터베이스를 설정하는 방법은 다음과 같습니다:

  • 직접 스트리밍 복제(예: Amazon RDS 또는 리눅스 패키지에서 관리되지 않는 베어 메탈)를 설정합니다.
  • 다음과 같이 리눅스 패키지 설치를 수동으로 구성합니다.

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

AWS EC2에서 설정한 기본 사이트가 RDS를 사용하는 경우. 이제 다른 지역에 읽기 전용 레플리카를 생성하고 복제 프로세스는 AWS에서 관리합니다. 필요에 따라 네트워크 ACL(액세스 제어 목록), 서브넷 및 보안 그룹을 설정하여 보조 Rails 노드가 데이터베이스에 액세스할 수 있도록 합니다.

다음 지침은 일반적인 클라우드 제공업체에서 읽기 전용 레플리카를 만드는 방법에 대해 설명합니다:

읽기 전용 레플리카가 설정되면, 보조 사이트를 구성하는 단계로 이동할 수 있습니다.

기본 사이트 SSH 호스트 키 수동 복제

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

    sudo -i

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

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

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

    • 보통 SSH 트래픽을 제공하는 기본 사이트 노드 중 하나에 root 계정으로 액세스할 수 있다면(일반적으로 주 GitLab Rails 애플리케이션 노드): 

      # 보조 사이트에서 실행하며 서버의 IP 또는 완전한 도메인 이름으로 '<primary_site_fqdn>'을 바꿉니다.
scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh

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

      # 기본 사이트의 노드에서 실행합니다:
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 키의 빠른 조회를 구성하는 단계를 따르세요.

빠른 조회는 Geo에서 필요합니다.

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

보조 사이트 추가

  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. 보조 사이트에 연결할 수 있는지 확인하려면 주 메인 GitLab 사이트의 Rails 또는 Sidekiq 서버에 SSH로 로그인하고 다음을 실행합니다: 

    sudo gitlab-rake gitlab:geo:check

    확인 중에 문제가 발생하면 문제 해결 문서를 확인하세요.

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

한편, 기본 사이트는 각 보조 사이트에 변경 사항을 알리기 시작하여 보조 사이트가 즉시 알림에 반응할 수 있도록 합니다.

보조 사이트가 실행되고 접근 가능한지 확인하세요. 기본 사이트에서 사용한 것과 동일한 자격 증명으로 보조 사이트에 로그인할 수 있습니다.

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

Geo는 HTTP/HTTPS를 통해 저장소를 동기화하며(새로운 설치의 경우 기본 설정으로 활성화됨) 따라서 이 복제 방법이 활성화되어 있어야 합니다. 기존 사이트를 Geo로 변환하는 경우 복제 방법이 활성화되어 있는지 확인해야 합니다.

기본 사이트에서:

  1. 왼쪽 사이드바에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 가시성 및 액세스 컨트롤을 확장합니다.
  4. SSH를 통해 Git을 사용하는 경우:
    1. 활성화된 Git 액세스 프로토콜이 SSH 및 HTTP(S)로 설정되었는지 확인합니다.
    2. 기본 및 보조 사이트에서 데이터베이스에서 SSH 키를 빠르게 조회하도록 설정했는지 확인합니다.
  5. Git을 SSH를 통해 사용하지 않는 경우, 활성화된 Git 액세스 프로토콜을 오직 HTTP(S)로 설정합니다.

보조 사이트의 올바른 기능 확인

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

로그인한 후:

  1. 왼쪽 사이드바에서 관리자를 선택합니다.
  2. Geo > 사이트를 선택합니다.
  3. 사이트가 올바르게 보조 Geo 사이트로 식별되고 Geo가 활성화되었는지 확인하세요.

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

Geo 관리 대시보드에서 보조 사이트의 동기화 상태를 보여주는 이미지.

추적 데이터베이스 구성

참고: 이 단계는 추적 데이터베이스를 외부 서버에서 설정하려는 경우에만 선택적으로 필요합니다.

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

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

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

확장 설치 중에 추가 역할이 필요합니다. 대안으로, 확장 프로그램이 수동으로 설치되어 있고, 나중에 GitLab 업그레이드 중에 발생할 수 있는 문제에 대해 읽어보세요.

참고: Amazon RDS를 추적 데이터베이스로 사용하려면 보조 데이터베이스에서 해당 데이터베이스에 액세스할 수 있도록 해야 합니다. 유감스럽게도 동일한 보안 그룹을 할당하는 것만으로는 충분하지 않습니다. 따라서 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. /etc/gitlab/gitlab.rb 파일을 열고 PostgreSQL 인스턴스를 위한 연결 매개변수와 자격 증명을 편집하세요: 

    geo_secondary['db_username'] = 'gitlab_geo'
geo_secondary['db_password'] = '<여기에_귀하의_추적_db_암호_입력>'

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 문제 해결을 참조하세요.