외부 Gitaly로 GitLab 차트 구성하기

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

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=<path to certificate>

외부 Gitaly 서버의 인증서를 커스텀 인증 기관 목록에 추가합니다. 값 파일에서 다음을 지정하세요.
```
global:
  certificates:
    customCAs:
      - secret: gitlab-gitaly-tls-certificate
```
또는 --set를 사용하여 helm upgrade 명령에 전달합니다.
```
--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

TLS로 Gitaly를 사용하는 경우, 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 차트와 함께 테스트되지 않았으며 지원되지 않습니다.

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

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

# 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 서비스의 방화벽이 Kubernetes 팟 IP 범위에서 설정된 Gitaly 포트로 트래픽을 허용하는지 확인합니다.

Step 2: 인스턴스를 새 Gitaly 서비스 사용하도록 구성

GitLab을 외부 Gital리를 사용하도록 구성합니다.

gitlab.yml 구성 파일에 Gitaly 참조가 있는 경우 이를 제거하고 다음 내용을 포함한 새 mixed-gitaly.yml 파일을 생성합니다.

기존에 추가 Gitaly 저장소를 정의한 경우, 새 구성에서 동일한 이름의 일치하는 Gitaly 저장소가 지정되었는지 확인해야 하며, 그렇지 않으면 복원 작업이 실패합니다.

TLS를 구성하는 경우 외부 Gital리와 TLS 연결 섹션을 참조하십시오:

Gitaly

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

Gitaly 클러스터

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

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

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

Toolbox 팟에서 GitLab이 외부 Gital리에 성공적으로 연결되는지 확인합니다:
```
kubectl exec <toolbox pod name> -it -- gitlab-rake gitlab:gitaly:check
```
외부 Gital리가 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
```

3단계: Gitaly pod 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 프로세스를 실행 중인 각 외부 Gitaly 서비스의 /etc/hosts 파일에 추가합니다.
Gitaly 프로세스를 실행 중인 각 외부 Gitaly 서비스에서 Gitaly 포드 호스트 이름에 핑이 가능함을 확인합니다:
```
ping <gitaly pod hostname>
```

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

4단계: 저장소 이동 예약

저장소 이동에서 지침에 따라 이동을 예약합니다.

5단계: 최종 구성 및 검증

Gitaly 저장소가 여러 개 있는 경우, 새 저장소가 저장될 위치 구성합니다.
외부 Gitaly 구성을 포함하는 통합된 gitlab.yml을 생성하는 것을 고려합니다:
```
helm get values <RELEASE_NAME> -o yaml > gitlab.yml
```

gitlab.yml 파일에서 내부 Gitaly 서브차트를 비활성화하고 새로운 default 저장소를 외부 Gitaly 서비스로 지정합니다. GitLab은 기본 저장소 구성이 필요합니다:

Gitaly

global:
  gitaly:
    enabled: false                      # 내부 Gitaly 서브차트 비활성화
    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 서브차트 비활성화
    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 pod IP 및 호스트 이름 가져오기 단계를 수행한 후 각 외부 Gitaly의 /etc/hosts 파일에서 수행한 변경 사항을 제거합니다.
모든 것이 예상대로 작동함을 확인한 후, Gitaly PVC를 삭제할 수 있습니다:

경고: 모든 것이 예상대로 작동하는지 두 번 확인할 때까지 Gitaly PVC를 삭제하지 마세요.
```
kubectl delete pvc repo-data-<release>-gitaly-0
```

백업/복원 방법으로 마이그레이션하기

이 방법은:

Gitaly 차트 PersistentVolumeClaim(PVC)에서 저장소를 백업한 후 외부 Gitaly 서비스로 복원합니다.
모든 사용자에게 다운타임을 초래합니다.
Praefect chart와 테스트되지 않았으며 지원되지 않습니다.

1단계: GitLab 차트의 현재 릴리스 개정판 가져오기

마이그레이션 중에 문제가 발생할 경우를 대비하여 GitLab 차트의 현재 릴리스 개정판을 가져옵니다. 출력을 복사하여 롤백(rollback)이 필요할 경우를 대비해 따로 보관합니다:

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. 러너 포드 축소

GitLab Community Edition을 사용하는 경우 클러스터에서 실행 중인 GitLab Runner 포드를 축소해야 합니다. 이렇게 하면 러너가 GitLab에 연결하여 CI/CD 작업을 처리할 수 없게 됩니다.

GitLab Enterprise Edition을 사용하는 경우 이 단계는 선택적이며, 유지 관리 모드가 클러스터의 러너가 GitLab에 연결하는 것을 방지합니다.

# 나중에 이 숫자로 스케일 업할 수 있도록 러너의 현재 복제본 수를 기록합니다
kubectl get deploy -lapp=gitlab-gitlab-runner,release=<release> -o jsonpath='{.items[].spec.replicas}{"\n"}'

# 러너 포드를 0으로 축소
kubectl scale deploy -lapp=gitlab-gitlab-runner,release=<release> --replicas=0

3. 실행 중인 CI 작업이 없는지 확인

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

4. Sidekiq 크론 작업 비활성화

마이그레이션 중에 Sidekiq 작업이 예약되고 실행되지 않도록 모든 Sidekiq 크론 작업을 비활성화합니다:

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

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

다음 단계로 진행하기 전에 대기 중이거나 진행 중인 작업이 완료될 때까지 기다려야 합니다.

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

6. Sidekiq 및 웹 서비스 포드 축소

일관된 백업이 수행되도록 Sidekiq 및 웹 서비스 포드를 축소합니다. 두 서비스는 나중에 다시 축소됩니다:

복원 단계에서 Sidekiq 포드가 다시 축소됩니다.
외부 Gitaly 서비스로 전환한 후 웹 서비스 포드가 다시 축소됩니다.

# 나중에 이 숫자로 스케일 업할 수 있도록 Sidekiq 및 웹 서비스의 현재 복제본 수를 기록합니다
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 및 웹 서비스 포드를 0으로 축소
kubectl scale deploy -lapp=sidekiq,release=<release> --replicas=0
kubectl scale deploy -lapp=webservice,release=<release> --replicas=0

7. 클러스터에 대한 외부 연결 제한

사용자 및 외부 GitLab 러너가 GitLab에 변경을 수행하지 못하도록 하기 위해 GitLab에 대한 불필요한 모든 연결을 제한해야 합니다.

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

마이그레이션 중에 클러스터가 새 외부 Gitaly 서비스에 접근 가능하도록 하려면 외부 Gitaly 서비스의 IP 주소를 nginx-ingress 구성에 유일한 외부 예외로 추가해야 합니다.

다음 내용을 가진 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를 구성하는 경우, 외부 Gitaly에 TLS로 연결 섹션을 참조하세요:

Gitaly

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

Gitaly 클러스터

global:
  gitaly:
    enabled: false
    external:
      - name: default                   # 필수
        hostname: ha.git.example.com    # 필수
        port: 2305                      # Praefect는 포트 2305 사용
        tlsEnabled: false               # 선택 사항, 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

웹서비스 파드를 원래 복제 수로 늘립니다(실행되지 않는 경우). 이는 다음 단계에서 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
```
특정 행의 diff 출력에서 빈 체크섬이 0000000000000000000000000000000000000000으로 변경되는 것을 관찰한다면, 이는 예상된 결과이며 안전하게 무시할 수 있습니다.

7단계: 최종 구성 및 검증

외부 사용자와 GitLab 러너가 다시 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 크론 잡 활성화하기:

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

러너 포드가 실행되고 있지 않다면 원래 복제 수로 늘리기:

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 서브차트를 다시 사용할 수 있도록 변경 사항을 롤백할 수 있습니다.

롤백이 성공적으로 이루어지려면 원본 Gitaly PVC가 존재해야 합니다.

1단계: GitLab 차트의 현재 릴리스 수정 번호 가져오기에서 얻은 수정 번호를 사용하여 GitLab 차트를 이전 릴리스로 롤백합니다:
```
helm rollback <release> <revision>
```
Webservice 포드가 실행되고 있지 않다면 원래 복제 수로 확장합니다:
```
kubectl scale deploy -lapp=webservice,release=<release> --replicas=<value>
```
Sidekiq 포드가 실행되고 있지 않다면 원래 복제 수로 확장합니다:
```
kubectl scale deploy -lapp=sidekiq,release=<release> --replicas=<value>
```

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

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

Runner 포드가 실행되고 있지 않다면 원래 복제 수로 확장합니다:

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

GitLab Enterprise Edition을 사용하는 경우 활성화되어 있다면 유지 관리 모드를 비활성화합니다.

외부 Gitaly로 GitLab 차트 구성하기

차트 구성하기

다중 외부 Gitaly

TLS를 통한 외부 Gitaly 연결

GitLab이 Gitaly에 연결되는지 테스트

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

저장소 이동 API로 마이그레이션

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

Step 2: 인스턴스를 새 Gitaly 서비스 사용하도록 구성

3단계: Gitaly pod IP 및 호스트 이름 가져오기

4단계: 저장소 이동 예약

5단계: 최종 구성 및 검증

백업/복원 방법으로 마이그레이션하기

1단계: GitLab 차트의 현재 릴리스 개정판 가져오기

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

3단계: 마이그레이션 동안 Git 변경이 불가능한지 확인

4단계: 모든 리포지토리 백업

5단계: 인스턴스를 새 Gitaly 서비스로 구성

6단계: 백업 저장소 복원 및 검증

7단계: 최종 구성 및 검증

롤백

관련 문서

도움말

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

도움받기