다운타임이 있는 다중 노드 업그레이드

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

다중 노드 GitLab 배포를 제로 다운타임으로 업그레이드할 수 있지만, 여러 가지 제약이 있습니다. 특히, 한 번에 하나의 마이너 릴리스만 업그레이드할 수 있습니다. 예를 들어, 14.6에서 14.7로, 그리고 14.8로 진행할 수 있습니다.

두 개 이상의 마이너 릴리스를 한 번에 업그레이드하려면(예를 들어, 14.6에서 14.9로), GitLab 인스턴스를 오프라인으로 만들어야 하며, 이는 다운타임을 의미합니다. 이 프로세스를 시작하기 전에, 귀하의 업그레이드 경로와 관련된 버전별 업그레이드 지침을 확인하세요:

단일 노드 설치의 경우, GitLab 패키지 업그레이드만 수행해야 합니다.

다중 노드 GitLab 설치의 여러 구성 요소를 업그레이드하는 프로세스는 제로 다운타임 업그레이드와 동일합니다. 차이점은 Rails(Puma/Sidekiq)를 실행하는 서버와 이벤트 순서와 관련이 있습니다.

전반적으로, 프로세스는 다음과 같습니다:

  1. GitLab 애플리케이션을 종료합니다.
  2. Consul 서버를 업그레이드합니다.
  3. 다른 백엔드 구성 요소를 업그레이드합니다:
    • Gitaly, Rails PostgreSQL, Redis, PgBouncer: 이러한 구성 요소는 어떤 순서로 업그레이드해도 됩니다.
    • 클라우드 플랫폼에서 PostgreSQL 또는 Redis를 사용하는 경우, 업그레이드가 필요하면 Omnibus GitLab에 대한 지침을 클라우드 공급자의 지침으로 대체하십시오.
  4. GitLab 애플리케이션(Sidekiq, Puma)을 업그레이드하고 애플리케이션을 시작합니다.

데이터베이스에 대한 쓰기 중지

업그레이드 전에 데이터베이스에 대한 쓰기를 중지해야 합니다. 이 프로세스는 귀하의 참조 아키텍처에 따라 다릅니다.

Linux 패키지

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

sudo gitlab-ctl stop sidekiq  
sudo gitlab-ctl stop puma
클라우드 네이티브 하이브리드

Cloud Native Hybrid 환경의 경우:

  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. 모든 Consul 서버에서 GitLab 패키지 업그레이드를 수행합니다.

  3. GitLab 서비스를 노드당 한 번씩 재시작합니다:

    sudo gitlab-ctl restart

Consul 클러스터 프로세스가 별도의 서버에 있지 않고 Redis HA 또는 Patroni와 같은 다른 서비스와 공유되는 경우, 해당 서버 업그레이드 시 다음 원칙을 준수하십시오:

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

Gitaly 노드 업그레이드 (Praefect / Gitaly 클러스터)

Gitaly 클러스터를 실행 중이라면, Gitaly 클러스터를 위한 제로 다운타임 프로세스를 따르세요.

AWS에서 Amazon Machine Images (AMIs)를 사용하는 경우, AMI 프로세스를 통해 Gitaly 노드를 업그레이드하거나 패키지 자체를 업그레이드할 수 있습니다:

  • Elastic network interfaces (ENI)를 사용하는 경우, AMI 프로세스를 통해 업그레이드할 수 있습니다. ENI를 사용하면 AMI 인스턴스 변경 시 개인 DNS 이름을 유지할 수 있으며, 이는 Gitaly가 작동하는 데 중요한 요소입니다.

  • ENI를 사용하지 않는 경우, GitLab 패키지를 사용하여 Gitaly를 업그레이드해야 합니다. 이는 Gitaly 클러스터가 서버 호스트 이름에 따라 Git 리포지토리의 복제본을 추적하기 때문이며, AMI를 사용한 재배포 시 노드에 새 호스트 이름이 부여됩니다. 저장소는 동일하지만 호스트 이름이 변경되면 Gitaly 클러스터가 작동하지 않습니다.

그러나 Praefect 노드는 AMI 재배포 프로세스를 통해 업그레이드할 수 있습니다:

  1. AMI 재배포 프로세스에는 gitlab-ctl reconfigure를 포함해야 합니다. AMI에 praefect['auto_migrate'] = false를 설정하여 모든 노드가 이를 받도록 합니다. 이렇게 하면 reconfigure가 자동으로 데이터베이스 마이그레이션을 실행하지 않습니다.

  2. 업그레이드된 이미지를 사용하여 재배포하는 첫 번째 노드는 배포 노드여야 합니다.

  3. 배포가 완료된 후 gitlab.rb에서 praefect['auto_migrate'] = true로 설정하고 gitlab-ctl reconfigure를 적용합니다. 이는 데이터베이스 마이그레이션을 실행합니다.

  4. 다른 Praefect 노드를 재배포합니다.

Gitaly 클러스터에 포함되지 않은 Gitaly 노드 업그레이드

Gitaly 클러스터의 일부가 아닌 Gitaly 서버에 대해서는 GitLab 패키지를 업그레이드하세요.

여러 Gitaly 샤드를 가지고 있거나 NFS를 사용하는 여러 로드 밸런스 Gitaly 노드가 있는 경우, Gitaly 서버를 업그레이드하는 순서는 중요하지 않습니다.

PostgreSQL 노드 업그레이드

비클러스터 PostgreSQL 서버의 경우:

  1. GitLab 패키지를 업그레이드하세요.

  2. 업그레이드 프로세스는 바이너리가 업그레이드될 때 PostgreSQL을 다시 시작하지 않습니다. 새 버전을 로드하기 위해 다시 시작하세요:

    sudo gitlab-ctl restart

Patroni 노드 업그레이드

Patroni는 PostgreSQL과 함께 고가용성을 달성하기 위해 사용됩니다.

PostgreSQL 주요 버전 업그레이드가 필요한 경우, 주요 버전 프로세스를 따르세요.

모든 다른 버전의 업그레이드 프로세스는 먼저 모든 복제 노드에서 수행됩니다. 복제 노드가 업그레이드된 후, 클러스터 장애 조치가 리더에서 업그레이드된 복제 노드 중 하나로 발생합니다. 이는 장애 조치가 하나만 필요하도록 보장하며, 완료되면 새로운 리더가 업그레이드됩니다.

다음 절차를 따릅니다:

  1. 리더 및 복제 노드를 식별하고 클러스터가 정상인지 확인하세요. 데이터베이스 노드에서 실행:

    sudo gitlab-ctl patroni members

  2. 복제 노드 중 하나에서 GitLab 패키지를 업그레이드하세요.

  3. 새 버전을 로드하기 위해 다시 시작하세요:

    sudo gitlab-ctl restart

  4. 클러스터가 정상인지 확인하세요.

  5. 다른 복제 노드에 대해 이 단계를 반복합니다: 업그레이드, 다시 시작, 건강 체크.

  6. 복제 노드와 동일한 패키지 업그레이드를 따르면서 리더 노드를 업그레이드합니다.

  7. 리더 노드에서 모든 서비스를 다시 시작하여 새 버전을 로드하고 클러스터 장애 조치도 트리거합니다:

    sudo gitlab-ctl restart

  8. 클러스터가 정상인지 확인하세요

PgBouncer 노드 업그레이드

Rails (애플리케이션) 노드에서 PgBouncer를 실행하는 경우,

PgBouncer는 애플리케이션 서버 업그레이드의 일환으로 업그레이드됩니다.

PgBouncer 노드에서 GitLab 패키지 업그레이드 를 수행하세요.

Redis 노드 업그레이드

독립형 Redis 서버를 GitLab 패키지 업그레이드 를 통해 업그레이드하세요.

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

Tier: Premium, Ultimate

Offering: Self-managed

무중단 업그레이드 지침을 따라

Redis HA 클러스터를 업그레이드하세요.

Rails 구성 요소 업그레이드

Linux 패키지

모든 Puma 및 Sidekiq 프로세스는 이전에 중지되었습니다. 각 노드에서:

  1. /etc/gitlab/skip-auto-reconfigure가 존재하지 않는지 확인하세요.

  2. Puma 및 Sidekiq가 중지되었는지 확인하세요:

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

Puma를 실행하는 노드를 하나 선택하세요. 이것이 배포 노드이며

모든 데이터베이스 마이그레이션을 실행하는 책임이 있습니다. 배포 노드에서:

  1. 서버가 정기적인 마이그레이션을 허용하도록 구성되어 있는지 확인하세요.

/etc/gitlab/gitlab.rb에 gitlab_rails['auto_migrate'] = false가 포함되어 있지 않은지 확인하세요.

이를 명시적으로 gitlab_rails['auto_migrate'] = true로 설정하거나 생략하여 기본 동작(true)을 유지하세요.

  1. PgBouncer를 사용하는 경우:

    PgBouncer를 우회하고 마이그레이션을 실행하기 전에 PostgreSQL에 직접 연결해야 합니다.

    Rails는 마이그레이션을 실행하려고 할 때 동시 마이그레이션이 동일한 데이터베이스에서 실행되는 것을 방지하기 위해 어드바이저리 잠금을 사용합니다.

    이러한 잠금은 트랜잭션 간에 공유되지 않으며, 결과적으로 ActiveRecord::ConcurrentMigrationError 및 PgBouncer를 사용하여

    트랜잭션 풀링 모드에서 데이터베이스 마이그레이션을 실행할 때 다른 문제를 발생시킵니다.

    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

  2. GitLab 패키지 업그레이드.

  3. PgBouncer를 우회하기 위해 배포 노드에서 gitlab.rb를 수정한 경우:

    1. 배포 노드에서 gitlab.rb를 업데이트하세요. gitlab_rails['db_host']와 gitlab_rails['db_port']를 PgBouncer 설정으로 다시 변경하세요.

    2. 변경 사항을 적용하세요:

      sudo gitlab-ctl reconfigure

  4. 모든 서비스가 업그레이드된 버전을 실행하고 있는지 확인하고, (해당되는 경우) PgBouncer를 사용하여 데이터베이스에 접근하는지 확인하기 위해,

    배포 노드에서 모든 서비스를 재시작하세요:

    sudo gitlab-ctl restart

다음으로, 모든 다른 Puma 및 Sidekiq 노드를 업그레이드하세요. gitlab_rails['auto_migrate'] 설정은 이러한 노드의 gitlab.rb에서 아무 값으로 설정할 수 있습니다.

이를 병렬로 업그레이드할 수 있습니다:

  1. GitLab 패키지 업그레이드.

  2. 모든 서비스가 재시작되었는지 확인하세요:

    sudo gitlab-ctl restart
클라우드 네이티브 하이브리드

모든 상태 저장 구성 요소가 업그레이드되었으므로,

GitLab 차트 업그레이드 단계를 따라

무상태 구성 요소(Webservice, Sidekiq, 기타 지원 서비스)를 업그레이드해야 합니다.

GitLab 차트 업그레이드를 수행한 후, 데이터베이스 클라이언트를 다시 시작하세요:

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>

모니터 노드 업그레이드

GitLab 패키지 업그레이드.