GitLab 차트 업그레이드

Tier: Free, Premium, Ultimate Offering: Self-managed

GitLab 설치를 업그레이드하기 전에, 업그레이드하려는 특정 릴리스에 해당하는
changelog를 확인하고,
새 GitLab 차트 버전에 관련된 릴리스 노트를 찾아야 합니다.

업그레이드는 지원되는 업그레이드 경로를 따라야 합니다.
GitLab 차트 버전은 GitLab 버전과 동일한 번호 체계를 따르지 않으므로,
그들 간의 버전 매핑을 참조하세요.

note
Zero-downtime upgrades는 GitLab 차트에서 제공되지 않습니다.
이 기능을 지원하는 작업은 GitLab Operator epic를 통해 추적할 수 있습니다.

먼저 백업을 수행할 것을 권장합니다.
또한 모든 값을 helm upgrade --set key=value 구문 또는 -f values.yaml을 사용하여 제공해야 하며,
--reuse-values를 사용해서는 안 됩니다. 현재 값 중 일부는 더 이상 사용되지 않을 수 있기 때문입니다.

이전 --set 인수를 깨끗하게 검색할 수 있습니다.
helm get values <release name>을 사용하세요.
이 파일을 (helm get values <release name> > gitlab.yaml)로 리디렉션하면, 안전하게 이 파일을 -f로 전달할 수 있습니다.
따라서 helm upgrade gitlab gitlab/gitlab -f gitlab.yaml을 사용합니다.
이는 --reuse-values의 동작을 안전하게 대체합니다.

단계

note
7.0 버전의 차트로 업그레이드하는 경우, 7.0에 대한 수동 업그레이드 단계를 따르세요.
6.0 버전의 차트로 업그레이드하는 경우, 6.0에 대한 수동 업그레이드 단계를 따르세요.
구버전의 차트로 업그레이드하는 경우, 구버전 업그레이드 단계를 따르세요.

업그레이드하기 전에 설정한 값을 반영하고 설정을 “과도하게 구성”했는지 고려하세요.
사용자 설정을 최소한으로 유지하고 대부분의 차트 기본값을 활용하는 것을 기대합니다.
다음 항목을 명시적으로 설정했으면:

  • 계산된 설정 복사
  • 모든 설정 복사 및 기본값과 실제로 동일한 값을 명시적으로 정의

이는 업그레이드 중에 거의 확실히 문제를 일으킬 것입니다.
버전간 구성 구조가 변경되었을 수 있으며, 설정을 적용하는 데 문제가 발생할 수 있습니다.
다음 단계에서 이를 어떻게 확인하는지 설명합니다.

다음은 GitLab을 최신 버전으로 업그레이드하는 단계입니다:

  1. 업그레이드하려는 특정 버전의 변경 로그를 확인합니다.
  2. 배포 문서를 단계별로 확인하세요.
  3. 이전에 제공한 값을 추출합니다:

    helm get values gitlab > gitlab.yaml  
    
  4. 업그레이드할 때 전달할 모든 값을 결정합니다.
    GitLab은 합리적인 기본값을 제공하며, 업그레이드 중에는 위의 명령으로부터 모든 값을 전달하려고 시도할 수 있습니다.
    하지만 차트 버전 간에 구성이 변경되었을 수 있으며, 매끄럽게 매핑되지 않을 수 있습니다.
    명시적으로 설정하고 싶은 최소한의 값 목록을 유지하는 것이 좋으며,
    업그레이드 과정에서 이러한 값을 전달하는 것이 좋습니다.

  5. 이전 단계에서 추출한 값으로 업그레이드를 수행합니다:

    helm upgrade gitlab gitlab/gitlab \  
      --version <new version> \  
      -f gitlab.yaml \  
      --set gitlab.migrations.enabled=true \  
      --set ...  
    

주요 데이터베이스 업그레이드 중에는 gitlab.migrations.enabledfalse로 설정하는 것이 좋습니다.
향후 업데이트를 위해 명시적으로 다시 true로 설정해야 합니다.

번들 PostgreSQL 차트 업그레이드

note
번들 PostgreSQL 차트(postgresql.install이 false인 경우)를 사용하고 있지 않다면, 이 단계를 수행할 필요가 없습니다.

번들 PostgreSQL을 버전 13으로 업그레이드

PostgreSQL 13은 GitLab 14.1 및 이후 버전에서 지원됩니다. PostgreSQL 13은 상당한 성능 향상을 제공합니다.

번들 PostgreSQL을 버전 13으로 업그레이드하려면 다음 단계가 필요합니다:

  1. 기존 데이터베이스 준비하기.
  2. 기존 PostgreSQL 데이터 삭제하기.
  3. postgresql.image.tag 값을 13.6.0으로 업데이트하고 차트를 재설치하기 위해 새로운 PostgreSQL 13 데이터베이스를 생성합니다.
  4. 데이터베이스 복원하기.

버전 7.0으로 업그레이드

caution
차트를 6.x 버전에서 최신 7.0 릴리즈로 업그레이드하는 경우, 이 업그레이드가 작동하려면 먼저 최신 6.11.x 패치 릴리즈로 업데이트해야 합니다.
7.0 릴리즈 노트에서 지원되는 업그레이드 경로를 설명합니다.

7.0.x 릴리즈는 업그레이드를 수행하기 위한 수동 단계가 필요할 수 있습니다.

  • 번들 bitnami/Redis 서브 차트를 사용하여 클러스터 내 Redis 서비스를 제공하는 경우, GitLab 차트의 버전 7.0으로 업그레이드하기 전에 Redis의 StatefulSet을 수동으로 삭제해야 합니다. 아래의 번들 Redis 서브 차트 업그레이드 설정을 따르세요.

번들 Redis 서브 차트 업데이트

GitLab 차트의 7.0 릴리즈는 이전 설치된 11.3.4에서 bitnami/Redis 서브 차트를 16.13.2로 업데이트합니다. redis-master StatefulSet에 적용된 matchLabels 변경으로 인해, StatefulSet을 수동으로 삭제하지 않고 업그레이드를 진행하면 다음과 같은 오류가 발생합니다:

Error: UPGRADE FAILED: cannot patch "gitlab-redis-master" with kind StatefulSet: StatefulSet.apps "gitlab-redis-master" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy' and 'minReadySeconds' are forbidden

RELEASE-redis-master의 StatefulSet을 삭제하려면:

  1. webservice, sidekiq, kas, 및 gitlab-exporter 배포에 대해 복제를 0으로 줄이세요:

    kubectl scale deployment --replicas 0 --selector 'app in (webservice, sidekiq, kas, gitlab-exporter)' --namespace <namespace>
    
  2. RELEASE-redis-master StatefulSet을 삭제하세요:

    kubectl delete statefulset RELEASE-redis-master --namespace <namespace>
    
    • <namespace>는 GitLab 차트를 설치한 네임스페이스로 교체해야 합니다.

그런 다음 표준 업그레이드 단계를 따르세요. Helm이 변경 사항을 병합하는 방식 때문에, 1단계에서 축소한 배포를 수동으로 다시 확장해야 할 수 있습니다.

global.redis.password의 사용

global.redis.password의 사용과 관련된 구성 유형 충돌을 완화하기 위해

global.redis.auth를 선호하여 global.redis.password의 사용을 더 이상 지원하지 않도록 하였습니다.

더불어 사용 중단 알림을 표시하는 것 외에도, helm upgrade에서 다음과 같은 경고 메시지를 볼 경우:

coalesce.go:199: warning: destination for password is a table. Ignoring non-table value

이는 값을 파일에 global.redis.password를 설정하고 있음을 나타냅니다.

Ingress의 useNewIngressForCerts

7.x에서 이후 버전으로 기존 차트를 업그레이드하고 있으며, global.ingress.useNewIngressForCertstrue로 변경하는 경우 기존

cert-manager Certificate 객체의 acme.cert-manager.io/http01-override-ingress-name 주석을 삭제하도록 업데이트해야 합니다.

이 속성이 false(기본값)으로 설정된 경우 이 주석은 기본적으로 Certificates에 추가되며, cert-manager는 이 주석을 사용하여 해당 인증서에 사용할 Ingress 방법을 식별합니다. 이 속성을 false로 변경하는 것만으로는 주석이 자동으로 제거되지 않습니다.

수동 작업이 필요하며, 그렇지 않으면 cert-manager는 기존 Ingress에 대해 이전 동작을 계속 사용합니다.

6.0 버전으로 업그레이드

경고:

차트의 5.x 버전에서 최신 6.0 릴리스로 업그레이드하는 경우, 업그레이드가 작동하도록 하려면 먼저 최신 5.10.x 패치 릴리스를 업데이트해야 합니다.

6.0 릴리스 노트에서는 지원되는 업그레이드 경로를 설명합니다.

6.0 릴리스로 업그레이드하려면 먼저 최신 5.10.x 패치 릴리스에 있어야 합니다. 6.0에서 추가적인 수동 변경이 필요하지 않으므로 정기 릴리스 업그레이드 절차를 따를 수 있습니다.

이전 업그레이드 지침

GitLab 차트의 5.x보다 이전 버전에서 업그레이드하는 경우, GitLab Docs 아카이브를 참조하여 이전 버전의 문서에 접근하세요.