두 개의 단일 노드 사이트에 대해 Geo 설정하기

Tier: Premium, Ultimate Offering: Self-managed

다음 가이드는 외부 서비스가 설정되지 않은 두 개의 Linux 패키지 인스턴스를 사용하여 두 개의 단일 노드 사이트 설치를 위해 GitLab Geo를 배포하는 방법에 대한 간결한 지침을 제공합니다.

사전 요구 사항:

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

Linux 패키지(Omnibus)에 대한 Geo 설정하기

사전 요구 사항:

기본 사이트 구성하기

  1. GitLab 기본 사이트에 SSH로 접속한 후 root로 로그인합니다:

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

  3. 변경 사항을 적용하기 위해 기본 사이트를 재구성합니다:

    gitlab-ctl reconfigure

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

    gitlab-ctl set-geo-primary-node

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

  5. gitlab 데이터베이스 사용자에 대한 비밀번호를 생성하고 Rail에 새 비밀번호를 사용하도록 업데이트합니다.

    참고:
    gitlab_rails['db_password']와 postgresql['sql_user_password'] 설정에 구성된 값은 일치해야 합니다.
    그러나 postgresql['sql_user_password'] 값만 MD5로 암호화된 비밀번호여야 합니다.
    이에 대한 변경 사항은 Rethink how we handle PostgreSQL passwords in cookbooks에서 논의되고 있습니다.

    1. 원하는 비밀번호의 MD5 해시를 생성합니다:

      gitlab-ctl pg-password-md5 gitlab  
# Enter password: <your_db_password_here>  
# Confirm password: <your_db_password_here>  
# fca0b89a972d69f00eb3ec98a5838484

    2. /etc/gitlab/gitlab.rb를 편집합니다:

      # `gitlab-ctl pg-password-md5 gitlab`로 생성된 해시로 채웁니다  
postgresql['sql_user_password'] = '<md5_hash_of_your_db_password>'  

# Puma 또는 Sidekiq를 실행하는 모든 노드는 아래와 같이 데이터베이스  
# 비밀번호를 지정해야 합니다. 고가용성 설정이 있는 경우, 이  
# 모든 애플리케이션 노드에 있어야 합니다.  
gitlab_rails['db_password'] = '<your_db_password_here>'

  6. 데이터베이스 복제 사용자에 대한 비밀번호를 정의하십시오.
    /etc/gitlab/gitlab.rb의 postgresql['sql_replication_user'] 설정에 정의된 사용자 이름을 사용합니다.
    기본값은 gitlab_replicator입니다.

    1. 원하는 비밀번호의 MD5 해시를 생성합니다:

      gitlab-ctl pg-password-md5 gitlab_replicator  

# Enter password: <your_replication_password_here>  
# Confirm password: <your_replication_password_here>  
# 950233c0dfc2f39c64cf30457c3b7f1e

    2. /etc/gitlab/gitlab.rb를 편집합니다:

      # `gitlab-ctl pg-password-md5 gitlab_replicator`로 생성된 해시로 채웁니다  
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'

    3. 선택 사항. Linux 패키지에서 관리되지 않는 외부 데이터베이스를 사용하는 경우,
      gitlab_replicator 사용자를 수동으로 생성하고 해당 사용자에 대한 비밀번호를 정의해야 합니다:

      --- 'replicator'라는 새로운 사용자 생성  
CREATE USER gitlab_replicator;  

--- 비밀번호 설정/변경 및 복제 권한 부여  
ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';

  7. /etc/gitlab/gitlab.rb에서 역할을 geo_primary_role로 설정합니다:

    ## Geo 기본 역할  
roles(['geo_primary_role'])

  8. PostgreSQL이 네트워크 인터페이스에서 수신 대기하도록 구성합니다:

    1. Geo 사이트의 주소를 찾으려면 Geo 사이트에 SSH로 접속하여 다음을 실행합니다:

      ##  
## 개인 주소  
##  
ip route get 255.255.255.255 | awk '{print "Private address:", $NF; exit}'  

##  
## 공용 주소  
##  
echo "External address: $(curl --silent "ipinfo.io/ip")"

      대부분의 경우, GitLab Geo를 구성하는 데 사용되는 주소는 다음과 같습니다:

      구성 주소
      postgresql['listen_address'] 기본 사이트 공용 또는 VPC 개인 주소.
      postgresql['md5_auth_cidr_addresses'] 기본 및 보조 사이트 공용 또는 VPC 개인 주소.

      Google Cloud Platform, SoftLayer 또는 VPC를 제공하는 다른 공급자를 사용하는 경우,
      postgresql['md5_auth_cidr_addresses'] 및 postgresql['listen_address']에 대해
      기본 및 보조 사이트의 개인 주소(Google Cloud Platform의 “내부 주소”에 해당)를 사용할 수 있습니다.

      참고:
      listen_address에 0.0.0.0 또는 *를 사용해야 하는 경우,
      postgresql['md5_auth_cidr_addresses'] 설정에 127.0.0.1/32를 추가해야
      Rails가 127.0.0.1을 통해 연결할 수 있도록 허용해야 합니다.
      자세한 정보는 문제 5258를 참조하세요.

      네트워크 구성에 따라 제안된 주소가 잘못될 수 있습니다.
      기본 사이트와 보조 사이트가 LAN 또는 가용 영역을 연결하는 가상 네트워크로 연결된 경우,
      Amazon의 VPC나 Google의 VPC와 같이
      postgresql['md5_auth_cidr_addresses']에 대해 보조 사이트 개인 주소를 사용해야 합니다.

    2. /etc/gitlab/gitlab.rb에 다음 줄을 추가합니다.
      IP 주소를 네트워크 구성에 적합한 주소로 바꾸는 것을 잊지 마세요:

      ##  
## 기본 주소  
## - '<primary_node_ip>'를 Geo 기본 노드의 공용 또는 VPC 주소로 교체합니다  
##  
postgresql['listen_address'] = '<primary_site_ip>'  

##  
# 기본 및 보조 IP에서 PostgreSQL 클라이언트 인증 허용. 이 IP는  
# CIDR 형식의 공용 또는 VPC 주소일 수 있습니다, 예: ['198.51.100.1/32', '198.51.100.2/32']  
##  
postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']

  9. PostgreSQL이 개인 주소에서 수신 대기할 때까지 자동 데이터베이스 마이그레이션을
    일시적으로 비활성화합니다. /etc/gitlab/gitlab.rb에서 gitlab_rails['auto_migrate']를 false로 설정합니다:

    ## 자동 데이터베이스 마이그레이션 비활성화  
gitlab_rails['auto_migrate'] = false

  10. 이러한 변경 사항을 적용하기 위해 GitLab을 재구성하고 PostgreSQL을 재시작합니다:

    gitlab-ctl reconfigure  
gitlab-ctl restart postgresql

  11. 마이그레이션을 다시 활성화하려면 /etc/gitlab/gitlab.rb를 편집하고
    gitlab_rails['auto_migrate']를 true로 변경합니다:

    gitlab_rails['auto_migrate'] = true

    파일을 저장하고 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

    PostgreSQL 서버가 원격 연결을 수락하도록 설정되었습니다.

  12. netstat -plnt | grep 5432를 실행하여 PostgreSQL이 포트
    5432에서 기본 사이트의 개인 주소를 수신 대기하고 있는지 확인합니다.

  13. GitLab이 재구성될 때 자동으로 인증서가 생성되었습니다.
    이 인증서는 PostgreSQL 트래픽을 중간자 공격으로부터 보호하는 데 사용됩니다.
    액티브(“중간자”) 공격자로부터 보호하기 위해 인증서를 보조 사이트로 복사합니다:

    1. 기본 사이트에서 server.crt를 복사합니다:

      cat ~gitlab-psql/data/server.crt

    2. 보조 사이트를 구성할 때 사용할 출력을 저장합니다.
      인증서는 민감한 데이터가 아닙니다.

    인증서는 일반적인 PostgreSQL 공통 이름으로 생성됩니다.
    호스트 이름 불일치 오류를 방지하려면 데이터베이스를 복제할 때
    verify-ca 모드를 사용해야 합니다.

보조 서버 구성

  1. GitLab 보조 사이트에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 사이트가 구성되기 전에 명령이 실행되지 않도록 애플리케이션 서버와 Sidekiq를 중지합니다:

    gitlab-ctl stop puma
gitlab-ctl stop sidekiq

  3. 주 사이트의 PostgreSQL 서버에 대한 TCP 연결성 확인:

    gitlab-rake gitlab:tcp_check[<primary_site_ip>,5432]

    이 단계가 실패하면 잘못된 IP 주소를 사용하고 있을 수 있거나, 방화벽이 사이트 접근을 차단하고 있을 수 있습니다. IP 주소를 확인하고 공용 주소와 개인 주소의 차이에 주의하세요. 방화벽이 있는 경우, 보조 사이트가 포트 5432에서 주 사이트에 연결할 수 있도록 허용되어 있는지 확인합니다.

  4. 보조 사이트에서 server.crt라는 파일을 만들고, 주 사이트 구성 시 만든 인증서 복사본을 추가합니다.

    editor server.crt

  5. 보조 사이트에서 PostgreSQL TLS 검증을 설정하기 위해 server.crt를 설치합니다:

    install \
   -D \
   -o gitlab-psql \
   -g gitlab-psql \
   -m 0400 \
   -T server.crt ~gitlab-psql/.postgresql/root.crt

    이제 PostgreSQL은 TLS 연결을 검증할 때 이 정확한 인증서만 인식합니다. 인증서는 개인 키에 접근할 수 있는 사용자가 복제할 수 있으며, 개인 키는 오직 주 사이트에만 존재합니다.

  6. gitlab-psql 사용자가 주 사이트 데이터베이스에 연결할 수 있는지 테스트합니다. 기본 Linux 패키지 이름은 gitlabhq_production입니다:

    sudo \
   -u gitlab-psql /opt/gitlab/embedded/bin/psql \
   --list \
   -U gitlab_replicator \
   -d "dbname=gitlabhq_production sslmode=verify-ca" \
   -W \
   -h <primary_site_ip>

    프롬프트가 나타나면 gitlab_replicator 사용자에게 설정한 평문 비밀번호를 입력합니다. 모든 것이 올바르게 작동했다면, 주 사이트 데이터베이스 목록이 표시됩니다.

  7. /etc/gitlab/gitlab.rb를 편집하고 역할을 geo_secondary_role로 설정합니다:

    ##
## Geo Secondary role
## - Geo를 활성화하기 위해 종속 플래그를 자동으로 구성합니다.
##
roles(['geo_secondary_role'])

    자세한 내용은 Geo 역할을 참조하세요.

  8. PostgreSQL을 구성하기 위해 /etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다:

    ##
## 보조 주소
## - '<secondary_site_ip>'를 Geo 보조 사이트의 공용 또는 VPC 주소로 교체합니다.
##
postgresql['listen_address'] = '<secondary_site_ip>'
postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32']

##
## 데이터베이스 자격 증명 비밀번호 (주 사이트에서 이전에 정의됨)
## - 주 사이트에 정의된 동일한 값을 여기에 반복합니다.
##
postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'
postgresql['sql_user_password'] = '<md5_hash_of_your_db_password>'
gitlab_rails['db_password'] = '<your_db_password_here>'

    IP 주소를 네트워크 구성에 적합한 주소로 교체하는 것을 잊지 마세요.

  9. 변경 사항을 적용하려면 GitLab을 재구성합니다:

    gitlab-ctl reconfigure

  10. IP 주소 변경 사항을 적용하려면 PostgreSQL을 재시작합니다:

    gitlab-ctl restart postgresql

데이터베이스 복제

보조 사이트의 데이터베이스를 기본 사이트의 데이터베이스에 연결합니다.

아래 스크립트를 사용하여 데이터베이스를 복제하고 스트리밍 복제를 위한 필요한 파일을 생성할 수 있습니다.

스크립트는 기본 Linux 패키지 디렉토리를 사용합니다.

기본값을 변경한 경우, 아래 스크립트의 디렉토리 및 경로 이름을 자신의 이름으로 바꿉니다.

caution
복제 스크립트는 오직 보조 사이트에서만 실행해야 합니다.
스크립트는 pg_basebackup을 실행하기 전에 모든 PostgreSQL 데이터를 제거하므로 데이터 손실로 이어질 수 있습니다.

데이터베이스를 복제하려면:

  1. GitLab 보조 사이트에 SSH로 접속하고 root로 로그인합니다:

    sudo -i

  2. 복제 슬롯 이름으로 사용할 데이터베이스에 친화적인 이름을 선택합니다. 예를 들어, 도메인이 secondary.geo.example.com인 경우 secondary_example을 슬롯 이름으로 사용합니다. 복제 슬롯 이름은 소문자, 숫자 및 밑줄 문자만 포함해야 합니다.

  3. 다음 명령을 실행하여 데이터베이스를 백업하고 복원하고 복제를 시작합니다.

    caution
    각 Geo 보조 사이트는 고유한 복제 슬롯 이름이 있어야 합니다.
    두 개의 보조 사이트 간에 동일한 슬롯 이름을 사용하면 PostgreSQL 복제가 깨집니다.
    gitlab-ctl replicate-geo-database \
   --slot-name=<secondary_site_name> \
   --host=<primary_site_ip> \
   --sslmode=verify-ca

    프롬프트가 표시되면 gitlab_replicator에 설정한 평문 비밀번호를 입력합니다.

복제 프로세스가 완료되었습니다.

새로운 보조 사이트 구성

초기 복제 프로세스가 완료된 후 보조 사이트에서 다음 항목의 구성을 진행합니다.

인증된 SSH 키의 빠른 조회

문서를 참조하여 인증된 SSH 키의 빠른 조회를 구성합니다.

빠른 조회는 Geo에 필수입니다.

note
인증은 기본 사이트에서 처리됩니다. 보조 사이트에 대한 사용자 정의 인증을 설정하지 마십시오.
Admin 영역에 대한 접근이 필요한 모든 변경 사항은 기본 사이트에서 이루어져야 합니다.
보조 사이트는 읽기 전용 복사본입니다.

비밀 GitLab 값 수동 복제

GitLab은 /etc/gitlab/gitlab-secrets.json에 여러 비밀 값을 저장합니다.
이 JSON 파일은 각 사이트 노드마다 동일해야 합니다.
비밀 파일은 모든 보조 사이트에 수동으로 복제해야 하며,
이슈 3789에서는 이 동작을 변경할 것을 제안하고 있습니다.

  1. SSH로 기본 사이트의 Rails 노드에 접속하고 아래 명령을 실행합니다:

    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

기본 사이트 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 애플리케이션의 주요 노드):

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

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

      # 기본 사이트의 노드에서 실행:
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

    다음과 유사한 출력이 나와야 합니다:

    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 /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로 접속합니다.

    연결할 수 없는 경우, 올바른 권한이 있는지 확인합니다.

2차 사이트 추가

  1. SSH를 통해 2차 사이트의 각 Rails 및 Sidekiq 노드에 접속하고 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. 변경사항을 적용하기 위해 2차 사이트의 각 Rails 및 Sidekiq 노드를 재구성합니다.

    gitlab-ctl reconfigure
  4. 기본 노드의 GitLab 인스턴스로 이동합니다:
    1. 왼쪽 사이드바의 하단에서 Admin을 선택합니다.
    2. Geo > Sites를 선택합니다.

    3. Add site를 선택합니다.

      2차 사이트 추가

    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. 선택 사항. 2차 사이트에서 복제할 그룹 또는 스토리지 샤드를 선택합니다. 모든 것을 복제하려면 필드를 비워 두세요. 선택적 동기화를 참조하세요.
    8. Save changes를 선택합니다.

  5. 2차 사이트의 각 Rails 및 Sidekiq 노드에 SSH로 접속하고 서비스를 재시작합니다:

    gitlab-ctl restart

  6. Geo 설정에 일반적인 문제가 있는지 확인하려면 다음을 실행합니다:

    gitlab-rake gitlab:geo:check

    체크가 실패하는 경우 문제 해결 문서를 참조하세요.

  7. 2차 사이트에 도달 가능한지 확인하려면 기본 사이트의 Rails 또는 Sidekiq 서버에 SSH로 접속하고 root로 로그인합니다:

    gitlab-rake gitlab:geo:check

    체크가 실패하는 경우 문제 해결 문서를 확인하세요.

2차 사이트가 Geo 관리 페이지에 추가되고 재시작된 후, 사이트는 자동으로 기본 사이트에서 누락된 데이터를 복제하기 시작합니다. 이 과정을 백필이라고 합니다.

이와 동시에, 기본 사이트는 각 2차 사이트에 변경 사항을 알리기 시작하여 2차 사이트가 즉시 알림에 따라 작업을 수행할 수 있습니다.

2차 사이트가 실행 중이고 접근 가능해야 합니다. 기본 사이트와 동일한 자격 증명으로 2차 사이트에 로그인할 수 있습니다.

HTTP/HTTPS 및 SSH를 통한 Git 접근 활성화

Geo는 HTTP/HTTPS를 통해 리포지토리를 동기화하므로, 이 클론 방법이 활성화되어야 합니다. 기본적으로 활성화되어 있습니다.

기존 사이트를 Geo로 변환하는 경우, 클론 방법이 활성화되어 있는지 확인해야 합니다.

기본 사이트에서:

  1. 왼쪽 사이드바의 하단에서 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Visibility and access controls를 확장합니다.
  4. Git을 SSH를 통해 사용하는 경우:
    1. Enabled Git access protocols가 Both SSH and HTTP(S)로 설정되어 있는지 확인합니다.
    2. 기본 및 2차 사이트 모두에서 데이터베이스 내 권한이 있는 SSH 키의 빠른 조회를 따릅니다.
  5. Git을 SSH를 통해 사용하지 않는 경우, Enabled Git access protocols를 Only HTTP(S)로 설정합니다.

보조 사이트의 적절한 기능 확인

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

로그인한 후:

  1. 왼쪽 사이드바에서 하단에 Admin을 선택합니다.
  2. Geo > Sites를 선택합니다.
  3. 해당 사이트가 보조 Geo 사이트로 올바르게 식별되었으며 Geo가 활성화되어 있는지 확인합니다.

초기 복제는 다소 시간이 걸릴 수 있습니다.

주 사이트의 Geo Sites 대시보드에서 각 Geo 사이트의 동기화 프로세스를 모니터링할 수 있습니다.

Geo 대시보드

관련 주제