• 새로운 보조 사이트 구성
  • 단계 1. GitLab의 비밀값을 수동으로 복제
  • 단계 2. 기본 사이트의 SSH 호스트 키를 수동으로 복제
  • 단계 3. 보조 사이트 추가
  • 단계 4. (선택 사항) 사용자 정의 인증서 사용
    • 수신 연결에 대한 사용자 정의 또는 자체 서명된 인증서
    • 사용자 정의 인증서를 사용하는 외부 서비스에 연결
  • 단계 5. HTTP/HTTPS 및 SSH를 통한 Git 액세스 활성화
  • 단계 6. 부(secondary) 사이트의 올바른 기능 확인
• 선택적 동기화
  • 비동기식 저장소의 Git 작업
• Geo 업그레이드
• 문제 해결

Geo 구성

새로운 보조 사이트 구성

참고: 이것은 보조 Geo 사이트를 설정하는 마지막 단계입니다. 설정 프로세스의 단계는 문서화된 순서대로 완료되어야 합니다. 그렇지 않으면 진행하기 전에 이전 단계를 모두 완료하십시오.

기본 및 보조 사이트에서 데이터베이스 복제를 설정하고, 인증된 SSH 키의 빠른 조회를 구성하세요.

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

• 기본 사이트와 보조 사이트 간에 필요한 구성을 복제합니다.
• 각 보조 사이트에 추적 데이터베이스를 구성합니다.
• 각 보조 사이트에서 GitLab을 시작합니다.

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

참고: 보조 사이트에 사용자 정의 인증을 설정하지 마십시오. 이 작업은 기본 사이트에서 처리됩니다. 기본 사이트에서 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 레코드도 새로운 기본 사이트(IP 또는 FQDN으로 이전에는 보조 사이트)를 가리키도록 업데이트해야 합니다. 이렇게 하면 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 트래픽을 제공하는 기본 사이트의 노드 중 하나에 root 사용자로 액세스할 수 있는 경우:

   # 이 명령을 보조 사이트에서 실행하고, `<primary_node_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
   

   참고: 개인 키와 공개 키 명령에 대한 출력은 동일한 지문을 생성해야 합니다.

7. OpenSSH의 경우 보조 사이트의 각 Rails 노드에서 sshd를 재시작하거나, 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 보조 서버에 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'] = '<여기에_사이트_이름_입력>'
   

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. 선택 사항. 보조 사이트에서 복제해야 하는 그룹이나 저장소 샤드를 선택합니다. 모두 복제하려면 비워두십시오. 자세한 내용은 selective synchronization을 참조하세요.
   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 관리 페이지에 추가되고 재시작된 후에, 사이트는 백필이라고 알려진 과정에서 주 사이트에서 누락된 데이터를 자동으로 복제하기 시작합니다. 한편, 주 사이트는 각 보조 사이트에 변경 사항을 알리기 시작하여 보조 사이트가 이러한 알림에 즉시 대응할 수 있도록 합니다.

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

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

다음 경우 이 단계를 건너뛸 수 있습니다:

• 주 사이트가 공용 CA에 의해 발급된 HTTPS 인증서를 사용하는 경우.
• 주 사이트가 자체 서명이 아닌 CA에 의해 발급된 HTTPS 인증서로만 외부 서비스에 연결하는 경우.

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

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

인증서 유형에 따라 올바른 인증서를 설치하세요:

• 주 사이트 및 보조 사이트 도메인을 모두 포함하는 다중 도메인 인증서: 보조 사이트의 모든 Rails, Sidekiq, Gitaly 노드에 /etc/gitlab/ssl에 인증서를 설치하세요.
• 각 Geo 사이트 도메인에 특화된 단일 도메인 인증서: 보조 사이트 도메인의 유효 인증서를 생성하고, 이를 보조 사이트의 모든 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. 왼쪽 사이드바에서 맨 아래에서 관리 영역(Admin Area)을 선택합니다.
2. 설정 > 일반(General)을 선택합니다.
3. 가시성 및 액세스 제어(Visibility and access controls)를 확장합니다.
4. Git을 SSH로 사용하는 경우:
   1. “활성화된 Git 액세스 프로토콜”이 “SSH 및 HTTP(S)”로 설정되었는지 확인합니다.
   2. 모든 주(primary) 및 부(secondary) 사이트에서 데이터베이스에서 SSH 키를 빠르게 찾는 방법을 따릅니다.
5. Git을 SSH로 사용하지 않는 경우 “활성화된 Git 액세스 프로토콜”을 “오직 HTTP(S)”로 설정합니다.

단계 6. 부(secondary) 사이트의 올바른 기능 확인

부(secondary) 사이트로 기본(primary) 사이트에서 사용한 것과 동일한 자격 증명으로 로그인할 수 있습니다. 로그인한 후:

1. 왼쪽 사이드바에서 맨 아래에서 관리 영역(Admin Area)을 선택합니다.
2. Geo > 사이트(Geo > Sites)를 선택합니다.
3. 올바르게 부(secondary) Geo 사이트로 식별되었는지, 그리고 Geo 기능이 활성화되었는지 확인합니다.

초기 복제에는 시간이 소요될 수 있습니다. 사이트의 상태나 ‘백필’(backfill)이 여전히 진행 중일 수 있습니다. 브라우저에서 기본(primary) 사이트의 Geo Sites 대시보드에서 각 Geo 사이트의 동기화 프로세스를 모니터링할 수 있습니다.

설치가 제대로 작동하지 않는 경우 문제 해결 문서를 확인하세요.

대시보드에서 명백히 나타날 수 있는 두 가지 주요 문제는:

1. 데이터베이스 복제가 제대로 작동하지 않음.
2. 인스턴스 간 알림이 작동하지 않음. 이 경우 다음과 같은 상황일 수 있습니다:
   • 사용자 정의 인증서 또는 사용자 정의 CA를 사용 중인 경우(문제 해결 문서 참조).
   • 인스턴스가 방화벽에 의해 차단됨(방화벽 규칙 확인).

부(secondary) 사이트를 비활성화하면 동기화 프로세스가 중지됩니다.

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

사용자를 Geo 사이트 사용 가이드로 안내하세요.

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

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

선택적 동기화

Geo는 선택적 동기화를 지원합니다. 이를 통해 관리자는 부(secondary) 사이트에서 동기화해야 할 프로젝트를 선택할 수 있습니다. 프로젝트의 하위 집합을 선택할 수 있으며 그룹이나 저장소 샤드별로 선택할 수도 있습니다. 전자는 사용자 하위 집합에 속한 데이터를 복제하는 데 이상적이며, 후자는 대규모 GitLab 인스턴스에 Geo를 점진적으로 적용하는 데 적합합니다.

참고: Geo의 동기화 논리는 문서에 개요가 되어 있습니다. 솔루션 및 문서는 수시로 변경될 수 있습니다. 개인적으로 계속하여 개인의 사생활 및 사이버보안 법, 해당 교역 통제 법률에 대한 법적 의무를 결정해야 합니다.

선택적 동기화:

1. 부(secondary) 사이트의 권한을 제한하지 않습니다.
2. 부(secondary) 사이트에 프로젝트 메타데이터를 숨기지 않습니다.
   • 현재 Geo는 PostgreSQL 복제를 사용하므로 모든 프로젝트 메타데이터가 부(secondary) 사이트로 복제되지만, 선택되지 않은 리포지토리는 비어 있습니다.
3. Geo 이벤트 로그에 생성되는 이벤트의 수를 줄이지 않습니다.
   • 기본(primary) 사이트는 부(secondary) 사이트가 있는 한 이벤트를 생성합니다. 선택적 동기화 제한은 부(secondary) 사이트에 적용되며, 기본(primary) 사이트에 적용되지 않습니다.

비동기식 저장소의 Git 작업

• HTTP(S)에서 12.10에서 도입됨(https://gitlab.com/groups/gitlab-org/-/epics/2562), SSH에서 13.0에서 도입됨.

HTTP(S) 및 SSH를 통한 Git 클론, 풀 및 푸시 작업은 기본 사이트에는 있는데 부(secondary) 사이트에는 없는 레포지토리를 지원합니다. 이 상황은 다음 경우 발생할 수 있습니다:

• 선택적 동기화에 프로젝트가 포함되어 있지 않을 때.
• 레포지토리가 활발하게 복제되고 있지만 아직 완료되지 않은 경우.

Geo 업그레이드

Geo 사이트 업그레이드 문서를 참조하세요.

문제 해결

문제 해결 문서를 참조하세요.