• 요구 사항
• 제한 사항
• 전체적인 개요
• Linux 패키지 데이터베이스 노드 설정
• 정보 수집
• 주 데이터베이스 구성
• Geo 주 사이트로 차트 배포
• Geo 주 사이트 설정
• 보조 데이터베이스 구성
• 기본 사이트에서 보조 사이트로 시크릿 복사
• Geo 보조 사이트로 차트 배포
• 주요 사이트를 통해 보조 Geo 사이트 추가
• 운영 상태 확인
• 보조 사이트에 대해 별도의 URL 구성(선택 사항)
• 레지스트리
• Cert-manager 및 통합 URL

GitLab Geo를 GitLab 차트로 구성하기

GitLab Geo는 지리적으로 분산된 애플리케이션 배포 기능을 제공합니다.

외부 데이터베이스 서비스를 사용할 수 있지만, 이 문서에서는 가이드의 플랫폼에 중립적인 가이드를 제공하고 gitlab-ctl에 포함된 자동화를 사용하기 위해 PostgreSQL에 대한 Linux 패키지를 사용하는 데 초점을 맞추고 있습니다.

이 가이드에서는 두 클러스터가 동일한 외부 URL을 가지고 있는 것을 전제로 합니다. 이 기능은 차트의 버전 7.3부터 지원됩니다. “Geo 사이트에 대한 통합 URL 설정”을 참조하십시오(https://docs.gitlab.com/ee/administration/geo/secondary_proxy/index.html#set-up-a-unified-url-for-geo-sites). 선택적으로 보조 사이트에 대한 별도의 URL을 구성할 수 있습니다.

참고: Geo의 모든 측면을 설명하는 정의된 용어를 참조하십시오(site 및 node의 주된 차이점)

요구 사항

GitLab Geo를 GitLab Helm 차트와 함께 사용하려면 다음 요구 사항을 충족해야 합니다:

• 외부 PostgreSQL 서비스를 사용해야 합니다(외부 데이터베이스 사용). 차트에 포함된 PostgreSQL은 외부 네트워크에 노출되지 않으며 복제에 필요한 WAL 지원이 없습니다.
• 제공된 데이터베이스는 다음을 지원해야 합니다:
  • 복제 지원
  • 프라이머리 데이터베이스는 프라이머리 사이트 및 모든 보조 데이터베이스 노드에서 접근 가능해야 합니다(복제를 위해)
  • 보조 데이터베이스는 보조 사이트에서만 접근 가능하면 됩니다.
  • 프라이머리 및 보조 데이터베이스 노드 사이에 SSL을 지원해야 합니다.
• 프라이머리 사이트에 모든 보조 사이트가 HTTP(S)로 접근할 수 있어야 합니다. 보조 사이트는 프라이머리 사이트에 HTTP(S)로 접근 가능해야 합니다.
• Geo 실행을 위한 요구 사항의 전체 목록은 Geo를 실행하기 위한 요구 사항을 확인하십시오.

제한 사항

제한 사항의 전체 목록은 제한 사항을 확인하십시오.

전체적인 개요

이 가이드는 Linux 패키지를 사용하여 생성된 2개의 데이터베이스 노드 및 필요한 PostgreSQL 서비스만 구성하고 GitLab Helm 차트의 2개의 배포를 사용합니다. 이는 _최소한_으로 필요한 구성이 의도되어 있습니다. 이 문서에는 응용프로그램에서 데이터베이스로의 SSL, 기타 데이터베이스 제공업체 지원, 보조 사이트를 프라이머리로 승격하는 기능은 포함되어 있지 않습니다.

아래 개요는 순서대로 따라야 합니다:

1. Linux 패키지 데이터베이스 노드 설정
2. Kubernetes 클러스터 설정
3. 정보 수집
4. 프라이머리 데이터베이스 구성
5. Geo 프라이머리 사이트로 차트 배포
6. Geo 프라이머리 사이트 설정
7. 보조 데이터베이스 구성
8. 프라이머리 사이트에서 보조 사이트로 암호 복사
9. Geo 보조 사이트로 차트 배포
10. 프라이머리를 통해 보조 Geo 사이트 추가
11. 운영 상태 확인
12. 보조 사이트를 위한 별도의 URL 구성(선택 사항)
13. 레지스트리
14. Cert-manager 및 통합 URL

Linux 패키지 데이터베이스 노드 설정

이 프로세스에서는 프라이머리 데이터베이스 노드와 보조 데이터베이스 노드 중 2개의 노드가 필요합니다. 어떤 제공업체의 머신 인프라에서도 사용할 수 있습니다. 온프레미스나 클라우드 제공업체에서도 됩니다.

통신이 필요함을 명심해야 합니다:

• 복제를 위한 두 개의 데이터베이스 노드 사이
• 각 데이터베이스 노드와 해당 쿠버네티스 배포 사이:
  • 프라이머리는 TCP 포트 5432를 노출해야 합니다.
  • 보조는 TCP 포트 5432 및 5431을 노출해야 합니다.

Linux 패키지에서 지원되는 운영 체제를 설치한 후에 지정된 database 노드 설정을 설치합니다. 재구성하기 전에 최소한의 구성 파일을 제공하기 위해 설치할 때 EXTERNAL_URL 환경 변수를 제공하지 않도록 하십시오.

운영 체제를 설치하고 GitLab 패키지를 설치한 후에 사용할 서비스를 위한 구성을 생성할 수 있습니다. 그 전에 정보를 수집해야 합니다.

정보 수집

설정을 계속하려면 다음 정보를 다양한 소스에서 수집해야 합니다. 이를 수집하고 나머지 문서에서 사용하기 위해 메모를 작성하세요.

• 주 데이터베이스:
  • IP 주소
  • 호스트명 (선택 사항)
• 보조 데이터베이스:
  • IP 주소
  • 호스트명 (선택 사항)
• 주 클러스터:
  • 외부 URL
  • 내부 URL
  • 노드의 IP 주소
• 보조 클러스터:
  • 내부 URL
  • 노드의 IP 주소
• 데이터베이스 암호(암호는 사전에 정해져 있어야 함):
  • gitlab (postgresql['sql_user_password'], global.psql.password에 사용됨)
  • gitlab_geo (geo_postgresql['sql_user_password'], global.geo.psql.password에 사용됨)
  • gitlab_replicator (복제에 필요)
• GitLab 라이선스 파일

각 클러스터의 내부 URL은 해당 클러스터에 대해 고유해야 합니다. 그래서 모든 클러스터가 다른 모든 클러스터에 요청을 보낼 수 있습니다. 예를 들어:

• 모든 클러스터의 외부 URL: https://gitlab.example.com
• 주 클러스터의 내부 URL: https://london.gitlab.example.com
• 보조 클러스터의 내부 URL: https://shanghai.gitlab.example.com

이 가이드는 DNS 설정을 다루지 않습니다.

gitlab 및 gitlab_geo 데이터베이스 사용자 암호는 두 가지 형태로 존재해야 합니다: 순수한 비밀번호와 PostgreSQL 해시된 비밀번호 형태로. 해시된 형식을 얻으려면 다음 명령을 이용하여 리눅스 패키지 설치 인스턴스 중 하나에서 다음 명령을 실행하세요. 이 명령은 암호를 입력하고 확인한 후에 적절한 해시 값을 확인하고 메모해야 합니다.

1. gitlab-ctl pg-password-md5 gitlab
2. gitlab-ctl pg-password-md5 gitlab_geo

주 데이터베이스 구성

이 섹션은 주 Linux 패키지 설치 데이터베이스 노드에서 수행됩니다.

주 데이터베이스 노드의 Linux 패키지 설치를 구성하려면 다음 예제 구성을 기반으로 작업하세요.

### Geo Primary
external_url 'http://gitlab.example.com'
roles ['geo_primary_role']
# Geo 노드의 고유 식별자입니다.
gitlab_rails['geo_node_name'] = '런던 오피스'
gitlab_rails['auto_migrate'] = false
## 모든 것을 끕니다(기본값이 true이고 여기서는 설정을 false로 변경)
sidekiq['enable']=false
puma['enable']=false
gitlab_workhorse['enable']=false
nginx['enable']=false
geo_logcursor['enable']=false
grafana['enable']=false
gitaly['enable']=false
redis['enable']=false
gitlab_kas['enable']=false
prometheus_monitoring['enable'] = false
## 네트워크용 DB 구성
postgresql['enable'] = true
postgresql['listen_address'] = '0.0.0.0'
postgresql['sql_user_password'] = 'gitlab_user_password_hash'
# !! 주의 !!
# 이 CIDR 주소 목록은 사용자 정의되어야 합니다
# - 주 응용 프로그램 배포
# - 보조 데이터베이스 노드
postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0']

다음을 교체해야 합니다.

• external_url은 주 사이트의 호스트명을 반영하도록 업데이트해야 합니다.
• gitlab_rails['geo_node_name']은 사이트의 고유한 이름으로 교체해야 합니다. 공통 설정에서 이름 필드를 참조하세요.
• gitlab_user_password_hash는 gitlab 비밀번호의 해시 형식으로 대체해야 합니다.
• postgresql['md5_auth_cidr_addresses']는 명시적 IP 주소 또는 CIDR 표기법의 주소 블록 목록으로 업데이트할 수 있습니다.

md5_auth_cidr_addresses는 다음 양식이어야 합니다. [ '127.0.0.1/24', '10.41.0.0/16']. 자동화된 리눅스 패키지는 이를 사용하여 연결하므로 이 목록에 127.0.0.1을 포함해야 합니다. 이 목록의 주소에는 보조 데이터베이스의 IP 주소(호스트명이 아님) 및 주 Kubernetes 클러스터의 모든 노드가 포함되어야 합니다. 이 몭록을 ['0.0.0.0/0']로 남겨둬도 됩니다. 그러나 이것은 최선의 실천이 아닙니다.

위의 구성을 준비한 후:

1. 내용을 /etc/gitlab/gitlab.rb에 넣으세요.
2. gitlab-ctl reconfigure를 실행하세요. TCP에서 서비스가 듣지 않는 문제가 발생하면 직접 gitlab-ctl restart postgresql로 다시 시작하세요.
3. gitlab-ctl set-replication-password를 실행하여 gitlab_replicator 사용자의 암호를 설정하세요.

4. 주 데이터베이스 노드의 공개 인증서를 가져오세요. 이것은 보조 데이터베이스가 복제할 수 있어야 합니다(이 출력을 저장하세요):

   cat ~gitlab-psql/data/server.crt
   

Geo 주 사이트로 차트 배포

이 섹션은 기본 사이트의 Kubernetes 클러스터에서 수행됩니다.

이 차트를 Geo 주 사이트로 배포하려면 이 예제 구성을 시작하십시오:

1. 데이터베이스 암호를 포함하는 시크릿을 생성하여 차트가 사용하도록 합니다. 아래의 PASSWORD를 gitlab 데이터베이스 사용자의 암호로 바꿉니다:

   kubectl --namespace gitlab create secret generic geo --from-literal=postgresql-password=PASSWORD
   

2. 예제 구성을 기반으로 primary.yaml 파일을 생성하고 올바른 값으로 구성을 업데이트합니다:

   ### Geo Primary
   global:
     # 설명은 docs.gitlab.com/charts/charts/globals을 참조합니다
     # 호스트 및 도메인 구성
     hosts:
       domain: example.com
       # 기본 로드 밸런서의 정적 IP를 선택적으로 구성
       # externalIP: 
       # Geo 로드 밸런서의 정적 IP를 선택적으로 구성
       # externalGeoIP:
     # DB 연결 구성
     psql:
       host: geo-1.db.example.com
       port: 5432
       password:
         secret: geo
         key: postgresql-password
     # Geo 구성 (주 사이트)
     geo:
       nodeName: London Office
       enabled: true
       role: primary
   # 내부 Geo 사이트 트래픽용 Geo Nginx 컨트롤러 구성
   nginx-ingress-geo:
     enabled: true
   gitlab:
     webservice:
       # Geo NGINX 컨트롤러 사용
       ingress:
         useGeoClass: true
       # 내부 Geo 트래픽용 Ingress 구성
       extraIngress:
         enabled: true
         hostname: gitlab.london.example.com
         useGeoClass: true
   # 외부 DB, 사용 안 함
   postgresql:
     install: false
   

   • global.hosts.domain
   • global.psql.host
   • global.geo.nodeName은 관리 영역의 Geo 사이트의 이름 필드와 일치해야 합니다
   • nginx-ingress-geo는 이중화된 사이트에서 전달된 Geo 트래픽을 위해 Ingress 컨트롤러를 활성화합니다
   • Geo 트래픽을 위해 주 Geo 사이트의 gitlab.webservice Ingress를 구성합니다
   • SSL/TLS 구성과 같은 추가 설정도 구성합니다:
     • SSL/TLS 구성
     • 외부 Redis 사용
     • 외부 객체 저장소 사용

3. 이 구성을 사용하여 차트를 배포합니다:

   helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f primary.yaml
   

   참고: gitlab 네임스페이스를 사용하고 있다고 가정합니다. 다른 네임스페이스를 사용하려면 문서의 나머지 부분에서 모두 --namespace gitlab을 해당 네임스페이스로 바꿔야 합니다.

4. 배포가 완료되고 응용 프로그램이 온라인 상태가 될 때까지 기다리세요.

5. GitLab에 로그인하여 GitLab 구독을 활성화합니다.

   참고: 이 단계는 Geo가 작동하려면 필수입니다.

Geo 주 사이트 설정

이제 차트가 배포되고 라이선스가 업로드되었으므로 이를 주 사이트로 설정할 수 있습니다. 이를 Toolbox Pod를 통해 수행합니다.

1. Toolbox Pod를 찾습니다.

   kubectl --namespace gitlab get pods -lapp=toolbox
   

2. kubectl exec를 사용하여 gitlab-rake geo:set_primary_node를 실행합니다:

   kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake geo:set_primary_node
   

3. Rails runner 명령을 사용하여 주 사이트의 내부 URL을 설정합니다. 실제 내부 URL로 https://primary.gitlab.example.com를 바꿉니다:

   kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rails runner "GeoNode.primary_node.update!(internal_url: 'https://primary.gitlab.example.com')"
   

4. Geo 구성 상태를 확인합니다:

   kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake gitlab:geo:check
   

   아래와 유사한 출력을 확인해야 합니다:

   WARNING: This version of GitLab depends on gitlab-shell 10.2.0, but you're running Unknown. Please update gitlab-shell.
   Checking Geo ...
   
   GitLab Geo is available ... yes
   GitLab Geo is enabled ... yes
   GitLab Geo secondary database is correctly configured ... not a secondary node
   Database replication enabled? ... not a secondary node
   Database replication working? ... not a secondary node
   GitLab Geo HTTP(S) connectivity ... not a secondary node
   HTTP/HTTPS repository cloning is enabled ... yes
   Machine clock is synchronized ... Exception: getaddrinfo: Servname not supported for ai_socktype
   Git user has default SSH configuration? ... yes
   OpenSSH configured to use AuthorizedKeysCommand ... no
     Reason:
     Cannot find OpenSSH configuration file at: /assets/sshd_config
     Try fixing it:
     If you are not using our official docker containers,
     make sure you have OpenSSH server installed and configured correctly on this system
     For more information see:
     doc/administration/operations/fast_ssh_key_lookup.md
   GitLab configured to disable writing to authorized_keys file ... yes
   GitLab configured to store new projects in hashed storage? ... yes
   All projects are in hashed storage? ... yes
   
   Checking Geo ... Finished
   

   • Kubernetes 컨테이너는 호스트 시계에 액세스할 수 없으므로 Exception: getaddrinfo: Servname not supported for ai_socktype에 대해 걱정하지 마십시오. 이는 괜찮습니다.
   • OpenSSH configured to use AuthorizedKeysCommand ... no 는 예상된 결과입니다. 이 명령은 실제로 다른 곳에서 배포된 gitlab-shell 차트에서 이미 적절하게 구성된 로컬 SSH 서버를 확인하고 있습니다.

보조 데이터베이스 구성

이 섹션은 보조 Linux 패키지 설치 데이터베이스 노드에서 수행됩니다.

보조 데이터베이스 노드의 Linux 패키지 설치를 구성하려면 다음 예제 구성에서 작업하세요.

### 지오 보조
# external_url은 주 클러스터의 external_url과 일치해야 함
external_url 'http://gitlab.example.com'
roles ['geo_secondary_role']
gitlab_rails['enable'] = true
# Geo 노드에 대한 고유 식별자
gitlab_rails['geo_node_name'] = 'Shanghai Office'
gitlab_rails['auto_migrate'] = false
geo_secondary['auto_migrate'] = false
## DB 이외 모든 것을 비활성화
sidekiq['enable']=false
puma['enable']=false
gitlab_workhorse['enable']=false
nginx['enable']=false
geo_logcursor['enable']=false
grafana['enable']=false
gitaly['enable']=false
redis['enable']=false
prometheus_monitoring['enable'] = false
gitlab_kas['enable']=false
## 네트워크용으로 DB 구성
postgresql['enable'] = true
postgresql['listen_address'] = '0.0.0.0'
postgresql['sql_user_password'] = 'gitlab_user_password_hash'
# !! 주의 !!
# 이 CIDR 주소 목록은 사용자 정의해야 함
# - 보조 애플리케이션 배포
# - 보조 데이터베이스 노드
postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0']
geo_postgresql['listen_address'] = '0.0.0.0'
geo_postgresql['sql_user_password'] = 'gitlab_geo_user_password_hash'
# !! 주의 !!
# 이 CIDR 주소 목록은 사용자 정의해야 함
# - 보조 애플리케이션 배포
# - 보조 데이터베이스 노드
geo_postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0']
gitlab_rails['db_password']='gitlab_user_password'

다음을 여러 항목으로 대체해야 합니다.

• gitlab_rails['geo_node_name']은 사이트의 고유한 이름으로 대체해야 합니다. 공통 설정의 이름 필드를 참조하세요.
• gitlab_user_password_hash는 gitlab 암호의 해시된 형식으로 대체되어야 합니다.
• postgresql['md5_auth_cidr_addresses']는 명시적 IP 주소나 CIDR 표기법으로 된 주소 블록 목록으로 업데이트되어야 합니다.
• gitlab_geo_user_password_hash는 gitlab_geo 암호의 해시된 형식으로 대체되어야 합니다.
• geo_postgresql['md5_auth_cidr_addresses']는 명시적 IP 주소나 CIDR 표기법으로 된 주소 블록 목록으로 업데이트되어야 합니다.
• gitlab_user_password를 업데이트해야 하며, 여기서 사용되어 리눅스 패키지가 PostgreSQL 구성을 자동화할 수 있습니다.

md5_auth_cidr_addresses는 다음과 같은 형식이어야 합니다. [ '127.0.0.1/24', '10.41.0.0/16']. 이 목록에 127.0.0.1을 포함하는 것이 중요합니다. 왜냐하면 리눅스 패키지의 자동화가 이를 사용하여 연결하기 때문입니다. 이 목록의 주소에는 보조 쿠버네티스 클러스터의 모든 노드의 IP 주소가 포함되어야 합니다. 이것은 ['0.0.0.0/0']로 남겨둬야 할 수도 있지만, 최선의 방법은 아닙니다.

위의 구성이 준비되면:

1. 주 사이트의 PostgreSQL 노드로의 TCP 연결을 확인합니다.

   openssl s_client -connect <primary_node_ip>:5432 </dev/null
   

   출력에는 다음이 표시되어야 합니다.

   CONNECTED(00000003)
   write:errno=0
   

   참고: 이 단계가 실패하면 잘못된 IP 주소를 사용하거나 방화벽이 서버 접근을 차단하고 있을 수 있습니다. IP 주소를 확인하고 공용 및 사설 주소 간의 차이에 주의하고, 방화벽이 존재하는 경우 보조 PostgreSQL 노드가 주 PostgreSQL 노드에 TCP 포트 5432로 연결할 수 있도록 허용되었는지 확인하세요.

2. 내용을 /etc/gitlab/gitlab.rb에 넣습니다.
3. gitlab-ctl reconfigure를 실행합니다. 서비스가 TCP를 수신하지 않는 문제가 있는 경우 gitlab-ctl restart postgresql을 사용하여 직접 다시 시작해 보세요.
4. 위의 주 PostgreSQL 노드의 인증서 내용을 primary.crt에 넣습니다.

5. 보조 PostgreSQL 노드에서 PostgreSQL TLS 검증 설정을 진행합니다.

   primary.crt 파일을 설치합니다.

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

   이제 PostgreSQL은 TLS 연결을 검증할 때 해당 인증서만 인식합니다. 인증서는 주 PostgreSQL 노드에만 개인 키에 액세스 권한이 있는 사람에 의해서만 복제할 수 있습니다.

6. gitlab-replicator 사용자가 주 사이트의 PostgreSQL에 연결할 수 있는지 테스트합니다 (기본 리눅스 패키지 데이터베이스 이름은 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_database_node_ip>
   

   프롬프트에서 이전에 수집한 gitlab_replicator 사용자의 암호를 입력하세요. 모든 것이 올바르게 작동했다면 주 PostgreSQL 노드의 데이터베이스 목록이 표시됩니다.

   여기서 연결에 실패하면 TLS 구성이 잘못되었을 수 있습니다. 보조 PostgreSQL 노드의 ~gitlab-psql/.postgresql/root.crt의 내용이 주 PostgreSQL 노드의 ~gitlab-psql/data/server.crt의 내용과 일치하는지 확인하세요.

7. 데이터베이스를 복제합니다. PRIMARY_DATABASE_HOST를 귀하의 주 PostgreSQL 노드의 IP나 호스트 이름으로 대체하세요.

   gitlab-ctl replicate-geo-database --slot-name=geo_2 --host=PRIMARY_DATABASE_HOST --sslmode=verify-ca
   

8. 복제가 완료되면 리눅스 패키지를 한 번 더 구성하여 보조 PostgreSQL 노드에 대한 pg_hba.conf가 올바른지 확인합니다.

   gitlab-ctl reconfigure
   

기본 사이트에서 보조 사이트로 시크릿 복사

이제 기본 사이트의 Kubernetes 배치에서 몇 가지 시크릿을 보조 사이트의 Kubernetes 배치로 복사합니다:

• gitlab-geo-gitlab-shell-host-keys
• gitlab-geo-rails-secret
• gitlab-geo-registry-secret(만약 레지스트리 복제가 활성화되어 있다면).

1. kubectl 컨텍스트를 기본으로 변경합니다.

2. 다음 명령으로 기본 배치에서 이러한 시크릿을 수집합니다:

   kubectl get --namespace gitlab -o yaml secret gitlab-geo-gitlab-shell-host-keys > ssh-host-keys.yaml
   kubectl get --namespace gitlab -o yaml secret gitlab-geo-rails-secret > rails-secrets.yaml
   kubectl get --namespace gitlab -o yaml secret gitlab-geo-registry-secret > registry-secrets.yaml
   

3. kubectl 컨텍스트를 보조 사이트의 것으로 변경합니다.

4. 이러한 시크릿을 적용합니다:

   kubectl --namespace gitlab apply -f ssh-host-keys.yaml
   kubectl --namespace gitlab apply -f rails-secrets.yaml
   kubectl --namespace gitlab apply -f registry-secrets.yaml
   

다음으로 데이터베이스 암호를 포함하는 시크릿을 생성합니다. 아래의 암호를 적절한 값으로 대체합니다:

kubectl --namespace gitlab create secret generic geo \
   --from-literal=postgresql-password=gitlab_user_password \
   --from-literal=geo-postgresql-password=gitlab_geo_user_password

Geo 보조 사이트로 차트 배포

이 섹션은 보조 사이트의 Kubernetes 클러스터에서 수행됩니다.

이 차트를 Geo 보조 사이트로 배포하려면 다음 예제 구성에서 시작하십시오.

1. 예제 구성을 기반으로 secondary.yaml 파일을 생성하고 올바른 값으로 구성을 업데이트합니다:

   ## Geo 보조
   global:
     # 문서 참조: docs.gitlab.com/charts/charts/globals
     # 호스트 및 도메인 구성
     hosts:
       domain: shanghai.example.com
       # 통합 URL 사용(기본 사이트와 동일한 외부 URL 사용)
       gitlab:
         name: gitlab.example.com
     # DB 연결 구성
     psql:
       host: geo-2.db.example.com
       port: 5432
       password:
         secret: geo
         key: postgresql-password
     # geo(보조) 구성
     geo:
       enabled: true
       role: secondary
       nodeName: Shanghai Office
       psql:
         host: geo-2.db.example.com
         port: 5431
         password:
           secret: geo
           key: geo-postgresql-password
   gitlab:
     webservice:
       # 내부 Geo 트래픽을 위한 Ingress 구성
       extraIngress:
         enabled: true
         hostname: shanghai.gitlab.example.com
   # 외부 DB 사용 불가
   postgresql:
     install: false
   

   • global.hosts.domain
   • global.psql.host
   • global.geo.psql.host
   • global.geo.nodeName은 반드시 관리 영역의 Geo 사이트의 이름 필드 와 정확히 일치해아 합니다
   • nginx-ingress-geo는 트래픽을 미리 구성된 인그레스 컨트롤러로 구성합니다
   • SSL/TLS 구성 설정
   • 외부 Redis 사용 설정
   • 외부 오브젝트 스토리지 사용 설정
   • 외부 데이터베이스의 경우, global.psql.host는 보조 읽기 전용 레플리카 데이터베이스이며, global.geo.psql.host는 Geo 추적 데이터베이스입니다

2. 이 구성을 사용하여 차트를 배포합니다:

   helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f secondary.yaml
   

3. 배포가 완료되고 애플리케이션이 온라인 상태가 될 때까지 기다립니다.

주요 사이트를 통해 보조 Geo 사이트 추가

이제 데이터베이스가 구성되고 애플리케이션이 배포되었으므로 주요 사이트에 보조 사이트가 존재함을 알려야 합니다:

1. 기본 사이트를 방문합니다.
2. 왼쪽 사이드바에서 맨 아래 관리 영역을 선택합니다.
3. Geo > 사이트 추가를 선택합니다.
4. 보조 사이트를 추가합니다. URL에는 전체 GitLab URL을 사용합니다.
5. 보조 사이트의 global.geo.nodeName과 일치하는 이름을 입력합니다. 이 값은 한 문자도 빠짐없이 정확히 일치해야 합니다.
6. 내부 URL을 입력합니다. 예: https://shanghai.gitlab.example.com.
7. 선택 사항으로, 보조 사이트가 복제해야 하는 그룹이나 스토리지 샤드를 선택합니다. 모두 복제하려면 비워 둡니다.
8. 노드 추가를 선택합니다.

보조 사이트가 관리 패널에 추가되면 주요 사이트에서 누락된 데이터를 자동으로 복제합니다. 이 프로세스를 “백필”이라고 합니다. 한편, 주요 사이트는 각 보조 사이트에 변경 사항을 통지하여 보조 사이트가 이러한 변경 사항을 신속하게 복제하도록 합니다.

운영 상태 확인

마지막 단계는 툴박스 Pod를 통해 완전히 구성된 이준 구성을 보조 사이트에서 두 번 확인하는 것입니다.

1. 툴박스 Pod 찾기:

   kubectl --namespace gitlab get pods -lapp=toolbox
   

2. kubectl exec를 사용하여 Pod에 연결:

   kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- bash -l
   

3. Geo 구성 상태 확인:

   gitlab-rake gitlab:geo:check
   

   아래와 유사한 출력을 확인해야 합니다:

   WARNING: This version of GitLab depends on gitlab-shell 10.2.0, but you're running Unknown. Please update gitlab-shell.
   Checking Geo ...
   
   GitLab Geo is available ... yes
   GitLab Geo is enabled ... yes
   GitLab Geo secondary database is correctly configured ... yes
   Database replication enabled? ... yes
   Database replication working? ... yes
   GitLab Geo HTTP(S) connectivity ...
   * Can connect to the primary node ... yes
   HTTP/HTTPS repository cloning is enabled ... yes
   Machine clock is synchronized ... Exception: getaddrinfo: Servname not supported for ai_socktype
   Git user has default SSH configuration? ... yes
   OpenSSH configured to use AuthorizedKeysCommand ... no
     Reason:
     Cannot find OpenSSH configuration file at: /assets/sshd_config
     Try fixing it:
     If you are not using our official docker containers,
     make sure you have OpenSSH server installed and configured correctly on this system
     For more information see:
     doc/administration/operations/fast_ssh_key_lookup.md
   GitLab configured to disable writing to authorized_keys file ... yes
   GitLab configured to store new projects in hashed storage? ... yes
   All projects are in hashed storage? ... yes
   
   Checking Geo ... Finished
   

   • Exception: getaddrinfo: Servname not supported for ai_socktype에 대해 걱정하지 마십시오. 이는 쿠버네티스 컨테이너가 호스트 시계에 액세스할 수 없기 때문입니다. 이것은 괜찮습니다.
   • OpenSSH configured to use AuthorizedKeysCommand ... no는 _예상대로_입니다. 이 Rake 작업은 실제로 다른 곳에 배포된 gitlab-shell 차트에 이미 적절히 구성된 로컬 SSH 서버를 확인합니다.

보조 사이트에 대해 별도의 URL 구성(선택 사항)

일반적으로 기본 사이트와 보조 사이트를 위한 단일 통합 URL이 사용자에게 더 편리합니다. 예를 들어 다음과 같은 작업을 수행할 수 있습니다:

• 두 사이트 모두 로드 밸런서 뒤에 배치합니다.
• 클라우드 제공업체의 DNS 기능을 사용하여 사용자를 가장 가까운 사이트로 라우팅합니다.

일부 경우에는 사용자가 방문할 사이트를 직접 선택할 수 있도록 하려고 할 수도 있습니다. 이를 위해 보조 Geo 사이트를 고유한 외부 URL을 사용하도록 구성할 수 있습니다. 예를 들어:

• 기본 클러스터의 외부 URL: https://gitlab.example.com
• 보조 클러스터의 외부 URL: https://shanghai.gitlab.example.com

1. secondary.yaml을 수정하고 보조 클러스터의 외부 URL을 업데이트하여 webservice 차트가 해당 요청을 처리할 수 있도록 합니다:

   global:
     # docs.gitlab.com/charts/charts/globals 참조
     # 호스트 및 도메인 구성
     hosts:
       domain: example.com
       # 보조 사이트에 대한 고유한 외부 URL 사용
       gitlab:
         name: shanghai.gitlab.example.com
   

2. 보조 사이트의 외부 URL을 GitLab에서 업데이트하여 필요한 곳에서 해당 URL을 사용할 수 있도록 합니다:
   • 관리자 UI 사용:
     1. 기본 사이트 방문.
     2. 왼쪽 사이드바에서 맨 아래에 관리 영역을 선택합니다.
     3. Geo > Sites를 선택합니다.
     4. 보조 사이트 편집을 선택합니다.
     5. 예를 들어 https://shanghai.gitlab.example.com과 같이 외부 URL을 수정합니다.
     6. 변경 사항 저장을 선택합니다.
   • Rails 러너 명령 사용:

     1. 기본 사이트의 툴박스 컨테이너에서:

        kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rails runner "GeoNode.secondary_nodes.last.update!(url: 'https://shanghai.gitlab.example.com')"
        

3. 보조 사이트 차트 재배포:

   helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f secondary.yaml
   

4. 배포 완료 및 응용 프로그램 온라인 상태 대기.

레지스트리

보조 레지스트리를 기본 레지스트리와 동기화하려면 레지스트리 복제를 구성할 수 있습니다. 이때 알림 시크릿을 사용합니다.

Cert-manager 및 통합 URL

Geo의 통합 URL은 일반적으로 지리적 위치 인식 라우팅과 함께 사용됩니다(예: Amazon Route 53 또는 Google Cloud DNS 사용). 이는 도메인 이름이 귀하의 관리하에 있는지를 검증하는 데 HTTP01 챌린지를 사용할 경우 문제를 발생시킬 수 있습니다.

한 Geo 사이트에 대한 인증서를 요청할 때 Let’s Encrypt는 DNS 이름을 요청한 Geo 사이트로 해석해야 합니다. DNS가 다른 Geo 사이트로 해석되면 통합 URL에 대한 인증서가 발급되거나 새로 고침되지 않을 수 있습니다.

cert-manager로 신뢰할 수 있는 방법으로 인증서를 생성하고 새로 고침하려면 챌린지 네임서버를 설정하거나 DNS01 Issuer를 구성하세요.