InfoGrab DocsInfoGrab Docs

다운타임과 함께 멀티 노드 인스턴스 업그레이드

요약

다운타임과 함께 멀티 노드 GitLab 인스턴스를 업그레이드하려면 다음을 수행합니다. 다운타임과 함께하는 업그레이드를 시작하기 전에 다운타임 옵션을 검토합니다. 업그레이드하기 전에 GitLab 애플리케이션을 종료해 데이터베이스에 대한 쓰기를 중지해야 합니다.

다운타임과 함께 멀티 노드 GitLab 인스턴스를 업그레이드하려면 다음을 수행합니다.

  1. GitLab 애플리케이션을 종료합니다.
  2. Consul 서버를 업그레이드합니다.
  3. Gitaly, Rails, PostgreSQL, Redis, PgBouncer를 순서에 상관없이 업그레이드합니다. 클라우드 플랫폼의 PostgreSQL 또는 Redis를 사용하고 업그레이드가 필요하다면, 이 안내 대신 클라우드 제공업체의 안내를 따릅니다.
  4. GitLab 애플리케이션(Sidekiq, Puma)을 업그레이드하고 애플리케이션을 시작합니다.

다운타임과 함께하는 업그레이드를 시작하기 전에 다운타임 옵션을 검토합니다.

GitLab 애플리케이션 종료#

업그레이드하기 전에 GitLab 애플리케이션을 종료해 데이터베이스에 대한 쓰기를 중지해야 합니다. 이 과정은 설치 방법에 따라 다릅니다.

이 프로세스를 실행 중인 모든 서버에서 Puma와 Sidekiq을 종료합니다.

sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl stop puma

Helm chart 인스턴스의 경우:

  1. 이후 재시작을 위해 데이터베이스 클라이언트의 현재 복제본 수를 기록해 둡니다.
kubectl get deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.replicas}{"\n"}{end}'
  1. 데이터베이스 클라이언트를 중지합니다.
kubectl scale deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' --replicas=0

Consul 노드 업그레이드#

Consul 노드 업그레이드 안내를 따릅니다. 요약하면 다음과 같습니다.

  1. Consul 노드가 모두 정상 상태인지 확인합니다.

  2. Linux 패키지로 업그레이드하는 방법으로 모든 Consul 서버를 업그레이드합니다.

  3. 한 번에 한 노드씩 모든 GitLab 서비스를 재시작합니다.

    sudo gitlab-ctl restart

Consul 클러스터 프로세스는 자체 서버에 있지 않고 Redis HA 나 Patroni 같은 다른 서비스와 공유될 수 있습니다. 이 경우 해당 서버를 업그레이드할 때는 다음을 따릅니다.

  • 한 번에 한 서버에서만 서비스를 재시작합니다.
  • 서비스를 업그레이드하거나 재시작하기 전에 Consul 클러스터가 정상 상태인지 확인합니다.

Gitaly 및 Gitaly Cluster(Praefect) 업그레이드#

Gitaly Cluster(Praefect)에 속하지 않은 Gitaly 서버는 Linux 패키지로 업그레이드하는 방법으로 서버를 업그레이드합니다. Gitaly 샤드가 여러 개라면 Gitaly 서버를 순서에 상관없이 업그레이드할 수 있습니다.

Gitaly Cluster(Praefect)를 실행 중이라면 다음 순서로 구성 요소를 업그레이드해야 합니다.

  1. Praefect PostgreSQL 데이터베이스. 다음을 사용하는 경우:
    • Linux 패키지: 이 단계에서는 Git 작업에 다운타임이 필요합니다.
    • 서드파티 HA 데이터베이스 솔루션: 이 단계는 다운타임 없이 수행할 수 있습니다.
  2. Gitaly 노드. Linux 패키지로 업그레이드하는 방법으로 순차적으로 업그레이드합니다.
  3. Praefect 노드. Praefect 업그레이드 단계를 따르며, 데이터베이스 마이그레이션을 실행할 배포 노드로 하나를 지정합니다.

Amazon 머신 이미지를 사용하는 경우#

AWS에서 Amazon 머신 이미지(AMI)를 사용하고 있다면 AMI 재배포 프로세스로 Gitaly 노드를 업그레이드할 수 있습니다. 이 프로세스를 사용하려면 Elastic network interfaces(ENI)를 사용해야 합니다. Gitaly Cluster(Praefect)는 서버 호스트 이름으로 Git 리포지터리의 복제본을 추적합니다. ENI를 사용하면 인스턴스가 재배포되어도 프라이빗 DNS 이름을 동일하게 유지할 수 있습니다. 노드가 새로운 호스트 이름으로 재배포되면 스토리지가 동일하더라도 Gitaly Cluster(Praefect)가 동작할 수 없습니다.

ENI를 사용하지 않는다면 Linux 패키지를 사용해 Gitaly 노드를 업그레이드해야 합니다.

AMI 재배포 프로세스로 Gitaly Cluster(Praefect) 노드를 업그레이드하려면 다음을 수행합니다.

  1. AMI 재배포 프로세스에는 gitlab-ctl reconfigure가 포함되어야 합니다. 모든 노드에 이 설정이 적용되도록 AMI에 praefect['auto_migrate'] = false를 설정합니다. 이 설정은 reconfigure가 데이터베이스 마이그레이션을 자동으로 실행하지 못하도록 막습니다.
  2. 업그레이드된 이미지로 처음 재배포되는 노드가 배포 노드여야 합니다.
  3. 배포가 끝나면 gitlab.rb에서 praefect['auto_migrate'] = true를 설정하고 gitlab-ctl reconfigure로 적용합니다.
  4. 이 명령이 데이터베이스 마이그레이션을 실행합니다.
  5. 나머지 Gitaly Cluster(Praefect) 노드를 재배포합니다.

PostgreSQL 노드 업그레이드#

Patroni(HA PostgreSQL) 구성을 사용 중이라면 이 섹션을 건너뛰고 Patroni 노드 업그레이드 단계를 따릅니다.

클러스터로 구성되지 않은 PostgreSQL 서버의 경우:

  1. Linux 패키지로 업그레이드하는 방법으로 서버를 업그레이드합니다.

  2. 업그레이드 프로세스는 바이너리가 업그레이드될 때 PostgreSQL을 재시작하지 않으므로, 새 버전을 로드하려면 재시작합니다.

    sudo gitlab-ctl restart

Patroni 노드 업그레이드#

Patroni는 PostgreSQL의 고가용성을 확보하는 데 사용됩니다.

PostgreSQL 메이저 버전 업그레이드가 필요하다면 메이저 버전 프로세스를 따릅니다.

그 밖의 모든 버전에 대한 업그레이드 프로세스는 먼저 모든 레플리카에서 수행됩니다. 레플리카가 업그레이드된 후 리더에서 업그레이드된 레플리카 중 하나로 클러스터 페일오버가 발생합니다. 이 과정은 페일오버가 한 번만 필요하도록 보장하며, 완료되면 새 리더가 업그레이드됩니다.

Patroni 노드를 업그레이드하려면 다음을 수행합니다.

  1. 리더 노드와 레플리카 노드를 확인하고 클러스터가 정상 상태인지 확인합니다. 데이터베이스 노드에서 다음을 실행합니다.

    sudo gitlab-ctl patroni members

  2. Linux 패키지로 업그레이드하는 방법으로 레플리카 노드 중 하나를 업그레이드합니다.

  3. 새 버전을 로드하려면 재시작합니다.

    sudo gitlab-ctl restart

  4. 클러스터가 정상 상태인지 확인합니다.

  5. 나머지 레플리카에 대해 업그레이드, 재시작, 상태 확인 단계를 반복합니다.

  6. 레플리카와 동일한 Linux 패키지 업그레이드 방식으로 리더 노드를 업그레이드합니다.

  7. 새 버전을 로드하고 클러스터 페일오버도 함께 발생시키기 위해 리더 노드의 모든 서비스를 재시작합니다.

    sudo gitlab-ctl restart

  8. 클러스터가 정상 상태인지 확인합니다.

PgBouncer 노드 업그레이드#

GitLab 애플리케이션(Rails) 노드에서 PgBouncer를 실행 중이라면 PgBouncer는 애플리케이션 서버 업그레이드의 일부로 업그레이드됩니다. 그렇지 않다면 Linux 패키지로 업그레이드하는 방법으로 PgBouncer 노드를 업그레이드합니다.

Redis 노드 업그레이드#

독립형 Redis 서버를 업그레이드하려면 Linux 패키지로 업그레이드합니다.

Redis HA(Sentinel 사용) 업그레이드#

Redis HA를 사용 중이라면 Redis HA 클러스터를 업그레이드하기 위해 제로 다운타임 안내를 따릅니다.

GitLab 애플리케이션(Rails) 노드 업그레이드#

레퍼런스 아키텍처에서 이 노드는 Rails 노드 라고 부릅니다. 이 노드는 첫 단계에서 종료했던 Puma 프로세스를 실행합니다. 이 노드를 업그레이드하는 과정은 설치 방법에 따라 다릅니다.

모든 Puma와 Sidekiq 프로세스는 이전 단계에서 이미 종료되었습니다. 각 GitLab 애플리케이션(Rails) 노드에서:

  1. /etc/gitlab/skip-auto-reconfigure가 존재하지 않는지 확인합니다.

  2. Puma와 Sidekiq 이 실행 중이지 않은지 확인합니다.

    ps -ef | egrep 'puma: | puma | sidekiq '

Rails 노드 중 하나를 모든 데이터베이스 마이그레이션 실행을 담당하는 배포 노드 로 선택합니다. 배포 노드에서:

  1. 서버가 일반 마이그레이션을 허용하도록 구성되어 있는지 확인합니다. /etc/gitlab/gitlab.rb에 gitlab_rails['auto_migrate'] = false가 포함되어 있지 않은지 확인합니다. gitlab_rails['auto_migrate'] = true 를 명시적으로 설정하거나, 기본 동작(true)을 사용하려면 생략합니다.

  2. PgBouncer를 사용 중이라면 마이그레이션을 실행하기 전에 PgBouncer를 거치지 않고 PostgreSQL에 직접 연결해야 합니다.

    Rails는 마이그레이션을 실행할 때 어드바이저리 락을 사용해 동일한 데이터베이스에서 동시 마이그레이션이 실행되지 않도록 방지합니다. 이 락은 트랜잭션 간에 공유되지 않으므로, 트랜잭션 풀링 모드의 PgBouncer로 데이터베이스 마이그레이션을 실행하면 ActiveRecord::ConcurrentMigrationError 오류와 그 밖의 문제가 발생합니다.

    1. Patroni를 실행 중이라면 리더 노드를 찾습니다. 데이터베이스 노드에서 다음을 실행합니다.

      sudo gitlab-ctl patroni members

    2. 배포 노드에서 gitlab.rb를 갱신합니다. gitlab_rails['db_host']와 gitlab_rails['db_port']를 다음 중 하나로 변경합니다.

      • 데이터베이스 서버의 호스트와 포트(클러스터로 구성되지 않은 PostgreSQL의 경우).
      • Patroni를 실행 중이라면 클러스터 리더의 호스트와 포트.

    3. 변경 사항을 적용합니다.

      sudo gitlab-ctl reconfigure

  3. Linux 패키지로 업그레이드하는 방법으로 GitLab을 업그레이드합니다.

  4. 다음을 실행해 데이터베이스 마이그레이션이 성공적으로 완료되었는지 확인합니다.

    sudo gitlab-rake db:migrate:status

    모든 마이그레이션이 끝날 때까지 나머지 Rails 노드를 업그레이드하지 않습니다.

  5. PgBouncer를 거치지 않도록 배포 노드에서 gitlab.rb를 변경했다면:

    1. 배포 노드에서 gitlab.rb를 갱신합니다. gitlab_rails['db_host']와 gitlab_rails['db_port']를 다시 PgBouncer 설정으로 되돌립니다.

    2. 변경 사항을 적용합니다.

      sudo gitlab-ctl reconfigure

  6. 모든 서비스가 업그레이드된 버전으로 실행되고 (해당하는 경우) PgBouncer를 통해 데이터베이스에 접근하도록 하기 위해 배포 노드의 모든 서비스를 재시작합니다.

    sudo gitlab-ctl restart

다음으로 나머지 모든 Puma와 Sidekiq 노드를 업그레이드합니다. 이 노드에서는 gitlab.rb의 gitlab_rails['auto_migrate']를 어떤 값으로 설정해도 됩니다.

이 노드들은 병렬로 업그레이드할 수 있습니다.

  1. Linux 패키지로 업그레이드하는 방법으로 GitLab을 업그레이드합니다.

  2. 모든 서비스가 재시작되었는지 확인합니다.

    sudo gitlab-ctl restart

모든 스테이트풀 구성 요소가 업그레이드된 후, GitLab chart 업그레이드 단계를 따라 스테이트리스 구성 요소(Webservice, Sidekiq, 그 밖의 지원 서비스)를 업그레이드합니다.

GitLab chart 업그레이드를 수행한 후 데이터베이스 클라이언트를 다시 시작합니다.

kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<value>
kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<value>
kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<value>

모니터 노드 업그레이드#

60 RPS 또는 3,000명 사용자 레퍼런스 아키텍처 구성의 일부로 Prometheus를 독립형 모니터링 노드로 구성했을 수 있습니다.

모니터 노드를 업그레이드하려면 Linux 패키지로 업그레이드합니다.

다운타임과 함께 멀티 노드 인스턴스 업그레이드

GitLab v19.5
Tier: Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기

요약

다운타임과 함께 멀티 노드 GitLab 인스턴스를 업그레이드하려면 다음을 수행합니다. 다운타임과 함께하는 업그레이드를 시작하기 전에 다운타임 옵션을 검토합니다. 업그레이드하기 전에 GitLab 애플리케이션을 종료해 데이터베이스에 대한 쓰기를 중지해야 합니다.

다운타임과 함께 멀티 노드 GitLab 인스턴스를 업그레이드하려면 다음을 수행합니다.

  1. GitLab 애플리케이션을 종료합니다.
  2. Consul 서버를 업그레이드합니다.
  3. Gitaly, Rails, PostgreSQL, Redis, PgBouncer를 순서에 상관없이 업그레이드합니다. 클라우드 플랫폼의 PostgreSQL 또는 Redis를 사용하고 업그레이드가 필요하다면, 이 안내 대신 클라우드 제공업체의 안내를 따릅니다.
  4. GitLab 애플리케이션(Sidekiq, Puma)을 업그레이드하고 애플리케이션을 시작합니다.

다운타임과 함께하는 업그레이드를 시작하기 전에 다운타임 옵션을 검토합니다.

GitLab 애플리케이션 종료#

업그레이드하기 전에 GitLab 애플리케이션을 종료해 데이터베이스에 대한 쓰기를 중지해야 합니다. 이 과정은 설치 방법에 따라 다릅니다.

이 프로세스를 실행 중인 모든 서버에서 Puma와 Sidekiq을 종료합니다.

sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl stop puma

Helm chart 인스턴스의 경우:

  1. 이후 재시작을 위해 데이터베이스 클라이언트의 현재 복제본 수를 기록해 둡니다.
kubectl get deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.replicas}{"\n"}{end}'
  1. 데이터베이스 클라이언트를 중지합니다.
kubectl scale deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' --replicas=0

Consul 노드 업그레이드#

Consul 노드 업그레이드 안내를 따릅니다. 요약하면 다음과 같습니다.

  1. Consul 노드가 모두 정상 상태인지 확인합니다.

  2. Linux 패키지로 업그레이드하는 방법으로 모든 Consul 서버를 업그레이드합니다.

  3. 한 번에 한 노드씩 모든 GitLab 서비스를 재시작합니다.

    sudo gitlab-ctl restart

Consul 클러스터 프로세스는 자체 서버에 있지 않고 Redis HA 나 Patroni 같은 다른 서비스와 공유될 수 있습니다. 이 경우 해당 서버를 업그레이드할 때는 다음을 따릅니다.

  • 한 번에 한 서버에서만 서비스를 재시작합니다.
  • 서비스를 업그레이드하거나 재시작하기 전에 Consul 클러스터가 정상 상태인지 확인합니다.

Gitaly 및 Gitaly Cluster(Praefect) 업그레이드#

Gitaly Cluster(Praefect)에 속하지 않은 Gitaly 서버는 Linux 패키지로 업그레이드하는 방법으로 서버를 업그레이드합니다. Gitaly 샤드가 여러 개라면 Gitaly 서버를 순서에 상관없이 업그레이드할 수 있습니다.

Gitaly Cluster(Praefect)를 실행 중이라면 다음 순서로 구성 요소를 업그레이드해야 합니다.

  1. Praefect PostgreSQL 데이터베이스. 다음을 사용하는 경우:
    • Linux 패키지: 이 단계에서는 Git 작업에 다운타임이 필요합니다.
    • 서드파티 HA 데이터베이스 솔루션: 이 단계는 다운타임 없이 수행할 수 있습니다.
  2. Gitaly 노드. Linux 패키지로 업그레이드하는 방법으로 순차적으로 업그레이드합니다.
  3. Praefect 노드. Praefect 업그레이드 단계를 따르며, 데이터베이스 마이그레이션을 실행할 배포 노드로 하나를 지정합니다.

Amazon 머신 이미지를 사용하는 경우#

AWS에서 Amazon 머신 이미지(AMI)를 사용하고 있다면 AMI 재배포 프로세스로 Gitaly 노드를 업그레이드할 수 있습니다. 이 프로세스를 사용하려면 Elastic network interfaces(ENI)를 사용해야 합니다. Gitaly Cluster(Praefect)는 서버 호스트 이름으로 Git 리포지터리의 복제본을 추적합니다. ENI를 사용하면 인스턴스가 재배포되어도 프라이빗 DNS 이름을 동일하게 유지할 수 있습니다. 노드가 새로운 호스트 이름으로 재배포되면 스토리지가 동일하더라도 Gitaly Cluster(Praefect)가 동작할 수 없습니다.

ENI를 사용하지 않는다면 Linux 패키지를 사용해 Gitaly 노드를 업그레이드해야 합니다.

AMI 재배포 프로세스로 Gitaly Cluster(Praefect) 노드를 업그레이드하려면 다음을 수행합니다.

  1. AMI 재배포 프로세스에는 gitlab-ctl reconfigure가 포함되어야 합니다. 모든 노드에 이 설정이 적용되도록 AMI에 praefect['auto_migrate'] = false를 설정합니다. 이 설정은 reconfigure가 데이터베이스 마이그레이션을 자동으로 실행하지 못하도록 막습니다.
  2. 업그레이드된 이미지로 처음 재배포되는 노드가 배포 노드여야 합니다.
  3. 배포가 끝나면 gitlab.rb에서 praefect['auto_migrate'] = true를 설정하고 gitlab-ctl reconfigure로 적용합니다.
  4. 이 명령이 데이터베이스 마이그레이션을 실행합니다.
  5. 나머지 Gitaly Cluster(Praefect) 노드를 재배포합니다.

PostgreSQL 노드 업그레이드#

Patroni(HA PostgreSQL) 구성을 사용 중이라면 이 섹션을 건너뛰고 Patroni 노드 업그레이드 단계를 따릅니다.

클러스터로 구성되지 않은 PostgreSQL 서버의 경우:

  1. Linux 패키지로 업그레이드하는 방법으로 서버를 업그레이드합니다.

  2. 업그레이드 프로세스는 바이너리가 업그레이드될 때 PostgreSQL을 재시작하지 않으므로, 새 버전을 로드하려면 재시작합니다.

    sudo gitlab-ctl restart

Patroni 노드 업그레이드#

Patroni는 PostgreSQL의 고가용성을 확보하는 데 사용됩니다.

PostgreSQL 메이저 버전 업그레이드가 필요하다면 메이저 버전 프로세스를 따릅니다.

그 밖의 모든 버전에 대한 업그레이드 프로세스는 먼저 모든 레플리카에서 수행됩니다. 레플리카가 업그레이드된 후 리더에서 업그레이드된 레플리카 중 하나로 클러스터 페일오버가 발생합니다. 이 과정은 페일오버가 한 번만 필요하도록 보장하며, 완료되면 새 리더가 업그레이드됩니다.

Patroni 노드를 업그레이드하려면 다음을 수행합니다.

  1. 리더 노드와 레플리카 노드를 확인하고 클러스터가 정상 상태인지 확인합니다. 데이터베이스 노드에서 다음을 실행합니다.

    sudo gitlab-ctl patroni members

  2. Linux 패키지로 업그레이드하는 방법으로 레플리카 노드 중 하나를 업그레이드합니다.

  3. 새 버전을 로드하려면 재시작합니다.

    sudo gitlab-ctl restart

  4. 클러스터가 정상 상태인지 확인합니다.

  5. 나머지 레플리카에 대해 업그레이드, 재시작, 상태 확인 단계를 반복합니다.

  6. 레플리카와 동일한 Linux 패키지 업그레이드 방식으로 리더 노드를 업그레이드합니다.

  7. 새 버전을 로드하고 클러스터 페일오버도 함께 발생시키기 위해 리더 노드의 모든 서비스를 재시작합니다.

    sudo gitlab-ctl restart

  8. 클러스터가 정상 상태인지 확인합니다.

PgBouncer 노드 업그레이드#

GitLab 애플리케이션(Rails) 노드에서 PgBouncer를 실행 중이라면 PgBouncer는 애플리케이션 서버 업그레이드의 일부로 업그레이드됩니다. 그렇지 않다면 Linux 패키지로 업그레이드하는 방법으로 PgBouncer 노드를 업그레이드합니다.

Redis 노드 업그레이드#

독립형 Redis 서버를 업그레이드하려면 Linux 패키지로 업그레이드합니다.

Redis HA(Sentinel 사용) 업그레이드#

Redis HA를 사용 중이라면 Redis HA 클러스터를 업그레이드하기 위해 제로 다운타임 안내를 따릅니다.

GitLab 애플리케이션(Rails) 노드 업그레이드#

레퍼런스 아키텍처에서 이 노드는 Rails 노드 라고 부릅니다. 이 노드는 첫 단계에서 종료했던 Puma 프로세스를 실행합니다. 이 노드를 업그레이드하는 과정은 설치 방법에 따라 다릅니다.

모든 Puma와 Sidekiq 프로세스는 이전 단계에서 이미 종료되었습니다. 각 GitLab 애플리케이션(Rails) 노드에서:

  1. /etc/gitlab/skip-auto-reconfigure가 존재하지 않는지 확인합니다.

  2. Puma와 Sidekiq 이 실행 중이지 않은지 확인합니다.

    ps -ef | egrep 'puma: | puma | sidekiq '

Rails 노드 중 하나를 모든 데이터베이스 마이그레이션 실행을 담당하는 배포 노드 로 선택합니다. 배포 노드에서:

  1. 서버가 일반 마이그레이션을 허용하도록 구성되어 있는지 확인합니다. /etc/gitlab/gitlab.rb에 gitlab_rails['auto_migrate'] = false가 포함되어 있지 않은지 확인합니다. gitlab_rails['auto_migrate'] = true 를 명시적으로 설정하거나, 기본 동작(true)을 사용하려면 생략합니다.

  2. PgBouncer를 사용 중이라면 마이그레이션을 실행하기 전에 PgBouncer를 거치지 않고 PostgreSQL에 직접 연결해야 합니다.

    Rails는 마이그레이션을 실행할 때 어드바이저리 락을 사용해 동일한 데이터베이스에서 동시 마이그레이션이 실행되지 않도록 방지합니다. 이 락은 트랜잭션 간에 공유되지 않으므로, 트랜잭션 풀링 모드의 PgBouncer로 데이터베이스 마이그레이션을 실행하면 ActiveRecord::ConcurrentMigrationError 오류와 그 밖의 문제가 발생합니다.

    1. Patroni를 실행 중이라면 리더 노드를 찾습니다. 데이터베이스 노드에서 다음을 실행합니다.

      sudo gitlab-ctl patroni members

    2. 배포 노드에서 gitlab.rb를 갱신합니다. gitlab_rails['db_host']와 gitlab_rails['db_port']를 다음 중 하나로 변경합니다.

      • 데이터베이스 서버의 호스트와 포트(클러스터로 구성되지 않은 PostgreSQL의 경우).
      • Patroni를 실행 중이라면 클러스터 리더의 호스트와 포트.

    3. 변경 사항을 적용합니다.

      sudo gitlab-ctl reconfigure

  3. Linux 패키지로 업그레이드하는 방법으로 GitLab을 업그레이드합니다.

  4. 다음을 실행해 데이터베이스 마이그레이션이 성공적으로 완료되었는지 확인합니다.

    sudo gitlab-rake db:migrate:status

    모든 마이그레이션이 끝날 때까지 나머지 Rails 노드를 업그레이드하지 않습니다.

  5. PgBouncer를 거치지 않도록 배포 노드에서 gitlab.rb를 변경했다면:

    1. 배포 노드에서 gitlab.rb를 갱신합니다. gitlab_rails['db_host']와 gitlab_rails['db_port']를 다시 PgBouncer 설정으로 되돌립니다.

    2. 변경 사항을 적용합니다.

      sudo gitlab-ctl reconfigure

  6. 모든 서비스가 업그레이드된 버전으로 실행되고 (해당하는 경우) PgBouncer를 통해 데이터베이스에 접근하도록 하기 위해 배포 노드의 모든 서비스를 재시작합니다.

    sudo gitlab-ctl restart

다음으로 나머지 모든 Puma와 Sidekiq 노드를 업그레이드합니다. 이 노드에서는 gitlab.rb의 gitlab_rails['auto_migrate']를 어떤 값으로 설정해도 됩니다.

이 노드들은 병렬로 업그레이드할 수 있습니다.

  1. Linux 패키지로 업그레이드하는 방법으로 GitLab을 업그레이드합니다.

  2. 모든 서비스가 재시작되었는지 확인합니다.

    sudo gitlab-ctl restart

모든 스테이트풀 구성 요소가 업그레이드된 후, GitLab chart 업그레이드 단계를 따라 스테이트리스 구성 요소(Webservice, Sidekiq, 그 밖의 지원 서비스)를 업그레이드합니다.

GitLab chart 업그레이드를 수행한 후 데이터베이스 클라이언트를 다시 시작합니다.

kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<value>
kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<value>
kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<value>

모니터 노드 업그레이드#

60 RPS 또는 3,000명 사용자 레퍼런스 아키텍처 구성의 일부로 Prometheus를 독립형 모니터링 노드로 구성했을 수 있습니다.

모니터 노드를 업그레이드하려면 Linux 패키지로 업그레이드합니다.