새 보조 사이트 구성

Tier: Premium, Ultimate Offering: Self-managed
note
이것은 보조 Geo 사이트를 설정하는 최종 단계입니다. 설정 프로세스의 단계는 문서화된 순서대로 완료되어야 합니다.
그렇지 않은 경우, 모든 이전 단계 완료 후 진행하십시오.

보조 사이트 구성을 위한 기본 단계는 다음과 같습니다:

  1. 주 사이트와 보조 사이트 간에 필요한 구성 복제
  2. 각 보조 사이트에 추적 데이터베이스 구성
  3. 각 보조 사이트에서 GitLab 시작

이 문서는 첫 번째 항목에 중점을 둡니다. 테스트/실제 환경에서 실행하기 전에 모든 단계를 먼저 읽어보는 것이 좋습니다.

둘 다 주 및 보조 사이트에 대한 전제 조건:

note
커스텀 인증을 보조 사이트에 설정하지 마십시오. 이는 주 사이트에서 처리됩니다.
Admin area에 대한 액세스가 필요한 모든 변경은 주 사이트에서 수행해야 하며, 보조 사이트는 읽기 전용 복제본입니다.

1단계. 비밀 GitLab 값 수동 복제

GitLab은 /etc/gitlab/gitlab-secrets.json 파일에 여러 비밀 값을 저장하며, 이는 모든 사이트의 노드에서 동일해야 합니다.
사이트 간에 이를 자동으로 복제하는 방법이 없기 때문에(참조: 문제 #3789),
이 값들은 보조 사이트의 모든 노드에 수동으로 복제해야 합니다.

  1. 주 사이트의 Rails 노드에 SSH로 접속한 후 아래 명령을 실행합니다:

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

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

  2. 각 보조 Geo 사이트의 노드에 SSH로 접속하여 root 사용자로 로그인합니다:

    sudo -i

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

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

  4. 주 사이트의 Rails 노드에서 /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. 변경 사항이 적용되도록 각 보조 사이트의 Rails, Sidekiq 및 Gitaly 노드를 재구성합니다:

    gitlab-ctl reconfigure  
gitlab-ctl restart

2단계. 주 사이트의 SSH 호스트 키 수동 복제

GitLab은 시스템에 설치된 SSH 데몬과 통합되어 있으며, 모든 액세스 요청을 처리하는 사용자(일반적으로 git이라고 함)를 지정합니다.

재난 복구 상황에서, GitLab 시스템 관리자는 보조 사이트를 주 사이트로 승격합니다.
주 도메인의 DNS 레코드도 새 주 사이트(이전의 보조 사이트)를 가리키도록 업데이트해야 합니다.
이렇게 하면 Git 원격 및 API URL을 업데이트할 필요가 없습니다.

이로 인해 새롭게 승격된 주 사이트에 대한 모든 SSH 요청이 SSH 호스트 키 불일치로 실패하게 됩니다.
이를 방지하기 위해서는 주 사이트의 SSH 호스트 키를 보조 사이트에 수동으로 복제해야 합니다.

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

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

다음 단계에서 <ssh_host_key_path>를 사용 중인 경로로 바꿉니다:

  1. 각 보조 사이트의 Rails 노드에 SSH로 접속하고 root 사용자로 로그인합니다:

    sudo -i

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

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

  3. 주 사이트에서 SSH 호스트 키를 복사합니다:

    주 사이트의 SSH 트래픽을 제공하는 노드(일반적으로 주요 GitLab Rails 애플리케이션 노드)에 root 사용자로 접속할 수 있는 경우:

    # 보조 사이트에서 실행, `<primary_site_fqdn>`을 서버의 IP 또는 FQDN으로 변경  
scp root@<primary_node_fqdn>:<ssh_host_key_path>/ssh_host_*_key* <ssh_host_key_path>

    sudo 권한이 있는 사용자로만 접근할 수 있는 경우:

    # 주 사이트의 노드에서 실행:  
sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz <ssh_host_key_path>/ssh_host_*_key*  

# 각 보조 사이트의 노드에서 실행:  
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. 각 보조 사이트의 Rails 노드에서 파일 권한이 올바른지 확인합니다:

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

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

    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. 각 보조 사이트의 Rails 노드에서 OpenSSH의 경우 sshd 또는 gitlab-sshd 서비스를 재시작합니다:

    • OpenSSH의 경우:

      # 데비안 또는 우분투 설치  
sudo service ssh reload  

# 센트OS 설치  
sudo service sshd reload

    • gitlab-sshd의 경우:

      sudo gitlab-ctl restart gitlab-sshd

  8. SSH가 여전히 작동하는지 확인합니다.

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

3단계. 보조 사이트 추가

  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'] = '<site_name_here>'

  3. 변경 사항이 적용되도록 보조 사이트의 각 Rails 및 Sidekiq 노드를 재구성합니다:

    gitlab-ctl reconfigure
  4. 기본 노드 GitLab 인스턴스로 이동합니다:
    1. 왼쪽 사이드바 하단에서 Admin을 선택합니다.
    2. 왼쪽 사이드바에서 Geo > Sites를 선택합니다.
    3. Add site를 선택합니다. Geo 구성 인터페이스에서 보조 사이트 추가
    4. Name에 /etc/gitlab/gitlab.rb에 있는 gitlab_rails['geo_node_name']의 값을 입력합니다. 이 값들은 항상 정확히, 문자 하나하나 맞아야 합니다.
    5. External URL에 /etc/gitlab/gitlab.rb의 external_url 값을 입력합니다. 이 값들은 항상 일치해야 하지만, 하나가 /로 끝나고 다른 하나가 그렇지 않아도 상관없습니다.
    6. 선택 사항. Internal URL (optional)에 보조 사이트에 대한 내부 URL을 입력합니다.
    7. 선택 사항. 보조 사이트가 복제할 그룹이나 스토리지 샤드를 선택합니다. 모두 복제하려면 비워둡니다. 더 많은 정보는 선택적 동기화를 참조하세요.
    8. Save changes를 선택하여 보조 사이트를 추가합니다.

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

    gitlab-ctl restart

    Geo 설정의 일반적인 문제를 확인하려면 다음을 실행합니다:

    gitlab-rake gitlab:geo:check

    어떤 점검이 실패하면 문제 해결 문서를 확인하세요.

  6. 기본 사이트의 Rails 또는 Sidekiq 서버에 SSH로 로그인하고 root로 로그인하여 **보조 사이트에 접근 가능하며 Geo 설정의 일반적인 문제를 확인합니다:**

    gitlab-rake gitlab:geo:check

    어떤 점검이 실패하면 문제 해결 문서를 확인하세요.

보조 사이트가 Geo 관리 페이지에 추가되고 재시작된 후, 해당 사이트는 backfill로 알려진 프로세스에서 기본 사이트에서 누락된 데이터를 자동으로 복제하기 시작합니다.

이와 동시에 기본 사이트는 각 보조 사이트에 변경 사항을 알려주어 보조 사이트가 즉시 해당 알림을 처리할 수 있도록 합니다.

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

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

다음 단계는 안전하게 건너뛸 수 있습니다:

  • 기본 사이트가 공개 CA 발급 HTTPS 인증서를 사용하는 경우.
  • 기본 사이트가 CA 발급(자가 서명 아님) HTTPS 인증서로만 외부 서비스에 연결하는 경우.

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

귀하의 GitLab Geo 주요 사이트가 수신 HTTPS 연결을 보호하기 위해 사용자 지정 또는 자체 서명된 인증서를 사용하는 경우, 이는 단일 도메인 또는 다중 도메인 인증서일 수 있습니다.

인증서 유형에 따라 올바른 인증서를 설치하십시오:

  • 주요 및 보조 사이트 도메인을 모두 포함하는 다중 도메인 인증서: 보조 사이트의 모든 Rails, Sidekiq 및 Gitaly 노드의 /etc/gitlab/ssl에 인증서를 설치하십시오.
  • 각 Geo 사이트 도메인에 특정한 단일 도메인 인증서: 귀하의 보조 사이트 도메인에 대한 유효한 인증서를 생성하고 이 지침에 따라 /etc/gitlab/ssl에 설치하십시오. Rails, Sidekiq, 및 Gitaly 노드의 모든 보조 사이트.

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

외부 서비스에 대한 자체 서명된 인증서의 복사본을 서비스에 접근해야 하는 모든 주요 사이트 노드의 신뢰 저장소에 추가해야 합니다.

보조 사이트가 동일한 외부 서비스에 액세스할 수 있으려면 이러한 인증서를 보조 사이트의 신뢰 저장소에 추가해야 합니다.

귀하의 주요 사이트가 수신 HTTPS 연결을 위한 사용자 지정 또는 자체 서명된 인증서를 사용하고 있는 경우, 주요 사이트의 인증서를 보조 사이트의 신뢰 저장소에 추가해야 합니다:

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

    sudo -i

  2. 주요 사이트에서 신뢰된 인증서를 복사하십시오:

    root 사용자로 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. Git over SSH를 사용하는 경우:
    1. “활성화된 Git 액세스 프로토콜”이 “SSH 및 HTTP(S) 모두”로 설정되어 있는지 확인합니다.
    2. 모든 주요 및 보조 사이트에서 데이터베이스에서 승인된 SSH 키의 빠른 조회를 구성하는 단계를 따릅니다.
  5. Git over SSH를 사용하지 않는 경우 “활성화된 Git 액세스 프로토콜”을 “HTTP(S)만”으로 설정합니다.

6단계. 보조 사이트의 올바른 기능 확인

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

  1. 왼쪽 사이드바에서 아래쪽에 있는 관리자를 선택합니다.
  2. Geo > 사이트를 선택합니다.
  3. 이를 보조 Geo 사이트로 올바르게 식별했는지, 그리고 Geo가 활성화되어 있는지 확인합니다.

초기 복제에는 시간이 걸릴 수 있습니다. 사이트의 상태나 ‘백필’이 여전히 진행 중일 수 있습니다. 각 Geo 사이트에서 기본 사이트의 Geo 사이트 대시보드에서 동기화 프로세스를 모니터링할 수 있습니다.

보조 사이트의 Geo 대시보드

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

대시보드에서 명백하게 드러날 수 있는 두 가지 가장 일반적인 문제는 다음과 같습니다:

  1. 데이터베이스 복제가 원활하지 않음.
  2. 인스턴스 간 알림이 작동하지 않음. 이 경우, 다음과 같은 원인이 있을 수 있습니다:
    • 사용자 정의 인증서 또는 사용자 정의 CA를 사용하고 있습니다 ( 문제 해결 문서를 참조하세요).
    • 인스턴스가 방화벽 뒤에 있습니다 (방화벽 규칙을 확인하십시오).

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

git_data_dirs가 기본 사이트에서 여러 리포지토리 샤드를 위해 사용자 정의된 경우, 각 보조 사이트에서 동일한 구성을 복제해야 합니다.

사용자에게 Geo 사이트 사용 가이드를 참조하도록 안내하십시오.

현재 동기화되는 항목은 다음과 같습니다:

  • Git 리포지토리.
  • 위키.
  • LFS 객체.
  • 이슈, 병합 요청, 스니펫 및 댓글 첨부 파일.
  • 사용자, 그룹 및 프로젝트 아바타.

문제 해결

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