• 요구 사항
• 제한 사항
• 종합
• Linux 패키지 데이터베이스 노드 설정
• Kubernetes 클러스터 설정
• 정보 수집
• 기본 데이터베이스 구성
• Geo 프라이머리 사이트로 차트 배포
• Geo 주 사이트 설정
• 보조 데이터베이스 구성
• Primary 사이트에서 보조 사이트로 비밀 복사
• Geo 보조 사이트로 차트 배포
• Primary를 통해 보조 Geo 사이트 추가
• 운영 상태 확인
• 별도의 URL을 사용하여 보조 사이트 구성하기 (선택 사항)
• 레지스트리
• Cert-manager 및 통합 URL

GitLab 지오와 GitLab 차트 구성

GitLab 지오는 지리적으로 분산된 응용 프로그램 배포를 가능하게 합니다.

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

이 가이드에서는 두 클러스터가 같은 외부 URL을 갖습니다. 이 기능은 버전 7.3부터 차트에서 지원됩니다. Geo 사이트에 대한 통합 URL 설정을 참조하세요. (선택 사항) 별도의 URL을 보조 사이트에 구성할 수 있습니다.

참고: Geo의 모든 측면을 설명하려면 정의된 용어를 참조하십시오. (주로 site와 node의 구분).

요구 사항

GitLab Helm 차트를 사용하여 GitLab Geo를 사용하려면 다음 요구 사항을 충족해야 합니다.

• 외부 PostgreSQL(external-db/index.md 사용) 서비스를 사용해야 합니다. 이유는 차트에 포함된 PostgreSQL이 외부 네트워크에 노출되지 않으며 복제에 필요한 WAL 지원이 없기 때문입니다.
• 제공된 데이터베이스는 다음을 지원해야 합니다.
  • 복제 지원
  • Primary 데이터베이스는 Primary 사이트 및 모든 Secondary 데이터베이스 노드 (복제용)에서 액세스 가능해야 합니다.
  • Secondary 데이터베이스는 보조 사이트에서만 액세스 할 수 있어야 합니다.
  • Primary 및 Secondary 데이터베이스 노드 간의 SSL 지원.
• Primary 사이트는 모든 보조 사이트가 HTTP(S)를 통해 액세스 할 수 있어야 합니다. 보조 사이트는 Primary 사이트로부터 HTTP(S)를 통해 액세스 할 수 있어야 합니다.
• Geo를 실행하기 위한 요구 사항에 대한 전체 목록은 Geo 실행 요구 사항을 참조하십시오.

제한 사항

Geo 제한 사항을 확인하십시오. 제한 사항의 완전한 목록을 보실 수 있습니다.

종합

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

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

1. Linux 패키지 데이터베이스 노드 설정
2. Kubernetes 클러스터 설정
3. 정보 수집
4. Primary 데이터베이스 구성
5. Geo Primary 사이트로 차트 배포
6. Geo Primary 사이트 설정
7. Secondary 데이터베이스 구성
8. Primary 사이트에서 보조 사이트로 비밀 복사
9. Geo Secondary 사이트로 차트 배포
10. 주 사이트를 통해 보조 Geo 사이트 추가
11. 운영 상태 확인
12. 별도의 URL을 보조 사이트에 구성 (선택 사항)
13. Registry
14. Cert-manager와 통합 URL

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

이 과정에서는 Primary 데이터베이스 노드와 Secondary 데이터베이스 노드 중 2개의 노드가 필요합니다. 하나는 Primary 데이터베이스 노드이고, 다른 하나는 Secondary 데이터베이스 노드입니다. 기계 인프라의 제공 업체 또는 온프레미스 또는 클라우드 제공 업체에서 사용할 수 있습니다.

통신이 필요한 사항에 유의하십시오:

• 복제를 위한 두 데이터베이스 노드 간
• 각 데이터베이스 노드와 해당 Kubernetes 배포 간:
  • Primary의 TCP 포트 5432 를 노출해야 합니다.
  • Secondary는 TCP 포트 5432 및 5431 을 노출해야 합니다.

Linux 패키지가 지원하는 운영 체제를 설치한 후, 해당 패키지를 설치하십시오. 구성 파일을 다시 구성하기 전에 환경 변수인 EXTERNAL_URL을 제공하지 마십시오.

운영 체제와 GitLab 패키지를 설치한 후 해당 서비스의 구성을 생성할 수 있습니다. 이를 하기 전에 정보를 수집해야 합니다.

Kubernetes 클러스터 설정

이 과정에서는 두 Kubernetes 클러스터를 사용해야 합니다. 제공 업체, 온프레미스 또는 클라우드 제공 업체 모두에서 사용할 수 있습니다.

통신이 필요한 사항에 유의하십시오: - 각 데이터베이스 노드와 통신: - Primary는 외부 TCP 5432 로 연결되어야 합니다. - Secondary는 TCP 5432 및 5431로 외부와 연결되어야 합니다. - 양쪽 Kubernetes Ingress 간 HTTPS 연결.

프로비저닝된 각 클러스터는 다음(들)을 가져야 합니다: - 이러한 차트의 기본적인 설치를 지원하기에 충분한 자원 - 영구 스토리지에 대한 액세스: - 외부 객체 스토리지를 사용하는 경우 MinIO가 필요하지 않음 - 외부 Gitaly를 사용하는 경우 Gitaly가 필요하지 않음 - 외부 Redis를 사용하는 경우 Redis가 필요하지 않음

정보 수집

설정을 계속하기 위해 다양한 원본에서 아래 정보를 수집해야 합니다. 이 정보를 수집하여 기록해두십시오. 이 정보는 나중의 절차에서 사용됩니다.

• Primary 데이터베이스:
  • IP 주소
  • 호스트 이름(선택 사항)
• Secondary 데이터베이스:
  • IP 주소
  • 호스트 이름(선택 사항)
• Primary 클러스터:
  • 외부 URL
  • 내부 URL
  • 노드의 IP 주소
• Secondary 클러스터:
  • 내부 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 - Primary 클러스터의 내부 URL: https://london.gitlab.example.com - Secondary 클러스터의 내부 URL: https://shanghai.gitlab.example.com

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

gitlab와 gitlab_geo 데이터베이스 사용자 암호는 데이터베이스 사용자 암호의 것으로 확인해야 합니다. 두 형태로 존재해야 합니다: 순수한 암호 및 PostgreSQL 해시된 암호. 해시 된 형태를 얻기 위해 다음 명령을 Linux 패키지 설치 인스턴스에서 실행하십시오. 해당 명령은 적절한 해시값을 출력해주기 전에 암호를 입력하고 확인하도록 합니다. 1. gitlab-ctl pg-password-md5 gitlab 1. gitlab-ctl pg-password-md5 gitlab_geo

기본 데이터베이스 구성

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

기본 데이터베이스 노드의 Linux 패키지 설치를 구성하려면 다음과 같은 예제 구성을 바탕으로 작업하십시오.

### 지오 프라이머리
external_url 'http://gitlab.example.com'
roles ['geo_primary_role']
# 지오 노드의 고유 식별자.
gitlab_rails['geo_node_name'] = '런던 오피스'
gitlab_rails['auto_migrate'] = false
## DB 외의 모든 것을 비활성화
sidekiq['enable']=false
puma['enable']=false
gitlab_workhorse['enable']=false
nginx['enable']=false
geo_logcursor['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']을 사이트에 대한 고유한 이름으로 대체해야 합니다. 공통 설정의 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을 포함하는 것이 중요합니다. Linux 패키지의 자동화는 이를 사용하여 연결합니다. 이 목록의 주소에는 보조 데이터베이스의 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
       # 기본 LoadBalancer에 대한 정적 IP를 구성하는 경우
       # externalIP: 
       # Geo LoadBalancer에 대한 정적 IP를 구성하는 경우
       # externalGeoIP:
     # DB 연결 구성
     psql:
       host: geo-1.db.example.com
       port: 5432
       password:
         secret: geo
         key: postgresql-password
     # geo (프라이머리) 구성
     geo:
       nodeName: 런던 오피스
       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 사이트의 Name 필드와 일치해야 합니다.
   • 기본 Geo 사이트의 nginx-ingress-geo.enabled를 설정하여 Geo 트래픽을 위해 두 번째 데이터베이스 노드에서 전달된 Ingress 컨트롤러를 활성화합니다.
   • Geo 트래픽을 위해 gitlab.webservice Ingress를 구성합니다.
   • 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. 레일즈 러너 명령어를 사용하여 주 사이트의 내부 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
   

   아래와 유사한 출력이 표시되어야 합니다:

   경고: 이 버전의 GitLab은 gitlab-shell 10.2.0에 종속되지만, 현재는 알 수 없습니다. gitlab-shell을 업데이트하십시오.
   Geo 확인 중 ...
   
   GitLab Geo 사용 가능 ... 예
   GitLab Geo 활성화됨 ... 예
   GitLab Geo 보조 데이터베이스가 올바르게 구성됨 ... 보조 노드가 아님
   데이터베이스 복제 활성화됨? ... 보조 노드가 아님
   데이터베이스 복제 작동 중? ... 보조 노드가 아님
   GitLab Geo HTTP(S) 연결 ... 보조 노드가 아님
   HTTP/HTTPS 저장소 복제가 활성화됨 ... 예
   머신 클록이 동기화됨 ... Exception: getaddrinfo: Servname not supported for ai_socktype
   Git 사용자의 기본 SSH 구성? ... 예
   OpenSSH가 AuthorizedKeysCommand를 사용하도록 구성됨 ... 아니요
     이유:
     다음 위치에서 OpenSSH 구성 파일을 찾을 수 없음: /assets/sshd_config
     이를 수정하려면:
     공식 도커 컨테이너를 사용하지 않는 경우,
     시스템에서 올바르게 OpenSSH 서버를 설치하고 구성했는지 확인하십시오
     자세한 내용은 다음 위치를 참조하십시오:
     doc/administration/operations/fast_ssh_key_lookup.md
   GitLab은 authorized_keys 파일에 대해 쓰기를 비활성화하도록 구성됨 ... 예
   GitLab은 새 프로젝트를 해시 저장소에 저장하도록 구성됨? ... 예
   모든 프로젝트가 해시 저장소에 있음? ... 예
   
   Geo 확인 중 ... 완료
   

   • 호스트 클록에 액세스할 수 없기 때문에 Exception: getaddrinfo: Servname not supported for ai_socktype 메시지에 대해 걱정하지 마세요. 이는 정상입니다.
   • OpenSSH가 AuthorizedKeysCommand를 사용하도록 구성됨 ... 아니요 는 예상된 결과입니다. 이 Rake 작업은 실제로 gitlab-shell 차트에 있는 로컬 SSH 서버를 확인하는 것입니다.

보조 데이터베이스 구성

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

보조 데이터베이스 노드의 Linux 패키지 설치를 구성하려면 다음 예제 구성을 기반으로 작업하십시오:

### Geo 보조
# 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
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']을 사이트에 대한 고유한 이름으로 대체해야 합니다. 공통 설정의 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를 업데이트해야 하며, 이것은 Linux 패키지가 PostgreSQL 구성을 자동화하기 위해 사용됩니다.

md5_auth_cidr_addresses는 [ '127.0.0.1/24', '10.41.0.0/16'] 형식이어야 합니다. 이 목록에 127.0.0.1을 포함하는 것이 중요합니다. Linux 패키지의 자동화는 이를 사용하여 연결하기 때문입니다. 이 목록의 주소에는 보조 Kubernetes 클러스터의 모든 노드의 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 주소를 사용하거나 방화벽이 서버 접근을 방지하고 있는 것일 수 있습니다. 공용 및 사설 주소의 차이에 유의하고, 방화벽이 있으면 보조 PostgreSQL 노드가 TCP 포트 5432에서 주 PostgreSQL 노드에 연결할 수 있도록 허용되었는지 확인하십시오.

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-psql 사용자가 주 사이트의 PostgreSQL에 연결할 수 있는지 테스트합니다(기본 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_database_node_ip>
   

   입력을 요청받으면 gitlab_replicator 사용자의 암호를 입력하십시오. 모든 것이 올바르게 작동했다면 주 PostgreSQL 노드의 데이터베이스 목록이 표시됩니다.

   여기서 연결에 실패하는 경우 TLS 구성이 올바르지 않을 수 있습니다. 주 PostgreSQL 노드의 ~gitlab-psql/data/server.crt의 내용이 보조 PostgreSQL 노드의 ~gitlab-psql/.postgresql/root.crt의 내용과 일치하는지 확인하십시오.

7. 데이터베이스를 복제합니다. PRIMARY_DATABASE_HOST를 귀하의 주 PostgreSQL 노드의 IP 또는 호스트이름으로 대체하십시오:

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

8. 복제가 완료되면 Linux 패키지를 마지막으로 다시 구성하여 보조 PostgreSQL 노드용 pg_hba.conf가 올바른지 확인해야 합니다:

   gitlab-ctl reconfigure
   

Primary 사이트에서 보조 사이트로 비밀 복사

이제 몇 가지 비밀을 Primrary 사이트의 Kubernetes 배포에서 Secondary 사이트의 Kubernetes 배포로 복사하세요:

• gitlab-geo-gitlab-shell-host-keys
• gitlab-geo-rails-secret
• gitlab-geo-registry-secret (Registry 복제가 활성화된 경우).

1. kubectl 컨텍스트를 Primary로 변경합니다.

2. Primary 배포에서 이러한 비밀을 수집합니다:

   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 컨텍스트를 Secondary로 변경합니다.

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 보조 사이트로 차트 배포

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

이 차트를 Geo 보조 사이트로 배포하려면 이 예시 구성을 참고하세요.

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

   ## Geo 보조
   global:
     # docs.gitlab.com/charts/charts/globals을 참조하세요
     # 호스트 및 도메인 구성
     hosts:
       domain: shanghai.example.com
       # 통합 URL 사용 (primary site와 동일한 외부 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
   # 보조 사이트의 경우 선택 사항: 내부 Geo 사이트 트래픽용 Geo Nginx Controller 구성.
   # nginx-ingress-geo:
   #   enabled: true
   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는 반드시 Admin Area의 Geo site의 이름 필드와 정확하게 일치해야 합니다.
   • 선택적으로 nginx-ingress-geo.enabled를 설정하여 내부 Geo 트래픽을 위한 사전 구성된 인그레스 컨트롤러를 활성화할 수 있습니다. 이는 primary로의 승격을 더 쉽게 만듭니다..
   • gitlab.webservice를 위해 추가적인 Ingress를 구성하세요. 이는 보조 사이트의 내부 URL로 전송된 트래픽을 처리합니다.
   • 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. 배포가 완료되고 응용 프로그램이 온라인으로 시작되도록 기다립니다.

Primary를 통해 보조 Geo 사이트 추가

이제 데이터베이스가 구성되고 응용 프로그램이 배포된 후 Primary 사이트에게 Secondary 사이트의 존재를 알려야 합니다.

1. primary 사이트를 방문합니다.
2. 좌측 사이드바에서 하단에 관리자 영역을 선택합니다.
3. Geo > 사이트 추가를 선택합니다.
4. secondary 사이트를 추가합니다. URL에 전체 GitLab URL을 사용하세요.
5. Secondary 사이트의 global.geo.nodeName과 정확히 일치하는 이름을 입력하세요. 이 값은 문자마다 정확히 일치해야 합니다.
6. 내부 URL을 입력합니다. 예: https://shanghai.gitlab.example.com.
7. 선택적으로 secondary 사이트가 복제해야 할 그룹 또는 저장소 샤드를 선택합니다. 모두 복제하려면 비워둡니다.
8. 노드 추가를 선택합니다.

Secondary 사이트가 관리 패널에 추가되면, 해당 사이트는 자동으로 primary 사이트로부터 누락된 데이터를 복제하기 시작합니다. 이 프로세스는 “backfill”로 알려져 있습니다. 한편, primary 사이트는 각 secondary 사이트에게 변경 사항을 알리기 시작하여 해당 사이트가 즉시 변경 사항을 복제하도록 합니다.

운영 상태 확인

최종 단계는 툴박스 Pod를 통해 완전히 구성된 보조 사이트의 Geo 구성을 확인하는 것입니다.

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
   

   다음과 유사한 출력이 표시되어야 합니다:

   경고: 이 GitLab의 이 버전은 gitlab-shell 10.2.0에 종속되지만 Unknown으로 실행 중입니다. gitlab-shell을 업데이트하세요.
   Geo 확인 중...
   
   GitLab Geo 사용 가능... 예
   GitLab Geo 활성화... 예
   GitLab Geo 보조 데이터베이스가 올바르게 구성됨... 예
   데이터베이스 복제 활성화?... 예
   데이터베이스 복제 작동 중?... 예
   GitLab Geo HTTP(S) 연결...
   * 기본 노드에 연결할 수 있음... 예
   HTTP/HTTPS 리포지토리 복제가 활성화됨... 예
   기계 시계가 동기화됨... 예외: getaddrinfo: Servname not supported for ai_socktype
   Git 사용자에게 기본 SSH 구성이 있나요?... 예
   OpenSSH가 AuthorizedKeysCommand를 사용하도록 구성됨... 아니요
     이유:
     /assets/sshd_config에서 OpenSSH 구성 파일을 찾을 수 없음
     다음을 수정하세요:
     공식적인 도커 컨테이너를 사용하지 않는 경우에는
     이 시스템에 올바르게 설치되고 구성된 OpenSSH 서버를 사용합니다
     자세한 정보는 다음을 참조하세요:
     doc/administration/operations/fast_ssh_key_lookup.md
   GitLab이 authorized_keys 파일에 쓰지 않도록 구성됨... 예
   새 프로젝트를 해시화된 저장소에 저장하도록 GitLab이 구성됨?... 예
   모든 프로젝트가 해시화된 저장소에 있는가?... 예
   
   Geo 확인 중... 완료
   

   • 호스트 크론 시계에 접근할 수 없으므로 Exception: getaddrinfo: Servname not supported for ai_socktype에 대해 걱정하지 마십시오. 이는 문제가 없습니다.
   • OpenSSH가 AuthorizedKeysCommand를 사용하도록 구성됨... 아니요는 정상적인 것입니다. 이 Rake 작업은 실제로 다른 곳에 배포된 gitlab-shell 차트에 이미 올바르게 설정된 로컬 SSH 서버를 확인하고 있습니다.

별도의 URL을 사용하여 보조 사이트 구성하기 (선택 사항)

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

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

일부 경우에는 사용자에게 어떤 사이트를 방문할지에 대한 제어 권한을 부여하고 싶을 수 있습니다. 이를 위해 보조 지오 사이트를 고유한 외부 URL을 사용하도록 구성할 수 있습니다. 예를 들어:

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

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

   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 > 사이트를 선택합니다.
     4. 연필 아이콘을 선택하여 보조 사이트를 편집합니다.
     5. 외부 URL을 편집합니다. 예: https://shanghai.gitlab.example.com.
     6. 변경 사항 저장을 선택합니다.

3. 보조 사이트 차트를 다시 배포합니다:

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

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

레지스트리

보조 레지스트리를 기본 레지스트리와 동기화하려면 레지스트리 복제를 구성할 수 있습니다. 이를 위해 알림 비밀키를 사용합니다.

Cert-manager 및 통합 URL

통합 URL은 주로 위치 인식 라우팅(예: Amazon Route 53 또는 Google Cloud DNS 사용)과 함께 사용되는데, 이는 도메인 이름이 귀하의 관리하에 있는지를 확인하기 위해 HTTP01 챌린지를 사용하는 경우 문제가 될 수 있습니다.

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

cert-manager를 사용하여 신뢰할 수 있는 방법으로 인증서를 생성하고 갱신하려면, 챌린지 네임서버를 설정하여 통합 호스트 이름을 Geo 사이트 IP 주소로 해석하는 것으로 알려진 서버로 설정하거나 DNS01 발급자를 구성하세요.