요구 사항
제한 사항
개요
Linux 패키지 데이터베이스 노드 설정
Kubernetes 클러스터 설정
정보 수집
주 데이터베이스 구성
DB 이외의 모든 것을 중지합니다
네트워크용 DB 구성
Geo 기본 사이트로 차트 배포
Geo 기본 사이트 설정
보조 데이터베이스 구성
기본 사이트에서 보조 사이트로 비밀 정보 복사
Geo프라이머리 사이트로 차트 배포하기
프라이머리를 통해 Geo프라이머리 사이트 추가하기
운영 상태 확인
세컨더리 사이트를 위한 별도의 URL 구성(선택 사항)
레지스트리
Cert-manager 및 통합 URL

GitLab Geo를 GitLab 차트로 구성하기

GitLab Geo는 지리적으로 분산된 응용 프로그램 배포 기능을 제공합니다.

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

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

Geo의 모든 측면을 설명하는 정의된 용어를 참조하세요(site와 node의 주요 차이).

요구 사항

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

차트에 포함된 PostgreSQL은 외부 네트워크에 노출되지 않으며 복제에 필요한 WAL 지원이 없으므로 외부 PostgreSQL 서비스를 사용해아합니다.
제공된 데이터베이스는 다음을 지원해야 합니다:
- 복제를 지원해아합니다.
- 기본 데이터베이스는 주 서비스 지점 및 모든 보조 데이터베이스 노드(복제용)에서 접근 가능해야 합니다.
- 보조 데이터베이스는 보조 사이트에서만 접근 가능하면됩니다.
- 주 데이터베이스 및 보조 데이터베이스 노드 간에 SSL을 지원해야 합니다.
주 사이트는 모든 보조 사이트에서 HTTP(S)로 접근할 수 있어야 합니다. 보조 사이트는 주 사이트에서 HTTP(S)로 접근할 수 있어야 합니다.
Geo를 실행하기 위한 요구 사항 전체 디렉터리을 참조하세요.

제한 사항

Geo 제한 사항을 전체 제한 디렉터리을 확인하세요.

개요

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

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

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

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

이 프로세스에서는 주 데이터베이스 노드와 보조 데이터베이스 노드가 필요합니다. 기계 인프라 제공자를 사용하여 온프레미스 또는 클라우드 제공자에서 제공할 수 있습니다.

통신이 필요하다는 것을 명심해야합니다. - 복제를 위한 두 데이터베이스 노드 간 - 각 데이터베이스 노드와 해당 Kubernetes 배포 간: - 주 데이터베이스는 TCP 포트 5432를 노출해야합니다. - 보조 데이터베이스는 TCP 포트 5432 및 5431을 노출해야합니다.

Linux 패키지에서 지원하는 운영 체제를 설치한 다음 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 패키지 설치 인스턴스 중 하나에서 다음 명령을 실행하세요. 이 명령은 적절한 해시 값을 출력하기 전에 암호를 입력하고 확인하도록 요청합니다.

gitlab-ctl pg-password-md5 gitlab
gitlab-ctl pg-password-md5 gitlab_geo

주 데이터베이스 구성

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

주 데이터베이스 노드의 Linux 패키지 설치를 구성하기 위해 다음 예제 구성을 사용하세요.

### Geo 주 사이트
external_url 'http://gitlab.example.com'
roles ['geo_primary_role']
# Geo 노드의 고유 식별자입니다.
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 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’ postgresql[‘md5_auth_cidr_addresses’] = [‘0.0.0.0/0’]

우리는 여러 가지를 바꿔야 합니다:

- `external_url`을 기본 사이트의 호스트 이름을 반영하도록 업데이트해야 합니다.
- `gitlab_rails['geo_node_name']`을 사이트에 고유한 이름으로 대체해야 합니다. [Common settings](https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings)의 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 패키지의 자동화가 여기에 연결하기 때문입니다. 이 디렉터리의 주소는 보조 데이터베이스, 기본 Kubernetes 클러스터의 모든 노드의 IP 주소(호스트 이름이 아닌)를 포함해야 합니다. 이것은 `['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. 기본 데이터베이스 노드의 공개 인증서를 가져옵니다. 이것은 보조 데이터베이스가 복제할 수 있도록 필요합니다(이 출력을 저장하세요):
   
   ```shell
   cat ~gitlab-psql/data/server.crt

Geo 기본 사이트로 차트 배포

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

이 차트를 Geo 기본으로 배포하려면 이 예제 구성부터 시작하세요.

차트가 사용할 데이터베이스 암호가 포함된 시크릿을 만드세요. 아래의 PASSWORD를 gitlab 데이터베이스 사용자의 암호로 대체하세요:
```
kubectl --namespace gitlab create secret generic geo --from-literal=postgresql-password=PASSWORD
```

예제 구성을 기반으로 primary.yaml 파일을 만들고 올바른 값을 반영하세요:

### Geo 기본
global:
  # See 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 Controller 구성
nginx-ingress-geo:
  enabled: true
gitlab:
  webservice:
    # Geo NGINX 컨트롤러 사용
    ingress:
      useGeoClass: true
    # 내부 Geo 트래픽을 위한 인그레스 구성
    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 트래픽을 위한 인그레스 컨트롤러를 활성화합니다.
기본 Geo 사이트의 gitlab.webservice 인그레스를 Geo 트래픽에 대해 구성하세요.
SSL/TLS 설정 및 외부 레디스 사용, 외부 객체 리포지터리 사용 등 다른 설정도 구성하세요.

이 구성을 사용하여 차트를 배포하세요:
```
helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f primary.yaml
```
gitlab 네임스페이스를 사용하는 것으로 가정합니다. 다른 네임스페이스를 사용하려면 이 문서의 다른 부분에서도--namespace gitlab를 해당 네임스페이스로 바꿔야 합니다.
배포가 완료되고 애플리케이션이 온라인 상태가 될 때까지 기다리세요. 애플리케이션이 접근 가능해지면 로그인하세요.
GitLab에 로그인하고 GitLab 구독을 활성화하세요.

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

Geo 기본 사이트 설정

차트가 배포되었고 라이선스가 업로드되었으므로 이를 기본 사이트로 구성할 수 있습니다. 이 작업은 Toolbox Pod를 통해 수행합니다.

Toolbox Pod를 찾으세요

kubectl --namespace gitlab get pods -lapp=toolbox

kubectl exec를 사용하여 gitlab-rake geo:set_primary_node를 실행하세요:

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

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')"

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는 걱정하지 마세요. 이것은 괜찮습니다.
OpenSSH configured to use AuthorizedKeysCommand ... no는 _예상된 결과_입니다. 이 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'] = '상하이 오피스'
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 주소 디렉터리은 사용자 정의해야 합니다
# - 보조 애플리케이션 배포
# - 보조 데이터베이스 노드(s)
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 주소 디렉터리은 사용자 정의해야 합니다
# - 보조 애플리케이션 배포
# - 보조 데이터베이스 노드(s)
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']으로 두어도 괜찮지만, 최선의 방법은 아닙니다.

위 구성을 준비한 후:

기본 사이트의 PostgreSQL 노드로의 TCP 연결을 확인합니다:
```
openssl s_client -connect <primary_node_ip>:5432 </dev/null
```
아래 내용이 표시되어야 합니다:
```
CONNECTED(00000003)
write:errno=0
```
이 단계에 실패하는 경우 잘못된 IP 주소를 사용하거나 방화벽이 서버 접근을 막고 있는 것일 수 있습니다. IP 주소를 확인할 때는 공용 및 사설 주소의 차이에 주의하고, 방화벽이 있다면 보조 PostgreSQL 노드가 TCP 포트 5432에서 기본 PostgreSQL 노드에 연결할 수 있도록 허용되었는지 확인합니다.
내용을 /etc/gitlab/gitlab.rb에 넣습니다.
gitlab-ctl reconfigure를 실행합니다. 서비스가 TCP에서 수신 대기하지 않는 문제가 발생하면 gitlab-ctl restart postgresql로 직접 다시 시작해 보십시오.
기본 PostgreSQL 노드의 인증서 내용을 primary.crt에 넣습니다.
보조 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 노드에만 개인 키에 액세스 권한이 있는 사람만 복제할 수 있습니다.
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/.postgresql/root.crt의 내용이 기본 PostgreSQL 노드의 ~gitlab-psql/data/server.crt의 내용과 일치하는지 확인해야 합니다.
데이터베이스를 복제합니다. PRIMARY_DATABASE_HOST를 기본 PostgreSQL 노드의 IP 또는 호스트 이름으로 교체합니다:
```
gitlab-ctl replicate-geo-database --slot-name=geo_2 --host=PRIMARY_DATABASE_HOST --sslmode=verify-ca
```
복제가 완료되면 Linux 패키지를 마지막으로 다시 구성하여 보조 PostgreSQL 노드의 pg_hba.conf가 올바른지 확인해야 합니다:
```
gitlab-ctl reconfigure
```

기본 사이트에서 보조 사이트로 비밀 정보 복사

이제 기본 사이트의 Kubernetes 배포에서 몇 가지 비밀 정보를 보조 사이트의 Kubernetes 배포로 복사해야 합니다:

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

kubectl context를 기본 사이트로 변경합니다.

기본 배포에서 이러한 비밀을 수집합니다:

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

kubectl context를 보조 사이트로 변경합니다.

이러한 비밀을 적용합니다:

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프라이머리 사이트로 이 차트를 배포하려면 이 예제 구성에서 시작하십시오.

예제 구성을 기반으로 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는 트래픽을 사전 구성된 Ingress 컨트롤러로 활성화합니다.
추가 설정도 구성하세요:
외부 데이터베이스의 경우, global.psql.host는 차선, 읽기 전용 레플리카 데이터베이스이고, global.geo.psql.host는 Geo 추적 데이터베이스입니다.

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

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

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

프라이머리를 통해 Geo프라이머리 사이트 추가하기

이제 데이터베이스가 모두 구성되었고 애플리케이션이 배포되었으므로, 프라이머리 사이트에게 세컨더리 사이트의 존재를 알려주어야 합니다.

프라이머리 사이트를 방문하십시오.
왼쪽 사이드바에서 아래쪽으로 가서 관리자 영역을 선택하십시오.
Geo > 사이트 추가를 선택하십시오.
세컨더리 사이트를 추가하십시오. URL에 전체 GitLab URL을 사용하십시오.
Secondary 사이트의 global.geo.nodeName과 정확히 일치하는 이름을 입력하십시오. 이러한 값은 반드시 한 글자, 모든 글자와 정확히 일치해야 합니다.
내부 URL을 입력하십시오. 예: https://shanghai.gitlab.example.com.
선택적으로, 세컨더리 사이트가 복제해야 하는 그룹이나 스토리지 샤드를 선택하세요. 모두 복제하려면 비워두세요.
노드 추가를 선택하십시오.

세컨더리 사이트가 관리 패널에 추가되면, 자동으로 프라이머리 사이트에서 누락된 데이터를 복제하기 시작합니다. 이 과정은 “백필(fill)”이라고 알려져 있습니다. 한편, 프라이머리 사이트는 각 세컨더리 사이트에게 변경 사항을 통보하여 세컨더리 사이트가 즉시 이러한 변경 사항을 복제하도록 합니다.

운영 상태 확인

마지막 단계는 툴박스 Pod를 통해 완전히 구성된 세컨더리 사이트의 Geo 구성을 이중으로 확인하는 것입니다.

툴박스 Pod를 찾습니다:

kubectl --namespace gitlab get pods -lapp=toolbox

kubectl exec로 Pod에 연결합니다:

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

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 확인 중... 완료

호스트 클록에 액세스할 수 없는 Kubernetes 컨테이너이기 때문에 Exception: getaddrinfo: Servname not supported for ai_socktype은 걱정하지 않아도 됩니다. 이는 괜찮습니다.
OpenSSH가 AuthorizedKeysCommand 사용하도록 구성되었습니까?... 아니요는 예상대로입니다. 이 Rake 작업은 실제로 다른 곳에서 이미 적절히 구성된 gitlab-shell 차트에서 로컬 SSH 서버를 확인하고 있습니다.

세컨더리 사이트를 위한 별도의 URL 구성(선택 사항)

일반적으로 프라이머리 및 세컨더리 사이트를 위한 단일 통합 URL이 사용자에게 훨씬 편리합니다. 예를 들어:

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

어떤 경우에는 사용자가 어떤 사이트를 방문할지를 제어하도록 할 수 있습니다. 이를 위해 세컨더리 Geo 사이트가 고유한 외부 URL을 사용하도록 구성할 수 있습니다. 예를 들어:

프라이머리 클러스터의 외부 URL: https://gitlab.example.com
세컨더리 클러스터의 외부 URL: https://shanghai.gitlab.example.com

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

global:
  # 문서 참조: docs.gitlab.com/charts/charts/globals
  # 호스트 및 도메인 구성
  hosts:
    domain: example.com
    # 세컨더리 사이트를 위한 고유한 외부 URL 사용
    gitlab:
      name: shanghai.gitlab.example.com

세컨더리 사이트의 외부 URL을 GitLab에서 업데이트하여 필요한 곳이면 어디서든 해당 URL을 사용할 수 있도록 합니다:
- Admin UI를 사용하는 경우:
  1. 프라이머리 사이트를 방문하십시오.
  2. 왼쪽 사이드바에서 아래쪽으로 가서 관리자 영역을 선택하십시오.
  3. Geo > 사이트를 선택해야 합니다.
  4. 세컨더리 사이트를 편집하기 위해 연필 아이콘을 선택하십시오.
  5. 외부 URL을 편집하십시오. 예: https://shanghai.gitlab.example.com.
  6. 변경 사항 저장을 선택하십시오.
- Rails runner 명령을 사용하는 경우:
  1. 프라이머리 사이트의 툴박스 컨테이너에서:
    kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rails runner "GeoNode.secondary_nodes.last.update!(url: 'https://shanghai.gitlab.example.com')"

세컨더리 사이트의 차트를 다시 배포하십시오:

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

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

레지스트리

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

Cert-manager 및 통합 URL

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

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

cert-manager로 신뢰성 있게 인증서를 생성하고 갱신하려면, 도메인 이름 서버를 설정하여 통합 호스트 이름을 Geo 사이트 IP 주소로 해석하는 것이나 DNS01 발급자를 구성하세요.

GitLab Geo를 GitLab 차트로 구성하기

요구 사항

제한 사항

개요

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

Kubernetes 클러스터 설정

정보 수집

주 데이터베이스 구성

DB 이외의 모든 것을 중지합니다

네트워크용 DB 구성

Geo 기본 사이트로 차트 배포

Geo 기본 사이트 설정

보조 데이터베이스 구성

기본 사이트에서 보조 사이트로 비밀 정보 복사

Geo프라이머리 사이트로 차트 배포하기

프라이머리를 통해 Geo프라이머리 사이트 추가하기

운영 상태 확인

세컨더리 사이트를 위한 별도의 URL 구성(선택 사항)

레지스트리

Cert-manager 및 통합 URL

도움말

기능 사용 가능성과 제품 평가판

도움받기