- 요구 사항
- 제한 사항
- 개요
- 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 구성도 설정할 수 있습니다.
요구 사항
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 서버를 확인하고 있습니다.
- 호스트 클록에 액세스할 수 없는 Kubernetes 컨테이너이기 때문에
세컨더리 사이트를 위한 별도의 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를 사용하는 경우:
- 프라이머리 사이트를 방문하십시오.
- 왼쪽 사이드바에서 아래쪽으로 가서 관리자 영역을 선택하십시오.
- Geo > 사이트를 선택해야 합니다.
- 세컨더리 사이트를 편집하기 위해 연필 아이콘을 선택하십시오.
- 외부 URL을 편집하십시오. 예:
https://shanghai.gitlab.example.com
. - 변경 사항 저장을 선택하십시오.
- Rails runner 명령을 사용하는 경우:
-
프라이머리 사이트의 툴박스 컨테이너에서:
kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rails runner "GeoNode.secondary_nodes.last.update!(url: 'https://shanghai.gitlab.example.com')"
-
- Admin UI를 사용하는 경우:
-
세컨더리 사이트의 차트를 다시 배포하십시오:
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 발급자를 구성하세요.