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

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
클라우드 네이티브 하이브리드

클라우드 네이티브 하이브리드 환경의 경우:

  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 (AMI)를 사용 중이라면, AMI 프로세스를 통해 Gitaly 노드를 업그레이드하거나 패키지 자체를 업그레이드할 수 있습니다:

  • Elastic network interfaces (ENI)를 사용하고 있다면, AMI 프로세스를 통해 업그레이드할 수 있습니다. ENI를 사용하면 Gitaly가 작동하는 데 중요한 사항인 개인 DNS 이름을 AMI 인스턴스 변경을 통해 유지할 수 있습니다.
  • ENI를 사용하지 않는 경우, Gitaly 클러스터가 서버 호스트 이름의 복제본을 추적하고 있기 때문에 호스트 이름이 변경되면 Gitaly 클러스터가 작동하지 않습니다. 따라서 새로운 호스트 이름을 가진 노드가 생성되며, 저장소는 동일하지만 호스트 이름이 변경될 때 Gitaly 클러스터는 작동하지 않습니다.

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

  1. AMI 재배포 프로세스에 gitlab-ctl reconfigure를 포함해야 합니다. praefect['auto_migrate'] = false를 AMI에 설정하여 모든 노드가 이 값을 사용하도록 합니다. 이렇게 하면 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 주 버전 업그레이드가 필요한 경우, 주 버전 프로세스를 따릅니다.

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

다음 프로세스를 따르세요:

  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가 없는지 확인하세요. 특정하게 설정하거나 기본 동작(true)에 대한 설정을 제외하고 gitlab_rails['auto_migrate'] = 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. 배포 노드에서 GitLab 패키지를 업그레이드하세요.

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

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

      sudo gitlab-ctl reconfigure

  5. 모든 서비스가 업그레이드된 버전을 실행하고(적용 가능한 경우) PgBouncer를 사용하여 데이터베이스에 액세스하는지 확인하기 위해 배포 노드의 모든 서비스를 재시작하세요: 

    sudo gitlab-ctl restart

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

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

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

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

    sudo gitlab-ctl restart
Cloud Native Hybrid

모든 상태 유지(stateful) 구성 요소가 업그레이드된 이후, 상태 무관(stateless) 구성 요소를 GitLab 차트 업그레이드 단계를 따라야 합니다.

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

kubectl scale deploy -lapp=sidekiq,release=<helm 릴리스 이름> -n <네임스페이스> --replicas=<값>
kubectl scale deploy -lapp=webservice,release=<helm 릴리스 이름> -n <네임스페이스> --replicas=<값>
kubectl scale deploy -lapp=prometheus,release=<helm 릴리스 이름> -n <네임스페이스> --replicas=<값>

모니터 노드 업그레이드

GitLab 패키지를 업그레이드합니다.