두 개의 단일 노드 사이트를 위한 Geo 설정(외부 PostgreSQL 서비스 사용)

Tier: Premium, Ultimate Offering: Self-Managed

다음 가이드는 두 개의 Linux 패키지 인스턴스와 RDS, Azure Database, 또는 Google Cloud SQL과 같은 외부 PostgreSQL 데이터베이스를 사용하여 두 개의 단일 노드 사이트 설치에 대한 GitLab Geo를 배포하는 방법에 대해 간결한 지침을 제공합니다.

전제 조건:

적어도 두 개의 독립적으로 작동하는 GitLab 사이트가 있어야 합니다. 사이트를 생성하려면 GitLab 참조 아키텍처 문서를 참조하세요.
- 하나의 GitLab 사이트는 Geo 기본 사이트로 사용됩니다. 각 Geo 사이트에 다른 참조 아키텍처 크기를 사용할 수 있습니다. 이미 작동 중인 GitLab 인스턴스가 있는 경우 해당 인스턴스를 기본 사이트로 사용할 수 있습니다.
- 두 번째 GitLab 사이트는 Geo 보조 사이트로 사용됩니다. Geo는 여러 보조 사이트를 지원합니다.
기본 Geo 사이트에는 적어도 GitLab Premium 라이선스가 있어야 합니다. 모든 사이트에는 하나의 라이선스만 필요합니다.
모든 사이트가 Geo 실행을 위한 요구 사항을 충족하는지 확인하세요.

Linux 패키지(Omnibus)를 위한 Geo 설정

전제 조건:

PostgreSQL 12 이상을 사용하며, 이는 pg_basebackup 도구를 포함합니다.

기본 사이트 구성

GitLab 기본 사이트에 SSH로 로그인하고 root로 서명합니다:
```
sudo -i
```

/etc/gitlab/gitlab.rb에 고유한 Geo 사이트 이름을 추가합니다:

##
## Geo 사이트의 고유 식별자. 자세한 내용은
## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings 참조
##
gitlab_rails['geo_node_name'] = '<여기에 사이트 이름 입력>'

변경 사항을 적용하려면 기본 사이트를 다시 구성합니다:
```
gitlab-ctl reconfigure
```
사이트를 기본 Geo 사이트로 정의합니다:
```
gitlab-ctl set-geo-primary-node
```
이 명령은 /etc/gitlab/gitlab.rb에서 정의된 external_url을 사용합니다.

외부 데이터베이스 구성

외부 데이터베이스를 설정하려면 다음 중 하나를 수행할 수 있습니다:

직접 스트리밍 복제(예: Amazon RDS 또는 Linux 패키지에서 관리되지 않는 베어 메탈) 설정.
다음과 같이 Linux 패키지 설치를 수동으로 구성합니다.

클라우드 제공업체의 도구를 활용하여 기본 데이터베이스 복제

AWS EC2에 설정된 기본 사이트가 있고 RDS를 사용하는 경우, 이제 다른 지역에 읽기 전용 레플리카를 만들고 복제 프로세스를 AWS에서 관리할 수 있습니다. 네트워크 ACL(액세스 제어 목록), 서브넷 및 보안 그룹을 필요에 따라 설정하여 보조 Rails 노드에서 데이터베이스에 액세스할 수 있도록합니다.

아래 지침은 일반적인 클라우드 제공업체에 대한 읽기 전용 레플리카를 만드는 방법을 설명합니다:

Amazon RDS - 읽기 전용 레플리카 생성
Azure Database for PostgreSQL - Azure Database for PostgreSQL의 읽기 전용 레플리카 생성 및 관리
Google Cloud SQL - 읽기 전용 레플리카 생성

읽기 전용 레플리카를 설정하면 보조 사이트 구성로 넘어갈 수 있습니다.

보조 사이트를 외부 읽기 전용 레플리카 사용하도록 구성

Linux 패키지 설치에서 geo_secondary_role에는 세 가지 주요 기능이 있습니다:

레플리카 데이터베이스를 구성합니다.
추적 데이터베이스를 구성합니다.
Geo 로그 커서를 활성화합니다.

외부 읽기 전용 레플리카 데이터베이스에 연결하려면:

각 보조 사이트의 Rails, Sidekiq 및 Geo Log Cursor 노드에 SSH로 로그인하고 root로 로그인합니다:
```
sudo -i
```

/etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다.

##
## Geo 보조 역할
## - Geo 활성화를 자동으로 구성하기 위해 종속 플래그를 구성합니다.
##
roles ['geo_secondary_role']

# 이것은 두 데이터베이스 모두에 공유됩니다,
# 두 데이터베이스에 동일한 암호를 정의해야 합니다.
gitlab_rails['db_password'] = '<여기에 암호 입력>'

gitlab_rails['db_username'] = 'gitlab'
gitlab_rails['db_host'] = '<데이터베이스_읽기_레플리카_호스트>'

# 내장된 Omnibus PostgreSQL을 사용하지 않으므로 비활성화
postgresql['enable'] = false

파일을 저장하고 GitLab을 다시 구성합니다:
```
gitlab-ctl reconfigure
```

레플리카 데이터베이스에 대한 연결 문제가 있는 경우 서버에서의 TCP 연결을 다음 명령으로 확인할 수 있습니다:

gitlab-rake gitlab:tcp_check[<레플리카 FQDN>,5432]

이 단계에서 문제가 발생하면 잘못된 IP 주소를 사용중인지 또는 방화벽이 사이트 접속을 방해하고 있는지 확인해야 합니다. IP 주소를 점검하여 공용 및 사설 주소 사이의 차이에 주의하세요. 방화벽이 존재하는 경우, 보조 사이트가 5432번 포트에서 기본 사이트에 연결할 수 있도록 허용되었는지 확인하세요.

GitLab 비밀 값 수동 복제

GitLab은 /etc/gitlab/gitlab-secrets.json에 여러 비밀 값을 저장합니다. 이 JSON 파일은 사이트 노드 간에 동일해야 합니다. 모든 보조 사이트에 비밀 파일을 수동으로 복제해야 합니다. 다만, issue 3789에서는 이 동작을 변경하도록 제안하고 있습니다.

기본 사이트의 Rails 노드에 SSH로 액세스하여 아래 명령을 실행합니다:
```
 sudo cat /etc/gitlab/gitlab-secrets.json
```
이 명령을 실행하면 JSON 형식으로 복제해야 하는 비밀 값이 표시됩니다.
보조 Geo 사이트의 각 노드에 SSH로 액세스하여 root로 로그인합니다:
```
 sudo -i
```

기존 비밀 값의 백업을 만듭니다:

 mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`

기본 사이트 Rails 노드에서 /etc/gitlab/gitlab-secrets.json을 각 보조 사이트 노드로 복사합니다. 또는 노드 간에 파일 내용을 복사하여 붙여넣을 수도 있습니다:
```
 sudo editor /etc/gitlab/gitlab-secrets.json

 # 기본 사이트에서 실행한 'cat' 명령의 결과를 붙여넣기합니다.
 # 저장하고 나갑니다.
```

파일 권한이 올바른지 확인합니다:

 chown root:root /etc/gitlab/gitlab-secrets.json
 chmod 0600 /etc/gitlab/gitlab-secrets.json

변경 사항을 적용하려면 각 Rails, Sidekiq 및 Gitaly 보조 사이트 노드를 재구성합니다:
```
 gitlab-ctl reconfigure
 gitlab-ctl restart
```

기본 사이트 SSH 호스트 키 수동 복제

보조 사이트의 각 노드에 SSH로 액세스하여 root로 로그인합니다:
```
 sudo -i
```

기존 SSH 호스트 키를 백업합니다:

 find /etc/ssh -iname 'ssh_host_*' -exec cp {} {}.backup.`date +%F` \;

기본 사이트에서 OpenSSH 호스트 키를 복사합니다.

일반적으로 SSH 트래픽을 제공하는 기본 사이트 노드 중 하나에 root로 액세스할 수 있다면:

  # 이 명령을 보조 사이트에서 실행하고, 서버의 IP 또는 FQDN에 해당하는 '<primary_site_fqdn>'을 변경하세요.
  scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh

sudo 권한이 있는 사용자를 통해서만 액세스할 수 있다면:

# 기본 사이트 노드에서 실행:
sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*

# 각 보조 사이트 노드에서 실행:
scp <user_with_sudo>@<primary_site_fqdn>:geo-host-key.tar.gz .
tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh

각 보조 사이트 노드에 대해 파일 권한이 올바른지 확인합니다:

 chown root:root /etc/ssh/ssh_host_*_key*
 chmod 0600 /etc/ssh/ssh_host_*_key

기본 사이트 및 각 사이트의 보조 노드에서 다음 명령을 실행하여 키 지문이 일치하는지 확인합니다:
```
 for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
```
두 노드에서 동일한 출력을 확인해야 합니다.

기존 개인 키에 대응하는 올바른 공개 키가 있는지 확인합니다:

 # 이 명령은 각 개인 키의 지문을 출력합니다:
 for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done

 # 이 명령은 각 공개 키의 지문을 출력합니다:
 for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done

개인 및 공개 키 명령의 출력이 동일한 지문을 생성해야 합니다.

각 보조 사이트 노드에서 sshd를 다시 시작합니다:

 # Debian 또는 Ubuntu 설치의 경우
 sudo service ssh reload

 # CentOS 설치의 경우
 sudo service sshd reload

SSH가 여전히 정상적으로 작동하는지 확인하기 위해 새 터미널에서 GitLab 보조 서버에 SSH합니다. 연결되지 않으면 올바른 권한이 있는지 확인하세요.

권한 부여된 SSH 키의 빠른 조회 설정

복제 프로세스가 완료된 후 권한 부여된 SSH 키의 빠른 조회 설정을 구성해야 합니다.

::노트:: 인증은 주 사이트에서 처리됩니다. 보조 사이트에 사용자 정의 인증을 설정하지 마십시오. 관리 영역에 액세스를 필요로하는 모든 변경 사항은 보조 사이트가 읽기 전용 복사본이기 때문에 주 사이트에서 수행해야 합니다.

보조 사이트 추가

보조 사이트의 각 Rails 및 Sidekiq 노드로 SSH를 통해 root로 로그인합니다.
```
sudo -i
```

/etc/gitlab/gitlab.rb를 편집하고 사이트에 대한 고유한 이름을 추가합니다.

##
## Geo 사이트의 고유 식별자. 자세한 내용은
## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings 참조
##
gitlab_rails['geo_node_name'] = '<여기에 보조_사이트_이름_입력>'

고유 이름을 다음 단계에 저장합니다.

변경 사항을 적용하려면 보조 사이트의 각 Rails 및 Sidekiq 노드를 다시 구성합니다.
```
gitlab-ctl reconfigure
```
주 노드 GitLab 인스턴스로 이동합니다:
1. 왼쪽 사이드바에서 아래쪽으로 스크롤하여 관리 영역을 선택합니다.
2. Geo > Sites를 선택합니다.
3. 사이트 추가를 선택합니다.
4. 이름에는 /etc/gitlab/gitlab.rb의 gitlab_rails['geo_node_name']값을 입력합니다. 값은 정확히 일치해야 합니다.
5. 외부 URL에는 /etc/gitlab/gitlab.rb의 external_url값을 입력합니다. 한 값이 /로 끝나고 다른 값이 그렇지 않더라도 괜찮습니다. 그렇지 않으면 값은 정확히 일치해야 합니다.
6. (선택 사항) 내부 URL(선택 사항)에는 주 사이트의 내부 URL을 입력합니다.
7. (선택 사항) 보조 사이트에서 복제해야 하는 그룹 또는 저장소 샤드를 선택합니다. 모두 복제하려면 필드를 비워 둡니다. 선택적 동기화를 참조하세요.
8. 변경 사항 저장을 선택합니다.
보조 사이트의 각 Rails 및 Sidekiq 노드로 SSH를 통해 이 서비스를 다시 시작합니다.
```
sudo gitlab-ctl restart
```
다음 명령을 실행하여 Geo 설정의 일반 문제가 있는지 확인합니다.
```
sudo gitlab-rake gitlab:geo:check
```
확인 사항 중 하나라도 실패하는 경우 문제 해결 문서를 확인하세요.
보조 사이트에 연결할 수 있는지 확인하기 위해 주 사이트의 Rails 또는 Sidekiq 서버로 SSH를 통해 이 명령을 실행합니다.
```
sudo gitlab-rake gitlab:geo:check
```
확인 사항 중 하나라도 실패하는 경우 문제 해결 문서를 확인하세요.

보조 사이트가 Geo 관리 페이지에 추가되고 다시 시작되면, 해당 사이트에서 주 사이트에서 누락된 데이터를 백필이라는 프로세스로 자동으로 복제하기 시작합니다.

한편, 주 사이트는 각 보조 사이트에 변경 사항을 알림으로써 보조 사이트가 즉시 해당 알림에 대응할 수 있도록 합니다.

보조 사이트가 실행되고 액세스할 수 있는지 확인하세요. 주 사이트에서 사용된 것과 동일한 인증 정보로 보조 사이트에 로그인할 수 있습니다.

HTTP/HTTPS 및 SSH를 통한 Git 액세스 활성화

Geo는 저장소를 HTTP/HTTPS로 동기화하기 때문에 (새 설치에 대해 기본적으로 활성화됨) 이 클론 방법을 활성화해야 합니다. 기존 사이트를 Geo로 변환하는 경우 클론 방법이 활성화되어 있는지 확인해야 합니다.

주 사이트에서:

왼쪽 사이드바에서 아래로 스크롤하여 관리 영역을 선택합니다.
설정 > 일반을 선택합니다.
가시성 및 액세스 제어를 확장합니다.
SSH를 사용하는 경우:
1. 활성화된 Git 액세스 프로토콜이 SSH 및 HTTP(S) 둘 다로 설정되어 있는지 확인합니다.
2. 기본 사이트와 보조 사이트 모두에서 데이터베이스에서 권한 부여된 SSH 키를 빠르게 조회하는것을 활성화합니다.
SSH를 사용하지 않는 경우, 활성화된 Git 액세스 프로토콜을 오직 HTTP(S)로 설정합니다.

보조 사이트의 정상 작동 확인

주 사이트에서 사용한 인증 정보로 보조 사이트에 로그인할 수 있습니다.

로그인한 후:

왼쪽 사이드바에서 아래로 스크롤하여 관리 영역을 선택합니다.
Geo > Sites를 선택합니다.
사이트가 올바르게 보조 Geo 사이트로 식별되었는지, 그리고 Geo가 활성화되었는지 확인합니다.

초기 복제에는 시간이 소요될 수 있습니다. 주 사이트의 브라우저에 있는 Geo Sites 대시보드에서 각 Geo 사이트의 동기화 프로세스를 모니터링할 수 있습니다.

추적 데이터베이스 구성

참고: 이 단계는 추적 데이터베이스를 다른 서버의 외부에 설정하려는 경우 선택 사항입니다.

Secondary 사이트는 복제 상태를 추적하고 잠재적인 복제 문제로부터 자동으로 복구하기 위해 별도의 PostgreSQL 설치를 사용합니다. Linux 패키지는 roles ['geo_secondary_role']이 설정되면 추적 데이터베이스를 자동으로 구성합니다. Linux 패키지 설치 외부에서 이 데이터베이스를 실행하려는 경우 다음 지침을 사용하세요.

클라우드 관리 데이터베이스 서비스

추적 데이터베이스에 클라우드 관리 서비스를 사용하는 경우 추적 데이터베이스 사용자에 추가 역할을 부여해야 할 수 있습니다(기본적으로 gitlab_geo입니다):

Amazon RDS는 rds_superuser 역할이 필요합니다.
Azure Database for PostgreSQL은 azure_pg_admin 역할이 필요합니다.
Google Cloud SQL은 cloudsqlsuperuser 역할이 필요합니다.

설치 중과 업그레이드 중에 확장 기능을 설치하는 데 추가 역할이 필요합니다. 대안으로 확장 기능을 수동으로 설치하고, 미래의 GitLab 업그레이드 중에 발생할 수 있는 문제에 대해 읽어보세요.

참고: Amazon RDS를 추적 데이터베이스로 사용하려면 보조 데이터베이스가 액세스할 수 있도록 설정하세요. 유감스럽게도 동일한 보안 그룹을 할당하는 것만으로는 부족하며 RDS PostgreSQL 데이터베이스에는 외부 룰이 적용되지 않습니다. 따라서 5432번 포트에서 추적 데이터베이스로부터의 모든 TCP 트래픽을 허용하는 읽기 전용 레플리카 보안 그룹에 내부 룰을 명시적으로 추가해야 합니다.

추적 데이터베이스 생성

PostgreSQL 인스턴스에서 추적 데이터베이스를 만들고 구성하세요:

데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정하세요.
gitlab_geo 사용자를 선택한 비밀번호로 설정하고, gitlabhq_geo_production 데이터베이스를 생성하고, 사용자를 데이터베이스의 소유자로 지정하세요. 이러한 설정의 예는 자체 컴파일 설치 설명서에서 확인할 수 있습니다.
클라우드 관리 PostgreSQL 데이터베이스를 사용하지 않는 경우 보조 사이트가 추적 데이터베이스와 통신할 수 있도록 추적 데이터베이스와 연결된 pg_hba.conf를 수동으로 변경하세요. 변경 사항이 적용되도록 PostgreSQL을 재시작해야 합니다.
```
##
## Geo 추적 데이터베이스 역할
## - pg_hba.conf
##
host    all         all               <신뢰할 수 있는 추적 IP>/32      md5
host    all         all               <신뢰할 수 있는 보조 IP>/32     md5
```

GitLab 구성

GitLab을 이 데이터베이스를 사용하도록 구성하세요. 이 단계는 Linux 패키지 및 Docker 배포를 위한 것입니다.

GitLab secondary 서버에 SSH로 로그인하고, 루트로 전환하세요:
```
sudo -i
```

/etc/gitlab/gitlab.rb 파일을 편집하여 PostgreSQL 인스턴스가 있는 기계의 연결 매개변수와 자격 증명을 추가하세요:

geo_secondary['db_username'] = 'gitlab_geo'
geo_secondary['db_password'] = '<여기에 비밀번호 입력>'

geo_secondary['db_host'] = '<추적_데이터베이스_호스트>'
geo_secondary['db_port'] = <추적_데이터베이스_포트>      # 올바른 포트로 변경
geo_postgresql['enable'] = false     # 내부 관리형 인스턴스를 사용하지 않음

파일을 저장하고 GitLab을 다시 구성하세요:
```
gitlab-ctl reconfigure
```

데이터베이스 스키마 수동 설정(선택 사항)

위의 단계에서 reconfigure는 이러한 단계를 자동으로 처리합니다. 이러한 단계는 실패한 경우에 제공됩니다.

이 작업은 데이터베이스 스키마를 만듭니다. 데이터베이스 사용자가 슈퍼 사용자 여야 합니다.
```
sudo gitlab-rake db:create:geo
```
Rails 데이터베이스 마이그레이션(스키마 및 데이터 업데이트) 적용은 reconfigure에 의해 수행됩니다. geo_secondary['auto_migrate'] = false로 설정되어 있거나 스키마가 수동으로 생성된 경우, 이 단계가 필요합니다:
```
sudo gitlab-rake db:migrate:geo
```

문제 해결

Geo 문제 해결을 참조하세요.

두 개의 단일 노드 사이트를 위한 Geo 설정(외부 PostgreSQL 서비스 사용)

Linux 패키지(Omnibus)를 위한 Geo 설정

기본 사이트 구성

외부 데이터베이스 구성

클라우드 제공업체의 도구를 활용하여 기본 데이터베이스 복제

보조 사이트를 외부 읽기 전용 레플리카 사용하도록 구성

GitLab 비밀 값 수동 복제

기본 사이트 SSH 호스트 키 수동 복제

권한 부여된 SSH 키의 빠른 조회 설정

보조 사이트 추가

HTTP/HTTPS 및 SSH를 통한 Git 액세스 활성화

보조 사이트의 정상 작동 확인

추적 데이터베이스 구성

클라우드 관리 데이터베이스 서비스

추적 데이터베이스 생성

GitLab 구성

데이터베이스 스키마 수동 설정(선택 사항)

문제 해결

도움말

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

도움받기