외부 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                    # 옵션, 기본값 표시

위의 구성 파일을 사용하여 예제 설치:

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
```
또는 --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

Gitaly를 TLS로 사용하는 경우, GitLab 차트가 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 pod과 동일한 VPC/존에 있어야 합니다.
Praefect 차트와는 호환되지 않으므로 테스트되지 않고 지원되지 않습니다.

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

외부 Gitaly 서비스 또는 외부 Gitaly 클러스터를 설정합니다. 차트 설치에 사용한 Gitaly 토큰 및 GitLab Shell 시크릿을 해당 단계의 일부로 제공해야 합니다:

# GitLab Shell 시크릿 가져오기
kubectl get secret <릴리스>-gitlab-shell-secret -ojsonpath='{.data.secret}' | base64 -d

# Gitaly 토큰 가져오기
kubectl get secret <릴리스>-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 pod 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 pod에서 GitLab이 외부 Gitaly에 성공적으로 연결되는지 확인합니다:
```
kubectl exec <toolbox pod 이름> -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
```

단계 3: Gitaly 파드 IP 및 호스트네임 가져오기

리포지터리 저장 이동 API가 성공하려면 외부 Gitaly 서비스가 파드 서비스 호스트네임을 사용하여 Gitaly 파드에 다시 연결해야 합니다. 파드 서비스 호스트명이 해결될 수 있도록 외부 Gitaly 서비스에서 실행 중인 Gitaly 프로세스에 host 파일에 호스트명을 추가해야 합니다.

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할 수 있는지 확인합니다:
```
ping <gitaly 파드 호스트명>
```

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

단계 4: 리포지터리 저장 이동 예약

리포지터리 이동에서 지시된 단계를 따라 이동을 예약합니다.

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

여러 Gitaly 리포지터리가 있는 경우, 새 리포지터리가 저장될 위치를 구성합니다.
외부 Gitaly 구성이 포함된 향후 통합 gitlab.yml을 생성하는 것을 고려합니다:
```
 helm get values <릴리스_이름> -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 파드 IP 및 호스트네임 가져오기 단계를 수행한 후, 각 외부 Gitaly /etc/hosts 파일에 적용한 변경사항을 제거합니다.
모든 것이 예상대로 작동하는지 확인한 후 Gitaly PVC를 삭제합니다:
경고: 모든 것이 예상대로 작동하는지 반드시 재확인한 후 Gitaly PVC를 삭제하지 마십시오.
```
kubectl delete pvc repo-data-<릴리스>-gitaly-0
```

백업/복원 방법으로 이전

이 방법:

Gitaly 차트 PersistentVolumeClaim (PVC)에서 리포지터리를 백업한 다음 외부 Gitaly 서비스로 복원합니다.
모든 사용자에게 다운타임이 발생합니다.
Praefect 차트와는 테스트되지 않았으며 지원되지 않습니다.

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

이주의 일이 문제가 발생하는 경우, GitLab 차트의 현재 릴리스 리비전을 가져옵니다. 출력을 복사하고 필요한 경우 rollback을 수행해야 합니다.

helm history <release> --max=1

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

외부 Gitaly나 외부 Gitaly 클러스터를 설정합니다. 이러한 단계의 일환으로 Chart 설치에서 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에 사용되어야 합니다.

단계 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 파드 축소

GitLab Community Edition을 사용하고 있다면, 클러스터에서 실행 중인 GitLab Runner 파드를 축소해야 합니다. 이렇게 하면 Runner가 GitLab에 연결되지 않아 CI/CD 작업을 처리하지 않습니다.

GitLab Enterprise Edition을 사용하고 있다면, 유지보수 모드로 인해 클러스터 내의 Runner가 GitLab에 연결되는 것을 방지하므로 이 단계는 선택 사항입니다.

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

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

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

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

4. Sidekiq cron 작업 비활성화

마이그레이션 중에 Sidekiq 작업이 예약되고 실행되는 것을 방지하려면 모든 Sidekiq cron 작업을 비활성화합니다.

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

5. 배경 작업이 실행 중이 아닌지 확인

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

관리자 영역으로 이동하여 모니터링을 선택합니다.
Sidekiq 대시보드에서 Queues를 선택한 다음 Live Poll을 선택합니다.
Busy 및 Enqueued가 0으로 줄어 드는 것을 기다립니다.

6. Sidekiq 및 Webservice 파드 축소

일관된 백업이 수행되도록 Sidekiq 및 Webservice 파드를 축소합니다. 두 서비스 모두 나중에 다시 확장됩니다.

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

# 현재 복제본 수를 메모하여 나중에 이 수로 확장할 수 있도록 합니다
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 파드를 0으로 축소합니다
kubectl scale deploy -lapp=sidekiq,release=<release> --replicas=0
kubectl scale deploy -lapp=webservice,release=<release> --replicas=0

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

사용자 및 외부 GitLab Runner가 GitLab에 변경 사항을 가하도록 방지하려면 GitLab에 모든 불필요한 연결을 제한해야 합니다.

이러한 단계가 완료되면 복원이 완료될 때까지 브라우저에서 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                   # 필수
        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

실행 중이 아닌 경우 Webservice 파드를 원래 복제본 수로 확장해야 합니다. 이렇게 하지 않으면 다음 단계에서 GitLab에서 외부 Gitaly 연결을 테스트할 수 없습니다.
```
kubectl scale deploy -lapp=webservice,release=<release> --replicas=<value>
```
Toolbox 파드에서 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 Runner가 다시 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 엔터프라이즈 에디션을 사용하는 경우, 유지 보수 모드를 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 pod를 확장합니다:

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 차트를 이전 릴리스로 롤백합니다:
```
helm rollback <release> <revision>
```

Webservice pod를 원래 복제본 수에 맞게 확장합니다.

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

Sidekiq pod를 원래 복제본 수에 맞게 확장합니다.

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 pod를 확장합니다:

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

GitLab 엔터프라이즈 에디션을 사용하는 경우, 유지 보수 모드가 활성화된 경우 비활성화합니다.

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

차트 구성

다중 외부 Gitaly

TLS를 통한 외부 Gitaly 연결

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

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

리포지터리 스토리지 이동 API를 사용한 마이그레이션

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

단계 2: 새로운 Gitaly 서비스 사용으로 인스턴스 구성

단계 3: Gitaly 파드 IP 및 호스트네임 가져오기

단계 4: 리포지터리 저장 이동 예약

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

백업/복원 방법으로 이전

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

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

단계 3: 마이그레이션 중에 Git 변경 사항을 할 수 없는지 확인

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

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

단계 6: 리포지터리 백업 복원 및 유효성 검사

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

롤백

관련 문서

도움말

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

도움받기