GitLab 차트 업그레이드

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

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

업그레이드는 지원되는 업그레이드 경로를 따라야 합니다. GitLab 차트 버전은 GitLab 버전과 동일한 번호 체계를 따르지 않기 때문에, 두 버전 간의 버전 매핑을 참조하십시오.

note
제로 다운타임 업그레이드는 GitLab 차트에서 제공되지 않습니다. 이 기능을 지원하기 위한 진행 중인 작업은 GitLab Operator epic에서 추적할 수 있습니다.

우리는 또한 먼저 백업을 하는 것을 권장합니다. 또한, 현재 값들 중 일부가 더 이상 사용되지 않을 수 있기 때문에 --reuse-values 대신 helm upgrade --set key=value 구문이나 -f values.yaml을 사용하여 모든 값을 제공해야 함에 유의하십시오.

이전 --set 인수를 정확하게 검색할 수 있습니다.

단계

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 릴리스는 업그레이드를 수행하기 위해 매뉴얼 단계가 필요할 수 있습니다.

  • 클러스터 내 Redis 서비스를 제공하기 위해 번들 포함된 bitnami/Redis 하위 차트를 사용하는 경우 - 7.0 버전의 GitLab 차트로 업그레이드하기 전에 Redis의 StatefulSet을 매뉴얼으로 삭제해야 합니다. 아래의 번들 포함된 Redis 서브 차트 업그레이드 단계를 따르세요.

번들 포함된 Redis 서브 차트 업그레이드

GitLab 차트의 7.0 릴리스는 이전에 설치된 11.3.4 버전에서 16.13.2 버전으로 번들 포함된 bitnami/Redis 서브 차트를 업데이트합니다. 서브 차트 내의 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 deployments의 복제본을 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이 변경 사항을 Merge하는 방식 때문에, 첫 번째 단계에서 축소한 배포를 매뉴얼으로 확장해야 할 수 있습니다.

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를 설정하고 있는 경우입니다.

Ingresses의 useNewIngressForCerts

기존 차트를 7.x에서 이후 버전으로 업그레이드하고 global.ingress.useNewIngressForCertstrue로 변경하는 경우, 기존 cert-manager Certificate 객체도 업데이트하여 acme.cert-manager.io/http01-override-ingress-name 주석을 삭제해야 합니다.

이 변경을 해야 하는 이유는 이 속성이 false(기본값)로 설정되어 있을 때 해당 주석이 인증서에 자동으로 추가되며, cert-manager가 인증서에 대해 사용할 Ingress 방법을 식별하는 데 사용하기 때문입니다. 이 주석은 이 속성을 단순히 false로 변경하는 것으로는 자동으로 제거되지 않습니다. 그렇지 않으면 cert-manager는 기존 Ingress에 대해 이전 동작을 계속 사용합니다. 매뉴얼 조치가 필요합니다.

6.0 버전으로 업그레이드

caution
차트의 5.x 버전에서 최신 6.0 릴리스로 업그레이드하는 경우, 업그레이드가 제대로 작동하려면 먼저 최신 5.10.x 패치 릴리스로 업데이트해야 합니다. 6.0 릴리스 노트에서 지원되는 업그레이드 경로에 대해 설명합니다.

6.0 릴리스로 업그레이드하려면 먼저 최신 5.10.x 패치 릴리스로 이동해야 합니다. 6.0에서 추가 매뉴얼 변경 사항은 없으므로 일반 릴리스 업그레이드 단계를 따를 수 있습니다.