Geo 구성

Tier: Premium, Ultimate Offering: Self-Managed

Secondary 사이트 구성

note
이것은 secondary Geo 사이트를 설정하는 마지막 단계입니다. 설치 프로세스의 단계는 문서화된 순서대로 완료되어야 합니다. 그렇지 않으면 계속하기 전에 이전 모든 단계를 완료하십시오.

Primary 및 Secondary 사이트의 데이터베이스 복제를 설정하고, 인가된 SSH 키의 빠른 조회를 구성하십시오.

Secondary 사이트를 구성하는 기본 단계는 다음과 같습니다.

  • Primary 사이트 및 Secondary 사이트 간에 필요한 구성을 복제합니다.
  • 각 Secondary 사이트에 추적 데이터베이스를 구성하십시오.
  • 각 Secondary 사이트에서 GitLab을 시작합니다.

테스트/운영 환경에서 실행하기 전에 모든 단계를 먼저 읽어보는 것이 좋습니다.

note
Secondary 사이트에 대한 사용자 정의 인증(까지)를 설정하지 마십시오. 이 작업은 Primary 사이트에서 처리됩니다. Secondary 사이트는 읽기 전용 복제본이기 때문에 Admin Area에 액세스가 필요한 변경 사항은 Primary 사이트에서 수행되어야 합니다.

단계 1. GitLab 비밀 값 매뉴얼 복제

GitLab은 /etc/gitlab/gitlab-secrets.json 파일에 여러 비밀 값을 저장하며, 이 값은 사이트의 모든 노드에서 동일해야만 합니다. 사이트 간에 이러한 값을 자동으로 복제할 방법이 있을 때까지 (이슈 #3789 참조) Secondary 사이트의 모든 노드에 비밀을 매뉴얼으로 복제해야만 합니다.

  1. Primary 사이트에서 Rails 노드로 SSH하고 아래 명령을 실행하십시오: 

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

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

  2. Secondary Geo 사이트의 각 노드에 SSH하여 root 사용자로 로그인하십시오: 

    sudo -i

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

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

  4. /etc/gitlab/gitlab-secrets.json을 Primary 사이트의 Rails 노드에서 Secondary 사이트의 모든 노드로 복사하거나 노드 간에 파일 내용을 복사 및 붙여넣기하십시오: 

    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. 변경 사항이 적용되려면 Secondary 사이트의 각 Rails, Sidekiq 및 Gitaly 노드를 구성하십시오: 

    gitlab-ctl reconfigure
gitlab-ctl restart

단계 2. Primary 사이트의 SSH 호스트 키 매뉴얼 복제

GitLab은 시스템에 설치된 SSH 데몬과 통합되어, 모든 액세스 요청을 처리하는 유저(일반적으로 git이름의)를 지정합니다.

Disaster Recovery 상황에서 GitLab 시스템 관리자는 Secondary 사이트를 Primary 사이트로 승격합니다. Primary 도메인의 DNS 레코드도 새로운 Primary 사이트로 업데이트되어야 합니다 (이전에는 Secondary 사이트였음). 이렇게 하면 Git 원격 및 API URL을 업데이트할 필요가 없게 됩니다.

이로 인해 새로 승격된 Primary 사이트로의 모든 SSH 요청이 SSH 호스트 키 불일치로 실패합니다. 이를 방지하려면 Primary SSH 호스트 키를 Secondary 사이트로 매뉴얼으로 복제해야 합니다.

SSH 호스트 키 경로는 사용하는 소프트웨어에 따라 다릅니다:

  • OpenSSH를 사용하는 경우, 경로는 /etc/ssh입니다.
  • gitlab-sshd를 사용하는 경우, 경로는 /var/opt/gitlab/gitlab-sshd입니다.

다음 단계에서 <ssh_host_key_path>를 사용 중인 경로로 변경하십시오.

  1. Secondary 사이트의 각 Rails 노드에 SSH하고 root 사용자로 로그인하십시오: 

    sudo -i

  2. 기존 SSH 호스트 키를 백업하십시오: 

    find <ssh_host_key_path> -iname 'ssh_host_*' -exec cp {} {}.backup.`date +%F` \;

  3. Primary 사이트에서 SSH 트래픽을 제공하는 노드 중 하나에 접근할 수 있는 경우 (일반적으로, 주요 GitLab Rails 애플리케이션 노드): 

    # Secondary 사이트에서 실행하며, <primary_node_fqdn>을 서버의 IP 또는 FQDN으로 변경하십시오
scp root@<primary_node_fqdn>:<ssh_host_key_path>/ssh_host_*_key* <ssh_host_key_path>

    sudo 권한이 있는 유저로만 액세스할 수 있는 경우: 

    # Primary 사이트의 노드에서 실행하십시오:
sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz <ssh_host_key_path>/ssh_host_*_key*
   
# Secondary 사이트의 각 노드에서 실행하십시오:
scp <user_with_sudo>@<primary_site_fqdn>:geo-host-key.tar.gz .
tar zxvf ~/geo-host-key.tar.gz -C <ssh_host_key_path>

  4. Secondary 사이트의 각 Rails 노드에서 파일 권한이 올바른지 확인하십시오: 

    chown root:root <ssh_host_key_path>/ssh_host_*_key*
chmod 0600 <ssh_host_key_path>/ssh_host_*_key

  5. 키 지문이 일치하는지 확인하십시오. 각 사이트의 기본 및 Secondary 노드에서 다음 명령을 실행하십시오: 

    for file in <ssh_host_key_path>/ssh_host_*_key; do ssh-keygen -lf $file; done

    다음과 유사한 출력을 받아야 하며, 두 노드에서 동일해야 합니다: 

    1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
2048 SHA256:qwa+rgir2Oy86QI+PZi/QVR+MSmrdrpsuH7YyKknC+s root@serverhostname (RSA)

  6. 기존 개인 키에 대한 올바른 공개 키를 확인하십시오: 

    # 개인 키의 지문을 출력합니다:
for file in <ssh_host_key_path>/ssh_host_*_key; do ssh-keygen -lf $file; done
   
# 공개 키의 지문을 출력합니다:
for file in <ssh_host_key_path>/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
    note
    개인 키와 공개 키 명령에 대한 출력은 동일한 지문을 생성해야 합니다.

  7. Secondary 사이트의 각 Rails 노드에서 sshd (OpenSSH를 위해) 또는 gitlab-sshd 서비스를 재시작하십시오:

    • OpenSSH의 경우: 

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

    • gitlab-sshd의 경우: 

       sudo gitlab-ctl restart gitlab-sshd

  8. SSH가 여전히 작동하는지 확인하십시오.

    새로운 터미널에서 GitLab Secondary 서버에 SSH합니다. 연결할 수 없는 경우, 이전 단계에 따라 권한이 올바른지 확인하십시오.

단계 3. 보조 사이트 추가

  1. 보조 사이트의 각 Rails 및 Sidekiq 노드에 SSH로 로그인하고 루트로 전환하십시오: 

    sudo -i

  2. /etc/gitlab/gitlab.rb 파일을 편집하고 사이트에 대한 고유한 이름을 추가하십시오. 이것은 다음 단계에서 필요합니다: 

    ##
## Geo 사이트의 고유 식별자. 자세한 내용은
## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings 를 참조하세요
##
gitlab_rails['geo_node_name'] = '<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로 로그인하고 서비스를 다시 시작하십시오: 

    gitlab-ctl restart

    다음 명령을 실행하여 Geo 설정에 일반적인 문제가 있는지 확인하십시오: 

    gitlab-rake gitlab:geo:check

  6. 주 서버의 Rails 또는 Sidekiq 서버에 SSH로 로그인하여 루트로 전환하고 보조 사이트가 접근 가능한지 또는 Geo 설정에 문제가 있는지 확인하십시오: 

    gitlab-rake gitlab:geo:check

    어떤 검사가 실패하면 문제 해결 문서를 확인하십시오.

보조 사이트가 Geo 관리 페이지에 추가되고 재시작되면, 사이트는 자동으로 후속 처리(backfill)라는 프로세스에서 주 사이트에서 누락된 데이터를 복제하기 시작합니다. 한편, 주 사이트는 각 보조 사이트에 변경 사항을 알리기 시작하여 보조 사이트가 이러한 알림에 즉시 대응할 수 있습니다.

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

단계 4. (선택 사항) 사용자 정의 인증서 사용

다음을 확인하십시오:

  • 주 사이트가 공용 CA로 발급된 HTTPS 인증서를 사용하고 있는지.
  • 주 사이트가 CA(자체 서명이 아닌)로 외부 서비스에 연결하고 있는지.

수신 연결을 위한 사용자 정의 또는 자체 서명된 인증서

만약 여러 도메인을 포함한 Multi-domain certificate가 있는 경우 보조 사이트의 모든 Rails, Sidekiq, 및 Gitaly 노드에 /etc/gitlab/ssl에 해당 인증서를 설치하십시오.

각 Geo 사이트 도메인에 특정한 Single-domain certificate가 있는 경우 보조 사이트의 모든 Rails, Sidekiq, 및 Gitaly 노드에 이 지침에 따라 /etc/gitlab/ssl에 유효한 인증서를 생성하고 설치하십시오.

사용자 정의 인증서를 사용하는 외부 서비스 연결

외부 서비스가 사용자 정의 인증서를 사용하는 경우, 해당 서비스의 자체 서명된 인증서의 사본을 주 사이트 노드의 신뢰 리포지터리에 추가해야 합니다.

보조 사이트가 동일한 외부 서비스에 액세스하려면 이러한 인증서를 보조 사이트의 신뢰 리포지터리에 반드시 추가해야 합니다.

만약 주 사이트가 수신 HTTPS 연결에 사용자 정의 또는 자체 서명된 인증서를 사용하고 있다면, 해당 주 사이트의 인증서를 보조 사이트의 신뢰 리포지터리에 추가해야 합니다:

  1. 보조 사이트의 각 Rails, Sidekiq, 및 Gitaly 노드에 SSH로 로그인하고 루트로 전환하십시오: 

    sudo -i

  2. 주 사이트로부터 신뢰할 수 있는 인증서를 복사하십시오:

    만약 주 사이트에를 제공하는 루트 사용자를 통해 SSH 트래픽에 액세스할 수 있는 경우: 

    scp root@<primary_site_node_fqdn>:/etc/gitlab/trusted-certs/* /etc/gitlab/trusted-certs

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

    # 주 사이트의 노드에서 실행:
sudo tar --transform 's/.*\///g' -zcvf ~/geo-trusted-certs.tar.gz /etc/gitlab/trusted-certs/*
   
# 보조 사이트의 각 노드에서 실행:
scp <user_with_sudo>@<primary_site_node_fqdn>:geo-trusted-certs.tar.gz .
tar zxvf ~/geo-trusted-certs.tar.gz -C /etc/gitlab/trusted-certs

  3. 보조 사이트의 각 업데이트된 Rails, Sidekiq, 및 Gitaly 노드를 다시 구성하십시오: 

    sudo gitlab-ctl reconfigure

단계 5. HTTP/HTTPS 및 SSH를 통한 Git 액세스 활성화

Geo는 리포지터리를 HTTP/HTTPS로 동기화하므로 이 클론 방법을 활성화해야 합니다. 기본적으로 이것은 활성화되어 있지만, 기존 사이트를 Geo로 변환하는 경우 확인해야 합니다:

주 사이트에서:

  1. 왼쪽 사이드바에서 가장 아래에서 관리 영역을 선택하십시오.
  2. 설정 > 일반을 선택하십시오.
  3. 가시성 및 액세스 제어를 확장하십시오.
  4. SSH를 통한 Git을 사용하는 경우:
    1. “활성화된 Git 액세스 프로토콜”이 “SSH 및 HTTP(S)”로 설정되어 있는지 확인하십시오.
    2. 모든 주 및 보조 사이트에서 데이터베이스에서 권한 부여된 SSH 키 빠른 조회를 따르십시오.
  5. Git을 통한 동기화를 사용하지 않는 경우 “활성화된 Git 액세스 프로토콜”을 “HTTP(S)만”로 설정하십시오.

단계 6. 보조 사이트의 올바른 작동 확인

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

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

초기 복제에는 시간이 소요될 수 있습니다. 사이트의 상태 또는 ‘후속 처리’가 아직 진행 중일 수 있습니다. 브라우저에서 주 사이트의 Geo 사이트 대시보드에서 각 Geo 사이트의 동기화 프로세스를 모니터링할 수 있습니다.

Geo 대시보드

설치가 정상적으로 작동하지 않는 경우 문제 해결 문서를 확인하십시오.

대시보드에서 나타날 수 있는 가장 분명한 문제점은 다음과 같습니다:

  1. 데이터베이스 복제가 제대로 작동하지 않음.
  2. 인스턴스 간 알림이 작동하지 않음. 이 경우 아래 중 하나여야 합니다:
    • 사용자 지정 인증서 또는 사용자 지정 CA를 사용 중 (자세한 내용은 문제 해결 문서를 참조).
    • 인스턴스에서 방화벽이 설정됨 (방화벽 규칙을 확인하십시오).

보조 사이트를 비활성화하면 동기화 프로세스가 중지됩니다.

만약 주 사이트에서 git_data_dirs가 여러 리포지터리 샤드에 대해 사용자 지정된 경우, 이와 동일한 구성을 각 보조 사이트에 중복해야 합니다.

사용자를 Geo Site 가이드 사용로 이어질 것입니다.

현재 이와 같은 항목이 동기화됩니다:

  • Git 리포지터리.
  • 위키.
  • LFS 객체.
  • 이슈, Merge Request, 스니펫, 및 코멘트 첨부 파일.
  • 사용자, 그룹, 및 프로젝트 아바타.

선택적 동기화

Geo는 보조 사이트에서 어떤 프로젝트를 동기화할지를 선택할 수 있는 선택적 동기화를 지원합니다. 프로젝트의 하위 집합은 그룹 또는 리포지터리 샤드별로 선택할 수 있습니다. 전자는 일부 사용자에게 속한 데이터를 복제하는 데 적합하며, 후자는 대규모 GitLab 인스턴스에 Geo를 점진적으로 전파하는 데 더 적합합니다.

note
Geo의 동기화 논리는 문서에 개요가 되어 있습니다. 해결책과 문서 모두 수시로 변경될 수 있습니다. 계속해서 개인적으로 개인정보 보호 및 사이버보안 법률, 적용 가능한 무역 통제 법률과 관련하여 법적 의무를 결정해야 합니다.

선택적 동기화:

  1. 보조 사이트의 권한을 제한하지 않습니다.
  2. 보조 사이트에서 프로젝트 메타데이터를 숨기지 않습니다.
    • 현재 Geo는 PostgreSQL 복제를 의존하고 있으므로 모든 프로젝트 메타데이터가 보조 사이트로 복제되지만, 선택되지 않은 리포지터리는 비어 있습니다.
  3. Geo 이벤트 로그에 생성된 이벤트 수를 줄이지 않습니다.
    • 기본 사이트에서 이벤트가 생성되는 한 어떤 보조 사이트가 존재하는 한 Geo 이벤트 로그에 이벤트가 생성됩니다. 선택적 동기화 제한은 보조 사이트에 적용되며, 기본 사이트에는 적용되지 않습니다.

미복제 리포지터리에 대한 Git 작업

기본 사이트에만 존재하고 보조 사이트에는 없는 리포지터리에 대해 HTTP(S) 및 SSH를 통한 Git clone, pull 및 push 작업이 지원됩니다. 이러한 상황은 다음과 같을 수 있습니다.

  • 선택적 동기화가 리포지터리에 연결된 프로젝트를 포함하지 않은 경우.
  • 리포지터리가 활발하게 복제되고 있지만 아직 완료되지 않은 경우.

Geo 업그레이드

Geo 사이트 업그레이드 문서를 참조하십시오.

문제 해결

문제 해결 문서를 참조하십시오.