- 단계 1. 수동으로 GitLab 비밀 값을 복제합니다.
- 단계 2. 주 사이트의 SSH 호스트 키를 수동으로 복제
- 단계 3. 보조 사이트 추가
- 단계 4. (선택 사항) 사용자 지정 인증서 사용
- 단계 5. HTTP/HTTPS 및 SSH를 통한 Git 액세스 활성화
- 단계 6. 보조(secondary) 사이트의 올바른 기능 확인
- 문제 해결
새로운 보조 사이트 구성
보조 사이트 구성의 기본 단계는 다음과 같습니다.
- 주 사이트(primary)와 보조 사이트(secondary) 간에 필요한 구성 복제
- 보조 사이트 각각에 추적 데이터베이스 구성
- 보조 사이트 각각에서 GitLab 시작
이 문서는 첫 번째 항목에 중점을 두고 있습니다. 테스트/운영 환경에서 실행하기 전에 모든 단계를 먼저 읽어보시기 바랍니다.
주 사이트 및 보조 사이트에 대한 선행 요구 사항:
단계 1. 수동으로 GitLab 비밀 값을 복제합니다.
GitLab은 모든 사이트 노드에서 동일해야 하는 여러 비밀 값을 /etc/gitlab/gitlab-secrets.json 파일에 저장합니다. 이 값들을 자동으로 복제할 수 있는 방법이 있을 때까지(이슈 #3789 참조) 이 값들은 보조 사이트의 모든 노드에 수동으로 복제되어야 합니다.
-
주 사이트의 Rails 노드에서 SSH를 실행하고 아래 명령을 실행하십시오:
sudo cat /etc/gitlab/gitlab-secrets.json이 명령은 JSON 형식으로 복제해야 하는 비밀 값을 표시합니다.
-
보조 Geo 사이트의 각 노드에서 SSH하여
root사용자로 로그인합니다:sudo -i -
기존 비밀 값을 백업합니다:
mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F` -
주 사이트의 Rails 노드에서
/etc/gitlab/gitlab-secrets.json을 각 보조 사이트의 노드로 복사하거나 노드 간에 파일 내용을 복사하여 붙여넣습니다:sudo editor /etc/gitlab/gitlab-secrets.json # 주 사이트에서 실행한 `cat` 명령의 출력을 붙여넣습니다 # 저장하고 나가기 -
파일 권한이 올바른지 확인합니다:
chown root:root /etc/gitlab/gitlab-secrets.json chmod 0600 /etc/gitlab/gitlab-secrets.json -
변경 사항이 적용되려면 각 보조 사이트의 Rails, Sidekiq 및 Gitaly 노드를 다시 구성하십시오:
gitlab-ctl reconfigure gitlab-ctl restart
단계 2. 주 사이트의 SSH 호스트 키를 수동으로 복제
GitLab은 시스템 설치된 SSH 데몬과 통합하여 모든 액세스 요청을 처리하는 사용자(일반적으로 git이라고 불림)를 지정합니다.
재해 복구 상황에서 GitLab 시스템 관리자는 보조 사이트를 주 사이트로 승격시킵니다. 주 도메인의 DNS 레코드도 새 주 사이트로 지정되어야 합니다(이전에는 보조 사이트였음). 이것은 Git 리모트 및 API URL을 업데이트할 필요 없이 SSH 요청을 새로 승격된 주 사이트로 보낼 수 있도록 합니다.
이로 인해 새로 승격된 주 사이트로의 모든 SSH 요청이 SSH 호스트 키 불일치로 실패합니다. 이를 방지하기 위해 주 사이트의 SSH 호스트 키를 보조 사이트로 수동으로 복제해야 합니다.
사용 중인 소프트웨어에 따라 SSH 호스트 키 경로가 다릅니다.
- OpenSSH를 사용하는 경우 경로는
/etc/ssh입니다. -
gitlab-sshd를 사용하는 경우 경로는/var/opt/gitlab/gitlab-sshd입니다.
다음 단계에서
-
보조 사이트의 각 Rails 노드에서 SSH로 로그인하고
root사용자로 로그인합니다:sudo -i -
기존 SSH 호스트 키를 백업합니다:
find <ssh_host_key_path> -iname 'ssh_host_*' -exec cp {} {}.backup.`date +%F` \; -
주 사이트로부터 SSH 호스트 키를 복사합니다:
주 사이트의 하나의 노드에서(일반적으로 메인 GitLab Rails 애플리케이션 노드) root 사용자를 사용하여 SSH 트래픽을 제공하는 경우:
# 이 명령은 보조 사이트에서 실행하며, 서버의 IP 또는 FQDN에 해당하는 <primary_node_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> -
보조 사이트의 각 Rails 노드에서 파일 권한이 올바른지 확인합니다:
chown root:root <ssh_host_key_path>/ssh_host_*_key* chmod 0600 <ssh_host_key_path>/ssh_host_*_key -
각 사이트의 주요 및 보조 노드에서 다음 명령을 실행하여 키 지문이 일치하는지 확인합니다:
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) -
기존 공개 키에 대한 올바른 비밀 키를 확인합니다:
# 이 명령은 비밀 키의 지문을 인쇄합니다: 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비밀 키 및 공개 키 명령에 대한 출력은 동일한 지문을 생성해야 합니다. -
보조 사이트의 각 Rails 노드에서 OpenSSH의
sshd또는gitlab-sshd서비스를 다시 시작합니다:-
OpenSSH의 경우:
# Debian 또는 Ubuntu 설치 sudo service ssh reload # CentOS 설치 sudo service sshd reload -
gitlab-sshd의 경우:sudo gitlab-ctl restart gitlab-sshd
-
-
SSH가 여전히 작동하는지 확인합니다.
새 터미널에서 GitLab 보조 서버로 SSH하여 연결할 수 없는 경우, 이전 단계에 따라 올바른 권한을 확인하십시오.
단계 3. 보조 사이트 추가
-
보조 사이트의 각 Rails 및 Sidekiq 노드에 SSH로 root로 로그인합니다.
sudo -i -
/etc/gitlab/gitlab.rb파일을 편집하고 사이트에 고유한 이름을 추가합니다. 다음 단계에서 이것이 필요합니다.## ## Geo 사이트의 고유 식별자. 자세한 내용은 ## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings 를 참조하세요. ## gitlab_rails['geo_node_name'] = '<site_name_here>' -
변경 사항이 적용되도록 보조 사이트의 각 Rails 및 Sidekiq 노드를 다시 구성합니다.
gitlab-ctl reconfigure - 기본 노드 GitLab 인스턴스로 이동합니다:
- 왼쪽 사이드바에서 아래쪽에서 관리자를 선택합니다.
- 왼쪽 사이드바에서 Geo > 사이트를 선택합니다.
-
사이트 추가를 선택합니다.
-
이름란에
/etc/gitlab/gitlab.rb의gitlab_rails['geo_node_name']값을 입력합니다. 이 값들은 반드시 글자 그대로 정확하게 일치해야 합니다. -
외부 URL란에
/etc/gitlab/gitlab.rb의external_url값 입력합니다. 이 값들은 반드시 일치해야 하지만 한쪽이/로 끝나거나 다른쪽이 그렇지 않더라도 상관없습니다. - 선택 사항. 내부 URL(선택 사항)에 보조 사이트의 내부 URL을 입력합니다.
- 선택 사항. 보조 사이트가 복제해야 할 그룹 또는 저장소 샤드를 선택합니다. 모두 복제하려면 비워두십시오. 자세한 내용은 selective synchronization을 참조하세요.
- 변경 사항을 저장하여 보조 사이트를 추가합니다.
-
보조 사이트의 각 Rails 및 Sidekiq 노드에 SSH로 접속하여 서비스를 다시 시작합니다.
gitlab-ctl restart다음 명령을 실행하여 Geo 설정에 일반적인 문제가 있는지 확인합니다.
gitlab-rake gitlab:geo:check체크 중에 문제가 발생한다면, 문제 해결 문서를 확인하세요.
-
주 사이트의 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 사이트 도메인에 특정한 인증서인 단일 도메인 인증서: 보조 사이트의 모든 Rails, Sidekiq 및 Gitaly 노드에 이 지침에 따라 보조 사이트 도메인에 유효한 인증서를 생성하여
/etc/gitlab/ssl에 설치하세요.
사용자 지정 인증서를 사용하는 외부 서비스에 연결
외부 서비스에서 사용자 지정 인증서를 사용하는 경우, 해당 인증서의 사본을 주 사이트의 서비스에 액세스해야 하는 모든 노드의 신뢰 저장소에 추가해야 합니다.
본사 사이트가 사용자 지정 인증서를 사용하여 동일한 외부 서비스에 액세스해야 하는 경우, 해당 인증서는 본사 사이트의 신뢰 저장소에 반드시 추가해야 합니다.
본사 사이트가 수신 HTTPS 연결을 위해 사용자 지정 또는 자체 서명 인증서를 사용하는 경우, 해당 인증서는 보조 사이트의 신뢰 저장소에 추가해야 합니다:
-
보조 사이트의 모든 Rails, Sidekiq 및 Gitaly 노드에 SSH로 root로 로그인합니다.
sudo -i -
주 사이트로부터 신뢰된 인증서를 복사합니다:
주 사이트의 루트 사용자를 통해 SSH 트래픽을 제공하는 주 사이트 노드 중 하나에 액세스할 수 있는 경우:
scp root@<primary_site_node_fqdn>:/etc/gitlab/trusted-certs/* /etc/gitlab/trusted-certssudo 권한으로 액세스할 수 있는 사용자를 통해서만 액세스할 수 있는 경우:
# **주** 사이트의 노드에서 실행: 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 -
보조 사이트의 각 업데이트된 Rails, Sidekiq 및 Gitaly 노드를 다시 구성합니다.
sudo gitlab-ctl reconfigure
단계 5. HTTP/HTTPS 및 SSH를 통한 Git 액세스 활성화
Geo는 저장소를 HTTP/HTTPS를 통해 동기화하므로 이 클론 방법을 활성화해야 합니다. 기본적으로 이 기능은 활성화되어 있지만, 기존 사이트를 Geo로 전환하는 경우 확인해야 합니다:
기본 사이트에서:
- 왼쪽 사이드바에서 아래쪽에 있는 관리자(Admin)를 선택합니다.
- 설정 > 일반(General)을 선택합니다.
- 가시성 및 액세스 제어를 확장합니다.
- Git을 SSH로 사용하는 경우:
- “활성화된 Git 액세스 프로토콜”이 “SSH 및 HTTP(S)”로 설정되어 있는지 확인합니다.
- 모든 기본 및 보조(secondary) 사이트에서 데이터베이스에서 승인된 SSH 키를 빠르게 찾는 방법을 구성하는 단계를 따릅니다.
- Git을 SSH로 사용하지 않는 경우 “활성화된 Git 액세스 프로토콜”을 “Only HTTP(S)”로 설정합니다.
단계 6. 보조(secondary) 사이트의 올바른 기능 확인
보조(secondary) 사이트에는 기본(primary) 사이트에 사용한 동일한 자격 증명으로 로그인할 수 있습니다. 로그인한 후에:
- 왼쪽 사이드바에서 아래쪽에 있는 관리자(Admin)를 선택합니다.
- Geo > 사이트(Sites)를 선택합니다.
- 올바른 보조(secondary) Geo 사이트로 식별되었는지, 그리고 Geo가 활성화되었는지 확인합니다.
초기 복제에는 시간이 소요될 수 있습니다. 사이트의 상태나 ‘백필(backfill)’이 아직 진행 중일 수 있습니다. 브라우저에서 기본(primary) 사이트의 Geo Sites 대시보드에서 각 Geo 사이트의 동기화 프로세스를 모니터링할 수 있습니다.
설치가 제대로 작동하지 않는 경우 문제 해결 문서를 확인하세요.
대시보드에서 가장 명백한 문제는 다음과 같습니다:
- 데이터베이스 복제가 제대로 작동하지 않음.
- 인스턴스 간 알림이 작동하지 않음. 이 경우 다음 중 하나가 될 수 있습니다:
- 사용자 정의 인증서 또는 사용자 정의 CA를 사용 중입니다 (문제 해결 문서를 참조하세요).
- 인스턴스가 방화벽으로 보호되어 있습니다 (방화벽 규칙을 확인하세요).
보조(secondary) 사이트를 비활성화하면 동기화 프로세스가 중지됩니다.
여러 저장소 샤드에 대해 기본(primary) 사이트에서 git_data_dirs가 사용자 지정된 경우 각 보조(secondary) 사이트에서 동일한 구성을 복제해야 합니다.
사용자를 Geo 사이트 사용 가이드로 안내하세요.
현재 다음과 같은 항목이 동기화됩니다:
- Git 저장소.
- 위키.
- LFS 객체.
- 이슈, 병합 요청, 스니펫 및 코멘트 첨부 파일.
- 사용자, 그룹 및 프로젝트 아바타.
문제 해결
문제 해결 문서를 참조하세요.
도움말