GitLab 차트 업그레이드

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

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

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

참고: 제로 다운타임 업그레이드 함수는 GitLab 차트에서 제공되지 않습니다. 해당 기능의 지원을 위한 진행 중인 작업은 GitLab 오퍼레이터 에픽을 통해 추적할 수 있습니다.

또한 먼저 백업을 추천합니다. 또한 현재 값 중 일부 값이 더 이상 사용되지 않을 수 있기 때문에 --reuse-values 대신 helm upgrade --set key=value 구문이나 -f values.yaml을 사용하여 모든 값을 제공해야 합니다.

이전의 --set 인수를 청소하려면 helm get values <릴리스 이름>을 사용하여 이를 파일로 안전하게 전달할 수 있습니다(helm get values <릴리스 이름> > gitlab.yaml). 따라서 helm upgrade gitlab gitlab/gitlab -f gitlab.yaml로 이 파일을 안전하게 전달합니다. 이로써 --reuse-values의 동작이 안전하게 대체됩니다.

단계

참고: 차트의 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 <새 버전> \
      -f gitlab.yaml \
      --set gitlab.migrations.enabled=true \
      --set ...
    

주요 데이터베이스 업그레이드 중에는 gitlab.migrations.enabledfalse로 설정하도록 요청합니다. 향후 업데이트를 위해 명시적으로 이 값을 true로 설정하는 지 확인하세요.

번들로 제공된 PostgreSQL 차트 업그레이드

참고: 번들로 제공된 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 버전으로 업그레이드

경고: 차트의 6.x 버전에서 최신 7.0 릴리스로 업그레이드하는 경우, 업그레이드를 위해 먼저 최신 6.11.x 패치 릴리스로 업데이트해야 합니다. 7.0 릴리스 노트에서 지원되는 업그레이드 경로가 설명되어 있습니다.

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

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

번들로 제공된 Redis Sub-Chart 업데이트

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 배포의 레플리카를 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이 변경사항을 병합하는 방식 때문에, 단계 하나를 수동으로 확장해야 할 수도 있습니다.

global.redis.password의 사용

global.redis.password의 사용과 관련된 구성 유형 충돌을 완화하기 위해 우리는 global.redis.password의 사용을 global.redis.auth로 대체하기로 하였습니다.

또한 사용자가 helm upgrade로 다음 경고 메시지를 보게 되면 추가로 알려드립니다: plaintext 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로 변경하더라도 자동으로 제거되지 않습니다. 기존 Ingress에 대한 예전 동작을 계속 사용하도록 하기 위해서는 수동 작업이 필요합니다.

버전 6.0으로 업그레이드

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

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

이전 업그레이드 지침

5.x 이전 버전의 GitLab 차트에서 업그레이드하는 경우, 더 오래된 버전의 설명서에 액세스하려면 GitLab Docs archives를 참조하십시오.