다음 가이드는 외부 서비스 없이 두 개의 Linux 패키지 인스턴스를 사용하여 두 단일 노드 사이트 설치에 GitLab Geo를 배포하는 방법에 대한 간결한 지침을 제공합니다. 이 가이드는 Docker 기반 설치에도 적용 가능합니다.

사전 요구사항:

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

Linux 패키지(Omnibus)용 Geo 설정#

사전 요구사항:

• pg_basebackup 도구가 포함된 PostgreSQL 12 이상을 사용합니다.

기본 사이트 구성#

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

   sudo -i
   

2. GitLab을 업그레이드할 때 의도하지 않은 다운타임을 방지하기 위해 자동 PostgreSQL 업그레이드를 거부합니다. Geo로 PostgreSQL을 업그레이드할 때 알려진 주의사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다. 결과적으로 앞으로는 PostgreSQL 업그레이드가 정기적인 유지 관리 활동의 일부가 되도록 해야 합니다.

3. /etc/gitlab/gitlab.rb에 고유한 Geo 사이트 이름을 추가합니다:

   ##
   ## The unique identifier for the Geo site. See
   ## https://docs.gitlab.com/administration/geo_sites/#common-settings
   ##
   gitlab_rails['geo_node_name'] = '<site_name_here>'
   

4. 변경 사항을 적용하려면 기본 사이트를 재구성합니다:

   gitlab-ctl reconfigure
   

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

   gitlab-ctl set-geo-primary-node
   

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

6. 완전한 기본 사이트에서 구성 예시를 복사합니다.

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

   [!note] gitlab_rails['db_password'] 및 postgresql['sql_user_password'] 설정에 구성된 값이 일치해야 합니다. 그러나 MD5 암호화된 비밀번호는 postgresql['sql_user_password'] 값만 사용해야 합니다. 이에 대한 변경은 쿡북에서 PostgreSQL 비밀번호 처리 방법 재고에서 논의 중입니다.

   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를 편집합니다:

      # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab`
      postgresql['sql_user_password'] = '<md5_hash_of_your_db_password>'
      
      # Every node that runs Puma or Sidekiq needs to have the database
      # password specified as below. If you have a high-availability setup, this
      # must be present in all application nodes.
      gitlab_rails['db_password'] = '<your_db_password_here>'
      

8. 데이터베이스 복제 사용자의 비밀번호를 정의합니다. /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를 편집합니다:

      # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator`
      postgresql['sql_replication_password'] = '<md5_hash_of_your_replication_password>'
      

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

      --- Create a new user 'replicator'
      CREATE USER gitlab_replicator;
      
      --- Set/change a password and grants replication privilege
      ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';
      

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

   ## Geo Primary role
   roles(['geo_primary_role'])
   

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

    1. Geo 사이트의 주소를 조회하려면 Geo 사이트에 SSH로 접속하고 실행합니다:

       ##
       ## Private address
       ##
       ip route get 255.255.255.255 | awk '{print "Private address:", $NF; exit}'
       
       ##
       ## Public address
       ##
       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의 "내부 주소"에 해당)를 사용할 수 있습니다.

       [!note] listen_address로 0.0.0.0 또는 *를 사용해야 하는 경우 Rails가 127.0.0.1을 통해 연결할 수 있도록 postgresql['md5_auth_cidr_addresses'] 설정에 127.0.0.1/32도 추가해야 합니다. 자세한 내용은 이슈 5258을 참조하세요.

       네트워크 구성에 따라 제안된 주소가 올바르지 않을 수 있습니다. 기본 및 보조 사이트가 로컬 영역 네트워크 또는 Amazon VPC나 Google VPC와 같은 가용성 영역을 연결하는 가상 네트워크를 통해 연결하는 경우 postgresql['md5_auth_cidr_addresses']에 보조 사이트 프라이빗 주소를 사용해야 합니다.

    2. /etc/gitlab/gitlab.rb에 다음 줄을 추가합니다. IP 주소를 네트워크 구성에 맞는 주소로 교체합니다:

       ##
       ## Primary address
       ## - replace '<primary_node_ip>' with the public or VPC address of your Geo primary node
       ##
       postgresql['listen_address'] = '<primary_site_ip>'
       
       ##
       # Allow PostgreSQL client authentication from the primary and secondary IPs. These IPs may be
       # public or VPC addresses in CIDR format, for example ['198.51.100.1/32', '198.51.100.2/32']
       ##
       postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']
       

11. PostgreSQL이 재시작되어 프라이빗 주소에서 수신할 때까지 자동 데이터베이스 마이그레이션을 일시적으로 비활성화합니다. /etc/gitlab/gitlab.rb에서 gitlab_rails['auto_migrate']를 false로 설정합니다:

    ## Disable automatic database migrations
    gitlab_rails['auto_migrate'] = false
    

12. 이러한 변경 사항을 적용하려면 GitLab을 재구성하고 PostgreSQL을 재시작합니다:

    gitlab-ctl reconfigure
    gitlab-ctl restart postgresql
    

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

    gitlab_rails['auto_migrate'] = true
    

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

    gitlab-ctl reconfigure
    

    PostgreSQL 서버는 원격 연결을 수락하도록 설정됩니다.

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

15. GitLab이 재구성될 때 인증서가 자동으로 생성되었습니다. 인증서는 도청자로부터 PostgreSQL 트래픽을 보호하기 위해 자동으로 사용됩니다. 능동적("중간자") 공격자로부터 보호하기 위해 인증서를 보조 사이트에 복사합니다:

    1. 기본 사이트에서 server.crt의 복사본을 만듭니다:

       cat ~gitlab-psql/data/server.crt
       

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

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

보조 서버 구성#

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

   sudo -i
   

2. GitLab을 업그레이드할 때 의도하지 않은 다운타임을 방지하기 위해 자동 PostgreSQL 업그레이드를 거부합니다. Geo로 PostgreSQL을 업그레이드할 때 알려진 주의사항을 숙지하세요. 특히 대규모 환경의 경우 PostgreSQL 업그레이드는 신중하게 계획하고 실행해야 합니다.

3. 사이트가 구성되기 전에 명령이 실행되는 것을 방지하려면 애플리케이션 서버와 Sidekiq를 중지합니다:

   gitlab-ctl stop puma
   gitlab-ctl stop sidekiq
   

4. 기본 사이트 PostgreSQL 서버에 대한 TCP 연결을 확인합니다:

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

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

5. 보조 사이트에서 server.crt라는 파일을 생성하고 기본 사이트를 구성할 때 만든 인증서의 복사본을 추가합니다.

   editor server.crt
   

6. 보조 사이트에서 PostgreSQL TLS 검증을 설정하려면 server.crt를 설치합니다:

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

   이제 PostgreSQL은 TLS 연결을 확인할 때 이 정확한 인증서만 인식합니다. 인증서는 기본 사이트에만 있는 개인 키에 액세스하는 사람이 복제할 수 있습니다.

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

   Linux packageDocker

    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>
    ```

</div>

<div class="tab-panel" data-tab-index="1">

```shell
    docker exec -it <container_name> su - gitlab-psql -c '/opt/gitlab/embedded/bin/psql \
        --list \
        -U gitlab_replicator \
        -d "dbname=gitlabhq_production sslmode=verify-ca" \
        -W \
        -h <primary_site_ip>'
    ```

</div>

</div>

   메시지가 표시되면 `gitlab_replicator` 사용자에 대해 설정한 일반 텍스트 비밀번호를 입력합니다. 모든 것이 올바르게 작동하면 기본 사이트 데이터베이스 목록이 표시됩니다.

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

   ```ruby
   ##
   ## Geo Secondary role
   ## - configure dependent flags automatically to enable Geo
   ##
   roles(['geo_secondary_role'])

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

1. PostgreSQL을 구성하려면 /etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다:

   ##
   ## Secondary address
   ## - replace '<secondary_site_ip>' with the public or VPC address of your Geo secondary site
   ##
   postgresql['listen_address'] = '<secondary_site_ip>'
   postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32']
   
   ##
   ## Database credentials password (defined previously in primary site)
   ## - replicate same values here as defined in primary site
   ##
   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 주소를 네트워크 구성에 맞는 주소로 교체합니다.

2. 완전한 보조 사이트에서 구성 예시를 복사합니다.

3. 변경 사항을 적용하려면 파일을 저장하고 GitLab을 재구성합니다:

   gitlab-ctl reconfigure
   

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

   gitlab-ctl restart postgresql
   

데이터베이스 복제#

보조 사이트의 데이터베이스를 기본 사이트의 데이터베이스에 연결합니다. 아래 스크립트를 사용하여 데이터베이스를 복제하고 스트리밍 복제에 필요한 파일을 생성할 수 있습니다.

이 스크립트는 기본 Linux 패키지 디렉토리를 사용합니다. 기본값을 변경한 경우 아래 스크립트의 디렉토리와 경로 이름을 직접 이름으로 교체합니다.

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

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

   sudo -i
   

2. 보조 사이트가 복제 슬롯 이름으로 사용할 데이터베이스 친화적인 이름을 선택합니다. 예를 들어 도메인이 secondary.geo.example.com인 경우 슬롯 이름으로 secondary_example을 사용합니다.

   복제 슬롯 이름은 소문자, 숫자, 밑줄 문자만 포함해야 합니다.

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

   [!warning] 각 Geo 보조 사이트에는 고유한 복제 슬롯 이름이 있어야 합니다. 두 보조 사이트 간에 동일한 슬롯 이름을 사용하면 PostgreSQL 복제가 중단됩니다.

   gitlab-ctl replicate-geo-database \
      --slot-name=<secondary_slot_name> \
      --host=<primary_site_ip> \
      --sslmode=verify-ca
   

   메시지가 표시되면 gitlab_replicator에 설정한 일반 텍스트 비밀번호를 입력합니다.

복제 프로세스가 완료됩니다.

새 보조 사이트 구성#

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

승인된 SSH 키의 빠른 조회#

승인된 SSH 키의 빠른 조회 구성 문서를 따르세요.

빠른 조회는 Geo에 필요합니다.

GitLab 비밀 값 수동 복제#

GitLab은 /etc/gitlab/gitlab-secrets.json에 여러 비밀 값을 저장합니다. 이 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
   
   # paste the output of the `cat` command you ran on the primary
   # save and exit
   

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 애플리케이션 노드):

     # Run this from the secondary site, change `<primary_site_fqdn>` for the IP or FQDN of the server
     scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
     

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

     # Run this from the node on your primary site:
     sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
     
     # Run this on each node on your secondary site:
     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. 기존 개인 키에 대한 올바른 공개 키가 있는지 확인합니다:

   # This will print the fingerprint for private keys:
   for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
   
   # This will print the fingerprint for public keys:
   for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
   

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

7. 각 보조 사이트 노드에서 sshd를 재시작합니다:

   # Debian or Ubuntu installations
   sudo service ssh reload
   
   # CentOS installations
   sudo service sshd reload
   

8. SSH가 여전히 작동하는지 확인하려면 새 터미널에서 GitLab 보조 서버에 SSH로 접속합니다. 연결할 수 없는 경우 올바른 권한이 있는지 확인합니다.

보조 사이트 추가#

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

   sudo -i
   

2. /etc/gitlab/gitlab.rb를 편집하고 사이트에 고유한 이름을 추가합니다.

   ##
   ## The unique identifier for the Geo site. See
   ## https://docs.gitlab.com/administration/geo_sites/#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를 선택합니다.

      

   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
   

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

   gitlab-rake gitlab:geo:check
   

   점검이 실패하면 문제 해결 문서를 참조하세요.

7. 보조 사이트에 도달할 수 있는지 확인하려면 기본 사이트의 Rails 또는 Sidekiq 서버에 SSH로 접속하고 root로 로그인합니다:

   gitlab-rake gitlab:geo:check
   

   점검이 실패하면 문제 해결 문서를 확인합니다.

보조 사이트가 Geo 관리 페이지에 추가되고 재시작된 후 사이트는 백필(backfill)이라는 프로세스에서 기본 사이트의 누락된 데이터를 자동으로 복제하기 시작합니다.

한편 기본 사이트는 각 보조 사이트에 변경 사항을 알리기 시작하므로 보조 사이트가 즉시 알림에 따라 동작할 수 있습니다.

보조 사이트가 실행 중이고 액세스 가능한지 확인합니다. 기본 사이트에 사용된 것과 동일한 자격 증명으로 보조 사이트에 로그인할 수 있습니다.

허용된 ActionCable 오리진으로 기본 및 보조 URL 추가#

이 단계를 통해 기본 및 보조 사이트에서 웹소켓이 원활하게 작동합니다.

1. 사이트(기본 및 보조)의 외부 URL을 수집합니다. 위 섹션에서 언급된 것처럼 Admin 영역의 Sites 페이지에서 찾을 수 있습니다.

2. 기본 사이트의 각 Rails 및 Sidekiq 노드에 SSH로 접속하고 root로 로그인합니다:

   sudo -i
   

3. 1단계에서 수집한 URL을 action_cable_allowed_origins 설정에 추가하도록 /etc/gitlab/gitlab.rb를 편집합니다:

   gitlab_rails['action_cable_allowed_origins'] = ['https://secondary.example.com', 'https://primary.example.com']
   

4. 변경 사항을 적용하고 서비스를 재시작하려면 각 Rails 및 Sidekiq 노드를 재구성합니다:

   gitlab-ctl reconfigure
   gitlab-ctl restart
   

HTTP/HTTPS 및 SSH를 통한 Git 액세스 활성화#

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

기본 사이트에서:

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

보조 사이트의 올바른 기능 확인#

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

로그인 후:

1. 오른쪽 상단 모서리에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Geo > Sites를 선택합니다.
3. 사이트가 보조 Geo 사이트로 올바르게 식별되고 Geo가 활성화되어 있는지 확인합니다.

초기 복제에는 시간이 걸릴 수 있습니다. 기본 사이트에서 각 Geo 사이트의 동기화 프로세스를 모니터링할 수 있습니다.

브라우저에서 기본 사이트 Geo Sites 대시보드를 통해 확인합니다.

구성 예시#

완전한 기본 사이트#

이 완전한 gitlab.rb 구성 예시는 Geo 기본 사이트에 사용됩니다:

# Primary site configuration example

## Geo Primary role
roles(['geo_primary_role'])

## The unique identifier for the Geo site
gitlab_rails['geo_node_name'] = 'headquarters'

## External URL
external_url 'https://gitlab.example.com'

## Database configuration
gitlab_rails['db_password'] = 'your_database_password_here'
postgresql['sql_user_password'] = 'md5_hash_of_your_database_password'
postgresql['sql_replication_password'] = 'md5_hash_of_your_replication_password'

## PostgreSQL network configuration
postgresql['listen_address'] = '10.0.1.10'  # Primary site IP
postgresql['md5_auth_cidr_addresses'] = ['10.0.1.10/32', '10.0.2.10/32']  # Primary and secondary IPs

## Disable automatic migrations (handled centrally, and to avoid unplanned downtime)
gitlab_rails['auto_migrate'] = false

## SSL/TLS configuration
nginx['listen_port'] = 80
nginx['listen_https'] = false
letsencrypt['enable'] = false

## Object Storage configuration (optional)
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'us-east-1',
  'aws_access_key_id' => 'your_access_key',
  'aws_secret_access_key' => 'your_secret_key'
}

## Monitoring configuration (optional)
node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '10.0.0.0/8']

## Gitaly configuration
gitaly['configuration'] = {
  prometheus_listen_addr: '0.0.0.0:9236',
}

## ActionCable allowed origins
gitlab_rails['action_cable_allowed_origins'] = ['https://secondary.example.com', 'https://primary.example.com']

완전한 보조 사이트#

이 완전한 gitlab.rb 구성 예시는 Geo 보조 사이트를 위한 것입니다:

# Secondary site configuration example

## Geo Secondary role
roles(['geo_secondary_role'])

## The unique identifier for the Geo site
gitlab_rails['geo_node_name'] = 'location-2'

## External URL (can be the same as primary for unified URL setup)
external_url 'https://gitlab.example.com'

## Database configuration
gitlab_rails['db_password'] = 'your_database_password_here'
postgresql['sql_user_password'] = 'md5_hash_of_your_database_password'
postgresql['sql_replication_password'] = 'md5_hash_of_your_replication_password'

## PostgreSQL network configuration
postgresql['listen_address'] = '10.0.2.10'  # Secondary site IP
postgresql['md5_auth_cidr_addresses'] = ['10.0.2.10/32']

## SSL/TLS configuration
nginx['listen_port'] = 80
nginx['listen_https'] = false
letsencrypt['enable'] = false

## Object Storage configuration (must match primary)
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'us-east-1',
  'aws_access_key_id' => 'your_access_key',
  'aws_secret_access_key' => 'your_secret_key'
}

## Monitoring configuration (optional)
node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '10.0.0.0/8']

## Gitaly configuration
gitaly['configuration'] = {
  prometheus_listen_addr: '0.0.0.0:9236',
}

관련 주제#

• Geo 문제 해결