외부 Gitaly를 사용하여 GitLab 차트 구성

이 문서는 외부 Gitaly 서비스로 Helm 차트를 구성하는 방법에 대한 설명서를 제공하고자 합니다.

Gitaly를 구성하지 않은 경우, 온프레미스용이나 VM에 배포할 경우 Linux 패키지를 고려해 보세요.

참고: 외부 Gitaly _서비스_는 Gitaly 노드나 Praefect 클러스터에서 제공될 수 있습니다.

차트 구성

포함된 Gitaly 차트를 비활성화하고 해당 차트가 제공하는 Gitaly 서비스를 외부 서비스로 지정하세요.

다음 속성을 설정해야 합니다:

global.gitaly.enabled: 포함된 Gitaly 차트를 비활성화하려면 false로 설정하세요.
global.gitaly.external: 외부 Gitaly 서비스들의 배열입니다.
global.gitaly.authToken.secret: 인증을 위한 토큰을 포함하는 시크릿의 이름입니다.
global.gitaly.authToken.key: 토큰 내용이 포함된 시크릿 내의 키입니다.

외부 Gitaly 서비스들은 해당 자체의 GitLab Shell 인스턴스를 사용할 것입니다. 귀하의 구현에 따라 해당 내용을 이 차트의 시크릿으로 구성하거나 사전에 정의된 소스에서 이 차트의 시크릿을 구성할 수 있습니다.

다음 속성을 설정해야 할 수 있습니다:

global.shell.authToken.secret: GitLab Shell의 시크릿을 포함하는 시크릿의 이름입니다.
global.shell.authToken.key: 시크릿 내의 키로, 해당 키에 비밀 내용이 포함됩니다.

두 개의 외부 서비스를 사용한 완전한 예제 구성 (external-gitaly.yml)는 다음과 같습니다:

global:
  gitaly:
    enabled: false
    external:
      - name: default                   # 필수
        hostname: node1.git.example.com # 필수
        port: 8075                      # 선택 사항, 표시된 기본값
      - name: praefect                  # 필수
        hostname: ha.git.example.com    # 필수
        port: 2305                      # Praefect는 포트 2305를 사용합니다
        tlsEnabled: false               # 선택 사항, gitaly.tls.enabled를 재정의함
    authToken:
      secret: external-gitaly-token     # 필수
      key: token                        # 선택 사항, 표시된 기본값
    tls:
      enabled: false                    # 선택 사항, 표시된 기본값

위의 구성 파일을 사용하여 다른 설정과 함께 설치 예제는 다음과 같습니다 (gitlab.yml을 사용):

helm upgrade --install gitlab gitlab/gitlab  \
  -f gitlab.yml \
  -f external-gitaly.yml

여러 외부 Gitaly

귀하의 구현이 이 차트와 외부 Gitaly 노드를 여러 개 사용하는 경우, 필요한 복잡성을 허용하도록 구문이 약간 다릅니다.

예제 값 파일이 제공됩니다. 해당 값 파일의 내용은 --set 인수를 통해 정확히 해석되지 않으므로 Helm에 -f / --values 플래그를 통해 전달해야 합니다.

TLS를 통한 외부 Gitaly 연결

외부 Gitaly 서버가 TLS 포트를 통해 수신하는 경우, GitLab 인스턴스가 TLS을 통해 해당 서버와 통신하도록 설정할 수 있습니다. 다음 단계를 따르세요.

Gitaly 서버의 인증서를 포함하는 Kubernetes 시크릿을 만듭니다.

kubectl create secret generic gitlab-gitaly-tls-certificate --from-file=gitaly-tls.crt=<인증서 경로>

외부 Gitaly 서버의 인증서를 사용자 지정 인증 기관 목록에 추가하세요. 값 파일에서 다음을 지정하세요.
```
global:
  certificates:
    customCAs:
      - secret: gitlab-gitaly-tls-certificate
```
또는 다음을 사용하여 helm upgrade 명령에 전달하세요. --set
```
--set global.certificates.customCAs[0].secret=gitlab-gitaly-tls-certificate
```

모든 Gitaly 인스턴스에 대해 TLS를 활성화하려면 global.gitaly.tls.enabled: true로 설정하세요.

global:
  gitaly:
    tls:
      enabled: true

개별적으로 활성화하려면 해당 항목의 tlsEnabled: true로 설정하세요.

global:
  gitaly:
    external:
      - name: default
        hostname: node1.git.example.com
        tlsEnabled: true

참고: 고유한 유효한 시크릿 이름 및 키를 선택할 수 있지만 충돌을 피하기 위해 customCAs에 지정된 모든 시크릿에서 키가 고유하도록 하세요. 모든 시크릿에 포함된 모든 키가 올바르게 마운트되기 때문에 인증서 키를 제공하지 않아도 됩니다. 이것은 클라이언트 측 기능이기 때문입니다.

GitLab이 Gitaly에 연결할 수 있는지 테스트

GitLab이 외부 Gitaly 서버에 연결할 수 있는지 확인하려면 다음을 실행하세요:

kubectl exec -it <toolbox-pod> -- gitlab-rake gitlab:gitaly:check

Gitaly를 TLS로 사용하는 경우, GitLab Chart가 Gitaly 인증서를 신뢰하는지 확인할 수도 있습니다:

kubectl exec -it <toolbox-pod> -- echo | /usr/bin/openssl s_client -connect <gitaly-host>:<gitaly-port>

Gitaly 차트에서 외부 Gitaly로 마이그레이션

Gitaly 차트를 사용하여 Gitaly 서비스를 제공하고 있고 모든 리포지토리를 외부 Gitaly 서비스로 마이그레이션해야 하는 경우 다음 중 하나의 방법으로 수행할 수 있습니다:

리포지토리 저장소 이동 API를 사용하여 마이그레이션(권장).
백업/복원 방법을 사용하여 마이그레이션.

리포지토리 저장소 이동 API를 사용하여 마이그레이션

이 방법은:

리포지토리 저장소 이동 API를 사용하여 Gitaly 차트에서 외부 Gitaly 서비스로 리포지토리를 마이그레이션합니다.
제로 다운타임으로 수행할 수 있습니다.
외부 Gitaly 서비스가 Gitaly 팟과 동일한 VPC/존에 있는 것을 요구합니다.
Praefect 차트와 테스트되지 않았으며 지원되지 않습니다.

단계 1: 외부 Gitaly 서비스 또는 Gitaly 클러스터 설정

외부 Gitaly 또는 외부 Gitaly 클러스터를 설정합니다. 이러한 단계 중 하나로 차트 설치에서 Gitaly 토큰 및 GitLab Shell 비밀을 제공해야합니다:

# GitLab Shell 비밀 가져오기
kubectl get secret <release>-gitlab-shell-secret -ojsonpath='{.data.secret}' | base64 -d

# Gitaly 토큰 가져오기
kubectl get secret <release>-gitaly-secret -ojsonpath='{.data.token}' | base64 -d

Gitaly

여기에서 추출한 Gitaly 토큰은 AUTH_TOKEN 값에 사용되어야합니다.
여기에서 추출한 GitLab Shell 비밀은 shellsecret 값에 사용되어야합니다.

Gitaly 클러스터

여기에서 추출한 Gitaly 토큰은 PRAEFECT_EXTERNAL_TOKEN에 사용되어야합니다.
여기에서 추출한 GitLab Shell 비밀은 GITLAB_SHELL_SECRET_TOKEN 값에 사용되어야합니다.

마지막으로, 외부 Gitaly 서비스의 방화벽이 쿠버네티스 파드 IP 범위에서 구성된 Gitaly 포트에 대한 트래픽을 허용하는지 확인하십시오.

단계 2: 새로운 Gitaly 서비스를 사용하도록 인스턴스 구성

GitLab이 외부 Gitaly를 사용하도록 구성합니다. 기본 gitlab.yml 구성 파일에서 Gitaly 참조가 있다면 해당 참조를 제거하고 다음 콘텐츠가 포함된 새로운 mixed-gitaly.yml 파일을 만듭니다.

이전에 추가적인 Gitaly 저장소를 정의한 경우 새 구성에서 동일한 이름을 가진 Gitaly 저장소가 지정되어 있는지 확인해야합니다. 그렇지 않으면 복구 작업이 실패합니다.

TLS를 구성하는 경우 TLS를 통해 외부 Gitaly에 연결하는 섹션을 참조하십시오:

Gitaly

global:
  gitaly:
    internal:
      names:
        - default
    external:
      - name: ext-gitaly                # 필수
        hostname: node1.git.example.com # 필수
        port: 8075                      # 선택 사항, 표시된 기본값
        tlsEnabled: false               # 선택 사항, gitaly.tls.enabled를 재정의합니다

Gitaly 클러스터

global:
  gitaly:
    internal:
      names:
        - default
    external:
      - name: ext-gitaly-cluster        # 필수
        hostname: ha.git.example.com    # 필수
        port: 2305                      # Praefect는 포트 2305를 사용합니다
        tlsEnabled: false               # 선택 사항, gitaly.tls.enabled를 재정의합니다

gitlab.yml 및 mixed-gitaly.yml 파일을 사용하여 새 구성을 적용합니다:

helm upgrade --install gitlab gitlab/gitlab \
  -f gitlab.yml \
  -f mixed-gitaly.yml

Toolbox 팟에서 확인하여 GitLab이 외부 Gitaly에 성공적으로 연결하는지 확인합니다:
```
kubectl exec <toolbox pod name> -it -- gitlab-rake gitlab:gitaly:check
```
외부 Gitaly가 차트 설치에 다시 연결할 수 있는지 확인하십시오:
Gitaly

Gitaly 서비스가 GitLab API에 대한 콜백을 성공적으로 수행할 수 있도록 확인하십시오:
```
sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml
```
Gitaly 클러스터

Praefect 노드 전체에서 Praefect 서비스가 Gitaly 노드에 연결할 수 있는지 확인하십시오:
```
# Praefect 노드에서 실행
sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dial-nodes
```
Gitaly 노드 전체에서 Gitaly 서비스가 GitLab API에 대한 콜백을 성공적으로 수행할 수 있도록 확인하십시오:
```
# Gitaly 노드에서 실행
sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml
```

단계 3: Gitaly 팟 IP 및 호스트명 가져오기

저장소 저장 이동 API가 성공하려면 외부 Gitaly 서비스가 포드 서비스 호스트명을 사용하여 Gitaly 팟에 다시 연결할 수 있어야합니다. 포드 서비스 호스트명을 해결할 수 있도록 하기 위해 Gitaly 프로세스를 실행하는 각 외부 Gitaly 서비스의 호스트 파일에 호스트명을 추가해야합니다.

Gitaly 팟 및 해당 내부 IP 주소/호스트명 목록을 가져옵니다:

kubectl get pods -l app=gitaly -o jsonpath='{range .items[*]}{.status.podIP}{"\t"}{.spec.hostname}{"."}{.spec.subdomain}{"."}{.metadata.namespace}{".svc\n"}{end}'

마지막 단계에서 출력을 각 외부 Gitaly 서비스의 호스트 파일(/etc/hosts)에 추가합니다.
각 외부 Gitaly 서비스가 Gitaly 팟 호스트명을 핑할 수 있는지 확인하십시오:
```
ping <gitaly pod hostname>
```

연결이 확인되면 저장소 저장 이동을 예약할 수 있습니다.

단계 4: 저장소 저장 이동 예약

저장소 이동에서 지시된 단계를 따라 이동을 예약합니다.

단계 5: 최종 구성 및 유효성 검사

여러 Gitaly 저장소가 있는 경우 새로운 저장소가 저장되는 위치를 구성하십시오.
외부 Gitaly 구성이 포함된 미래용 gitlab.yml을 생성하는 것을 고려하십시오:
```
helm get values <RELEASE_NAME> -o yaml > gitlab.yml
```

gitlab.yml 파일에서 내부 Gitaly subchart를 비활성화하고 새 default 저장소를 외부 Gitaly 서비스로 지정하십시오. GitLab에는 기본 저장소가 필요합니다:

Gitaly

global:
  gitaly:
    enabled: false                      # 내부 Gitaly subchart 비활성화
    external:
      - name: ext-gitaly                # 필수
        hostname: node1.git.example.com # 필수
        port: 8075                      # 선택 사항, 표시된 기본값
        tlsEnabled: false               # 선택 사항, gitaly.tls.enabled를 재정의합니다
      - name: default                   # 기본 저장소 추가, ext-gitaly와 동일한 설정 사용
        hostname: node1.git.example.com
        port: 8075
        tlsEnabled: false

Gitaly 클러스터

global:
  gitaly:
    enabled: false                      # 내부 Gitaly subchart 비활성화
    external:
      - name: ext-gitaly-cluster        # 필수
        hostname: ha.git.example.com    # 필수
        port: 2305                      # Praefect는 포트 2305를 사용합니다
        tlsEnabled: false               # 선택 사항, gitaly.tls.enabled를 재정의합니다
      - name: default                   # 기본 저장소 추가, ext-gitaly-cluster와 동일한 설정 사용
        hostname: ha.git.example.com
        port: 2305
        tlsEnabled: false

새 구성을 적용합니다:

helm upgrade --install gitlab gitlab/gitlab \
  -f gitlab.yml

선택 사항. Gitaly 팟 IP 및 호스트명 가져오기 단계를 따른 후 각 외부 Gitaly의 /etc/hosts 파일로 가한 변경을 제거하십시오.
모든 것이 예상대로 작동하는지 확인한 후 Gitaly PVC를 삭제할 수 있습니다:
경고: 모든 것이 예상대로 작동하는지 반드시 확인한 후에 Gitaly PVC를 삭제하지 마십시오.
```
kubectl delete pvc repo-data-<release>-gitaly-0
```

백업/복원 방법을 사용하여 이주하기

이 방법은 다음을 수행합니다.

Gitaly 차트 PersistentVolumeClaim (PVC)에서 귀하의 저장소를 백업한 다음 외부 Gitaly 서비스로 복원합니다.
모든 사용자에 대해 다운타임이 발생합니다.
Praefect chart 및 지원되지 않습니다.

단계 1: GitLab Chart의 현재 릴리스 리비전 가져오기

이주 중에 뭔가 잘못될 경우 GitLab Chart의 현재 릴리스 리비전을 가져옵니다. 출력을 복사하여 경우에 따라 롤백을 수행해야 할 수도 있으므로 따로 둡니다.

helm history <release> --max=1

단계 2: 외부 Gitaly 서비스 또는 Gitaly 클러스터 설정

외부 Gitaly 또는 외부 Gitaly 클러스터를 설정합니다. 이러한 단계 중 일부로 차트 설치에서 Gitaly 토큰 및 GitLab Shell 비밀을 제공해야 합니다.

# GitLab Shell 비밀 가져오기
kubectl get secret <release>-gitlab-shell-secret -ojsonpath='{.data.secret}' | base64 -d

# Gitaly 토큰 가져오기
kubectl get secret <release>-gitaly-secret -ojsonpath='{.data.token}' | base64 -d

Gitaly

여기서 추출한 Gitaly 토큰은 AUTH_TOKEN 값을 위해 사용되어야 합니다.
여기서 추출한 GitLab Shell 비밀은 shellsecret 값으로 사용되어야 합니다.

Gitaly Cluster

여기서 추출한 Gitaly 토큰은 PRAEFECT_EXTERNAL_TOKEN 값을 위해 사용되어야 합니다.
여기서 추출한 GitLab Shell 비밀은 GITLAB_SHELL_SECRET_TOKEN 값으로 사용되어야 합니다.

단계 3: 이주 중 Git 변경이 불가능한지 확인

이주의 데이터 무결성을 보장하기 위해 Git 저장소에 대한 변경 사항이 발생하지 않도록 합니다.

1. 유지 보수 모드 활성화

GitLab Enterprise Edition을 사용하는 경우 UI, API 또는 Rails 콘솔을 통해 유지 보수 모드를 활성화합니다.

kubectl exec <toolbox pod name> -it -- gitlab-rails runner 'Gitlab::CurrentSettings.update!(maintenance_mode: true)'

2. Runner pods 축소

GitLab Community Edition을 사용하는 경우, 클러스터에서 실행 중인 모든 GitLab Runner pods를 축소해야 합니다. 이것은 Runners가 CI/CD 작업을 처리하기 위해 GitLab에 연결하는 것을 방지합니다.

GitLab Enterprise Edition을 사용하는 경우, 유지 보수 모드는 클러스터의 Runners가 GitLab에 연결하는 것을 방지하기 때문에 이 단계는 선택 사항입니다.

# 현재 Runners의 복제본 수를 메모해두어 나중에 이 수로 확장할 수 있도록 합니다
kubectl get deploy -lapp=gitlab-gitlab-runner,release=<release> -o jsonpath='{.items[].spec.replicas}{"\n"}'

# Runners pods를 0으로 축소합니다
kubectl scale deploy -lapp=gitlab-gitlab-runner,release=<release> --replicas=0

3. CI 작업이 실행 중이 아닌지 확인

관리 영역으로 이동하여 CI/CD > 작업으로 이동합니다. 이 페이지에서 모든 작업이 표시되지만 실행 중 상태의 작업이 없는지 확인합니다. 다음 단계로 진행하기 전에 작업이 완료될 때까지 기다려야 합니다.

4. Sidekiq cron 작업 비활성화

이주 중에 Sidekiq 작업이 예약되고 실행되는 것을 방지하기 위해 모든 Sidekiq cron 작업을 비활성화합니다.

kubectl exec <toolbox pod name> -it -- gitlab-rails runner 'Sidekiq::Cron::Job.all.map(&:disable!)'

5. 백그라운드 작업이 실행 중이 아닌지 확인

다음 단계로 진행하기 전에 대기하 준비가 완료되었는지 확인해야 합니다.

관리 영역으로 이동하여 모니터링로 이동하고 백그라운드 작업을 선택합니다.
Sidekiq 대시보드에서 대기열을 선택한 후 실시간 폴링을 선택합니다.
바쁨 및 대기분이 0으로 감소할 때까지 기다립니다.

6. Sidekiq 및 Webservice pods 축소

일관된 백업이 이루어질 수 있도록 Sidekiq 및 Webservice pods 수를 축소합니다.

Sidekiq pods는 복원 단계 중에 다시 확장되고
외부 Gitaly 서비스로 전환한 후 Webservice pods가 연결성을 테스트 한 후에 다시 확장됩니다.

# 현재 Sidekiq 및 Webservice의 복제본 수를 메모해두어 나중에 이 수로 확장할 수 있도록 합니다
kubectl get deploy -lapp=sidekiq,release=<release> -o jsonpath='{.items[].spec.replicas}{"\n"}'
kubectl get deploy -lapp=webservice,release=<release> -o jsonpath='{.items[].spec.replicas}{"\n"}'

# Sidekiq 및 Webservice pods를 0으로 축소합니다
kubectl scale deploy -lapp=sidekiq,release=<release> --replicas=0
kubectl scale deploy -lapp=webservice,release=<release> --replicas=0

7. 클러스터로의 외부 연결 제한

GitLab에 대한 모든 불필요한 연결을 제한하여 Git 변경이 발생하지 않도록 합니다.

이러한 단계가 완료되면 복원이 완료될 때까지 브라우저에서 GitLab이 완전히 사용할 수 없습니다.

이주 동안 클러스터가 새로운 외부 Gitaly 서비스에 접근할 수 있도록 하기 위해 nginx-ingress 구성에 외부 예외로서 외부 Gitaly 서비스의 IP 주소를 추가해야 합니다.

다음 내용과 같은 ingress-only-allow-ext-gitaly.yml 파일을 생성합니다.
```
nginx-ingress:
  controller:
    service:
      loadBalancerSourceRanges:
       - "x.x.x.x/32"
```
x.x.x.x에 외부 Gitaly 서비스의 IP 주소를 입력합니다.

새 구성을 gitlab.yml 및 ingress-only-allow-ext-gitaly.yml 파일을 사용하여 적용합니다.

helm upgrade <release> gitlab/gitlab \
  -f gitlab.yml \
  -f ingress-only-allow-ext-gitaly.yml

8. 저장소 체크섬 목록 생성

백업을 실행하기 전에 모든 GitLab 저장소를 확인하고 저장소 체크섬 목록을 생성합니다. 마이그레이션 후 체크섬을 diff할 수 있도록 내용을 파일로 보냅니다.

kubectl exec <toolbox pod name> -it -- gitlab-rake gitlab:git:checksum_projects > ~/checksums-before.txt

단계 4: 모든 저장소 백업

저장소만 백업하십시오.

kubectl exec <toolbox pod name> -it -- backup-utility --skip artifacts,ci_secure_files,db,external_diffs,lfs,packages,pages,registry,terraform_state,uploads

단계 5: 새로운 Gitaly 서비스를 사용하도록 인스턴스 구성

Gitaly 서브차트를 비활성화하고 GitLab을 외부 Gitaly를 사용하도록 구성하십시오. gitlab.yml 구성 파일에 Gitaly 참조가 있으면 해당 항목을 제거하고 다음 내용으로 새 external-gitaly.yml 파일을 만드십시오.

이전에 추가로 정의한 Gitaly 저장소가 있는 경우 새 구성에서 동일한 이름의 Gitaly 저장소가 지정되었는지 확인하여 복원 작업이 실패하지 않도록 하십시오.

TLS를 구성하려면 TLS를 통한 외부 Gitaly에 연결 섹션을 참조하십시오.

Gitaly

global:
  gitaly:
    enabled: false
    external:
      - name: default                   # required
        hostname: node1.git.example.com # required
        port: 8075                      # optional, default shown
        tlsEnabled: false               # optional, overrides gitaly.tls.enabled

Gitaly 클러스터

global:
  gitaly:
    enabled: false
    external:
      - name: default                   # required
        hostname: ha.git.example.com    # required
        port: 2305                      # Praefect uses port 2305
        tlsEnabled: false               # optional, overrides gitaly.tls.enabled

gitlab.yml, ingress-only-allow-ext-gitaly.yml, 및 external-gitaly.yml 파일을 사용하여 새 구성을 적용하십시오:

helm upgrade --install gitlab gitlab/gitlab \
  -f gitlab.yml \
  -f ingress-only-allow-ext-gitaly.yml \
  -f external-gitaly.yml

Webservice pods를 원래의 복제본 수로 확장하십시오. 이는 이후 단계에서 GitLab이 외부 Gitaly에 정상적으로 연결되는지 테스트하기 위해 필요합니다.
```
kubectl scale deploy -lapp=webservice,release=<release> --replicas=<value>
```
Toolbox pod에서 GitLab이 외부 Gitaly에 성공적으로 연결되는지 확인하십시오.
```
kubectl exec <toolbox pod name> -it -- gitlab-rake gitlab:gitaly:check
```
외부 Gitaly가 Chart 설치에 다시 연결할 수 있는지 확인하십시오:
Gitaly

Gitaly 서비스가 GitLab API에 대한 콜백을 성공적으로 수행할 수 있는지 확인하십시오.
```
sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml
```
Gitaly 클러스터

모든 Praefect 노드에서 Praefect 서비스가 Gitaly 노드에 연결할 수 있는지 확인하십시오.
```
# Praefect 노드에서 실행
sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dial-nodes
```
모든 Gitaly 노드에서 Gitaly 서비스가 GitLab API에 대한 콜백을 성공적으로 수행할 수 있는지 확인하십시오.
```
# Gitaly 노드에서 실행
sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml
```

단계 6: 백업 복원 및 검증

이전에 생성한 백업 파일을 복원하십시오. 결과적으로 저장소는 구성된 외부 Gitaly 또는 Gitaly 클러스터로 복사됩니다.
모든 GitLab 저장소를 확인하고 저장소 체크섬 목록을 만드십시오. 다음 단계에서 체크섬을 diff할 수 있도록 결과를 파일로 보냅니다:
```
kubectl exec <toolbox pod name> -it -- gitlab-rake gitlab:git:checksum_projects  > ~/checksums-after.txt
```
저장소 마이그레이션 전후의 저장소 체크섬을 비교하십시오. 체크섬이 동일하면 이 명령은 출력을 반환하지 않습니다:
```
diff ~/checksums-before.txt ~/checksums-after.txt
```
특정 라인의 빈 체크섬이 0000000000000000000000000000000000000000으로 변경된 것을 diff 결과에서 관찰하면, 이는 예상된 것으로 안심하고 무시해도 됩니다.

단계 7: 최종 구성 및 검증

외부 사용자 및 GitLab Runners가 다시 GitLab에 연결할 수 있도록 gitlab.yml 및 external-gitaly.yml 파일을 적용하십시오. ingress-only-allow-ext-gitaly.yml을 지정하지 않았으므로 IP 제한이 제거됩니다:
```
 helm upgrade <release> gitlab/gitlab \
   -f gitlab.yml \
   -f external-gitaly.yml
```
외부 Gitaly 구성이 포함된 향후에 사용할 수 있는 통합 gitlab.yml을 생성하는 것을 고려하십시오:
```
 helm get values <release> gitlab/gitlab -o yaml > gitlab.yml
```
GitLab Enterprise Edition을 사용 중인 경우, 유지 관리 모드를 해제하십시오. UI, API 또는 Rails 콘솔을 통해 수행할 수 있습니다:
```
kubectl exec <toolbox pod name> -it -- gitlab-rails runner 'Gitlab::CurrentSettings.update!(maintenance_mode: false)'
```
여러 Gitaly 저장소를 사용 중인 경우, 새로운 저장소가 저장되는 위치를 구성하십시오.

Sidekiq cron 작업을 활성화하십시오:

kubectl exec <toolbox pod name> -it -- gitlab-rails runner 'Sidekiq::Cron::Job.all.map(&:enable!)'

Runner pods를 원래의 복제본 수로 확장하십시오.

kubectl scale deploy -lapp=gitlab-gitlab-runner,release=<release> --replicas=<value>

모든 것이 예상대로 작동하는 것을 확인한 후 Gitaly PVC를 삭제할 수 있습니다.
경고: 단계 6에서 체크섬이 일치하고 모든 것이 예상대로 작동하는지 다시 한번 확인하기 전에 Gitaly PVC를 삭제하지 마십시오.
```
kubectl delete pvc repo-data-<release>-gitaly-0
```

롤백

문제가 발생하면 변경 사항을 롤백하여 기존의 Gitaly subchart를 다시 사용할 수 있습니다.

원본 Gitaly PVC는 성공적으로 롤백하려면 존재해야 합니다.

Step 1: Get the current release revision of the GitLab Chart에서 얻은 버전 번호를 사용하여 GitLab 차트를 이전 릴리스로 롤백합니다:
```
helm rollback <릴리스> <리비전>
```
Webservice 팟을 원래의 레플리카 수로 확장합니다(실행 중이 아닌 경우):
```
kubectl scale deploy -lapp=webservice,release=<릴리스> --replicas=<값>
```
Sidekiq 팟을 원래의 레플리카 수로 확장합니다(실행 중이 아닌 경우):
```
kubectl scale deploy -lapp=sidekiq,release=<릴리스> --replicas=<값>
```

이전에 비활성화한 경우 Sidekiq cron 작업을 활성화합니다:

kubectl exec <toolbox pod 이름> -it -- gitlab-rails runner 'Sidekiq::Cron::Job.all.map(&:enable!)'

Runner 팟을 원래의 레플리카 수로 확장합니다(실행 중이 아닌 경우):
```
kubectl scale deploy -lapp=gitlab-gitlab-runner,release=<릴리스> --replicas=<값>
```
GitLab Enterprise Edition을 사용하는 경우 유지 보수 모드를 사용 중이라면 비활성화합니다.

외부 Gitaly를 사용하여 GitLab 차트 구성

차트 구성

여러 외부 Gitaly

TLS를 통한 외부 Gitaly 연결

GitLab이 Gitaly에 연결할 수 있는지 테스트

Gitaly 차트에서 외부 Gitaly로 마이그레이션

리포지토리 저장소 이동 API를 사용하여 마이그레이션

단계 1: 외부 Gitaly 서비스 또는 Gitaly 클러스터 설정

단계 2: 새로운 Gitaly 서비스를 사용하도록 인스턴스 구성

단계 3: Gitaly 팟 IP 및 호스트명 가져오기

단계 4: 저장소 저장 이동 예약

단계 5: 최종 구성 및 유효성 검사

백업/복원 방법을 사용하여 이주하기

단계 1: GitLab Chart의 현재 릴리스 리비전 가져오기

단계 2: 외부 Gitaly 서비스 또는 Gitaly 클러스터 설정

단계 3: 이주 중 Git 변경이 불가능한지 확인

단계 4: 모든 저장소 백업

단계 5: 새로운 Gitaly 서비스를 사용하도록 인스턴스 구성

단계 6: 백업 복원 및 검증

단계 7: 최종 구성 및 검증

롤백

관련 문서

도움말

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

도움받기