• 요구 사항
• 한계 및 제한 사항
• 개요
• 리눅스 패키지 데이터베이스 노드 설정
• Kubernetes 클러스터 설정
• 정보 수집
• 기본 데이터베이스 구성
• Geo 기본 사이트로 차트 배포
• Geo 기본 사이트 설정
• 보조 데이터베이스 구성
• 모든 것을 끄고 DB만 켜기
• 네트워크의 DB 구성
• 주요 사이트에서 보조 사이트로 비밀 복사하기
• 차트를 Geo 보조 사이트로 배포하기
• 기본 사이트를 통해 보조 Geo 사이트 추가하기
• 운영 상태 확인
• 보조 사이트에 대한 별도의 URL 구성 (선택 사항)
• 레지스트리
• Cert-manager와 통합 URL

GitLab 차트를 GitLab Geo로 구성하기

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

외부 데이터베이스 서비스를 사용할 수 있지만, 이 문서에서는 PostgreSQL에 대한 Linux 패키지 사용에 중점을 두어 플랫폼에 구애받지 않는 가이드를 제공하고 gitlab-ctl에 포함된 자동화를 활용합니다.

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

요구 사항

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

• 외부 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

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

이 과정에는 두 개의 노드가 필요합니다. 하나는 기본 데이터베이스 노드이고, 다른 하나는 보조 데이터베이스 노드입니다. 온프레미스 또는 클라우드 제공업체를 포함하여 기계 인프라의 모든 공급자를 사용할 수 있습니다.

통신이 필요하다는 점을 염두에 두세요:

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

Linux 패키지에서 지원하는 운영 체제를 설치하고, 그 위에 리눅스 패키지를 설치하세요. 설치할 때 EXTERNAL_URL 환경 변수를 제공하지 마세요. 최소 구성 파일을 제공한 후 패키지를 재구성할 것입니다.

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

Kubernetes 클러스터 설정

이 과정에는 두 개의 Kubernetes 클러스터를 사용해야 합니다. 이들은 온프레미스 또는 클라우드 제공업체의 것이어야 합니다.

통신이 필요하다는 점을 염두에 두세요:

• 해당 데이터베이스 노드로:
  • 기본 노드는 TCP 5432로 아웃바운드합니다.
  • 보조 노드는 TCP 5432 및 5431로 아웃바운드합니다.
• 두 Kubernetes Ingress 간에 HTTPS로.

제공된 각 클러스터는 다음을 충족해야 합니다:

• 이러한 차트의 기본 설치를 지원할 수 있는 충분한 리소스.
• 지속적인 저장소에 대한 접근:
  • 외부 객체 저장소를 사용하는 경우 MinIO는 필요하지 않습니다.
  • 외부 Gitaly를 사용하는 경우 Gitaly는 필요하지 않습니다.
  • 외부 Redis를 사용하는 경우 Redis는 필요하지 않습니다.

정보 수집

구성을 계속 진행하기 위해 다음 정보를 다양한 출처에서 수집해야 합니다. 이 정보를 수집하고, 이 문서의 나머지 부분에서 사용할 메모를 작성하세요.

• 기본 데이터베이스:
  • 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 해시 비밀번호. 해시 형태를 얻으려면 다음 명령어를 Linux 패키지 설치 인스턴스 중 하나에서 실행하세요. 이 명령은 비밀번호를 입력하고 확인하도록 요청한 후 적절한 해시 값을 출력합니다.

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'] = 'London Office'
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']는 사이트의 고유 이름으로 교체해야 합니다. 공통 설정의 이름 필드를 참조하십시오.
• 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. Primary 데이터베이스 노드의 공개 인증서를 검색합니다. 이는 보조 데이터베이스가 복제할 수 있도록 필요한 것입니다(이 출력을 저장하십시오):

   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:
     # See 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: London Office
       enabled: true
       role: primary
   # 내부 Geo 사이트 트래픽을 위한 Geo Nginx Controller 구성
   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 사이트 이름 필드와 일치해야 합니다.
   • Geo 트래픽을 보조에서 전달하기 위한 Ingress 컨트롤러를 활성화하려면 nginx-ingress-geo.enabled를 설정하십시오.
   • Geo 트래픽을 위한 기본 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을 Rails 러너 명령으로 설정합니다. https://primary.gitlab.example.com을 실제 내부 URL로 교체합니다:

   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
   

   • Exception: getaddrinfo: Servname not supported for ai_socktype에 대해 걱정하지 마세요. Kubernetes 컨테이너는 호스트 시계에 접근할 수 없습니다. 이것은 괜찮습니다.
   • OpenSSH configured to use AuthorizedKeysCommand ... no 는 예상되는 결과입니다. 이 Rake 작업은 실제로 다른 곳에 배포된 gitlab-shell 차트에 있는 로컬 SSH 서버를 확인하고 있습니다.

보조 데이터베이스 구성

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

보조 데이터베이스 노드의 Linux 패키지 설치를 구성하려면 다음 예제 구성을 사용합니다:

### Geo Secondary
# external_url은 기본 클러스터의 external_url과 일치해야 합니다.
external_url 'http://gitlab.example.com'
roles ['geo_secondary_role']
gitlab_rails['enable'] = true
# Geo 노드의 고유 식별자입니다.
gitlab_rails['geo_node_name'] = '상하이 사무소'
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']`는 귀하의 사이트를 위한 고유한 이름으로 교체해야 합니다. [일반 설정](https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings)에서 이름 필드를 참조하세요.

- `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 패키지의 자동화는 이 주소를 사용하여 연결됩니다. 이 목록의 주소는 Secondary Kubernetes 클러스터의 모든 노드의 IP 주소를 포함해야 합니다. 이것은 `['0.0.0.0/0']`로 남겨둘 수 있지만, _모범 사례는 아닙니다_.

위 구성이 준비된 후:

1. **기본** 사이트의 PostgreSQL 노드에 대한 TCP 연결을 확인하십시오:

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

출력은 다음과 같아야 합니다:

   CONNECTED(00000003)

   write:errno=0

참고: 이 단계가 실패하는 경우 잘못된 IP 주소를 사용하고 있거나 방화벽이 서버 접근을 차단하고 있을 수 있습니다. IP 주소를 확인하고, 공용 주소와 개인 주소의 차이점에 주의하고, 방화벽이 있는 경우 보조 PostgreSQL 노드가 기본 PostgreSQL 노드에 TCP 포트 5432에서 연결할 수 있도록 허용되어 있는지 확인하십시오.

1. 내용을 /etc/gitlab/gitlab.rb에 넣으세요.

2. gitlab-ctl reconfigure를 실행하세요. TCP에서 서비스가 수신 대기하지 않는 문제를 경험하는 경우, gitlab-ctl restart postgresql로 직접 재시작해 보세요.

3. 위의 기본 PostgreSQL 노드의 인증서 내용을 primary.crt로 넣으세요.

4. 보조 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 노드에만 존재합니다.

5. 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 내용과 일치하는지 확인하세요.

6. 데이터베이스를 복제하세요. PRIMARY_DATABASE_HOST를 기본 PostgreSQL 노드의 IP 또는 호스트 이름으로 교체하세요:

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

7. 복제가 완료된 후, 보조 PostgreSQL 노드의 pg_hba.conf가 올바른지 확인하기 위해 Linux 패키지를 마지막으로 다시 구성해야 합니다:

   gitlab-ctl reconfigure
   

주요 사이트에서 보조 사이트로 비밀 복사하기

이제 주요 사이트의 Kubernetes 배포에서 보조 사이트의 Kubernetes 배포로 몇 가지 비밀을 복사합니다:

• gitlab-geo-gitlab-shell-host-keys
• gitlab-geo-rails-secret
• Registry 복제가 활성화된 경우 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
   # 보조 사이트 용 선택 사항: 내부 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는 관리 영역에서 Geo 사이트의 이름 필드와 일치해야 합니다
   • 내부 Geo 트래픽을 위해 사전 구성된 인그레스 컨트롤러를 활성화하려면 선택적으로 nginx-ingress-geo.enabled를 설정하세요. 이렇게 하면 사이트를 주요 사이트로 승격하기가 더 쉬워집니다..
   • 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. 배포가 완료되고 애플리케이션이 온라인 상태가 될 때까지 기다립니다.

기본 사이트를 통해 보조 Geo 사이트 추가하기

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

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

보조 사이트가 관리 패널에 추가되면, 자동으로 기본 사이트에서 누락된 데이터를 복제하기 시작합니다. 이 과정을 “백필(backfill)”이라고 합니다. 동시에, 기본 사이트는 각각의 보조 사이트에 변경 사항을 알리기 시작하여, 보조 사이트가 이러한 변경 사항을 신속하게 복제할 수 있도록 합니다.

운영 상태 확인

최종 단계는 설정이 완전히 완료된 후 Toolbox Pod를 통해 보조 사이트의 Geo 구성을 다시 확인하는 것입니다.

1. Toolbox 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:이 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를 사용하도록 구성됨 ... 아니요
     이유:
     다음 위치에서 OpenSSH 구성 파일을 찾을 수 없습니다: /assets/sshd_config
     이를 해결해 보세요:
     공식 도커 컨테이너를 사용하지 않는 경우,
     이 시스템에 OpenSSH 서버가 올바르게 설치되어 구성되었는지 확인하세요.
     자세한 내용은 다음을 참조하세요:
     doc/administration/operations/fast_ssh_key_lookup.md
   GitLab에서 authorized_keys 파일에 쓰기를 비활성화하도록 구성됨 ... 예
   GitLab에서 새 프로젝트를 해시된 저장소에 저장하도록 구성됨? ... 예
   모든 프로젝트가 해시된 저장소에 있습니까? ... 예
   
   Geo 확인 ... 완료
   

   • 예외: getaddrinfo: Servname not supported for ai_socktype에 대해 걱정하지 마세요, Kubernetes 컨테이너는 호스트 시계에 접근할 수 없습니다. 이것은 괜찮습니다.
   • OpenSSH가 AuthorizedKeysCommand를 사용하도록 구성됨 ... 아니요 는 예상됩니다. 이 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. GitLab에서 보조 사이트의 외부 URL을 업데이트하여 필요한 곳에서 해당 URL을 사용할 수 있도록 합니다:
   • Admin UI 사용:
     1. 기본 사이트를 방문합니다.
     2. 왼쪽 사이드바에서 하단의 Admin Area를 선택합니다.
     3. Geo > Sites를 선택합니다.
     4. 연필 아이콘을 선택하여 보조 사이트 편집합니다.
     5. 외부 URL을 편집합니다. 예: https://shanghai.gitlab.example.com.
     6. 변경 사항 저장을 선택합니다.

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

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

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

레지스트리

보조 레지스트리를 기본 레지스트리와 동기화하려면 레지스트리 복제 를 구성할 수 있습니다 notification secret.

Cert-manager와 통합 URL

Geo의 통합 URL은 지리적 인지 라우팅(예: Amazon Route 53 또는 Google Cloud DNS 사용)과 함께 자주 사용되며, 이로 인해 HTTP01 challenge를 사용하여 도메인 이름이 당신의 제어하에 있는지 확인하는 경우 문제가 발생할 수 있습니다.

한 Geo 사이트에 대한 인증서를 요청할 때, Let’s Encrypt는 DNS 이름을 요청하는 Geo 사이트로 해결해야 합니다. DNS가 다른 Geo 사이트로 해결될 경우, 통합 URL에 대한 인증서는 발급되지 않거나 갱신되지 않습니다.

cert-manager로 인증서를 신뢰성 있게 생성하고 갱신하려면, challenge nameserver를 통합 호스트 이름을 Geo 사이트의 IP 주소로 해결해야 하는 서버로 설정하거나 DNS01 Issuer를 구성해야 합니다.