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

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

다중 노드 GitLab 배포를 다운타임 없이 업그레이드할 수는 있지만, 일부 제약 사항이 있습니다. 특히 한 번에 한 번증 릴리스로만 업그레이드할 수 있으며, 예를 들어 14.6에서 14.7로, 다음으로 14.8로 업그레이드할 수 있습니다.

하나 이상의 번증 릴리스로 한꺼번에 업그레이드하려면(예: 14.6에서 14.9로), GitLab 인스턴스를 오프라인 상태로 전환하여(다운타임이 발생) 업그레이드해야 합니다. 이 과정을 시작하기 전에 버전별 업그레이드 지침 및 업그레이드 경로에 관련된 지침을 확인하세요.

단일 노드 설치의 경우, 단순히 GitLab 패키지를 업그레이드하면 됩니다.

다중 노드 GitLab 설치의 여러 구성요소를 업그레이드하는 프로세스는 다운타임 없는 업그레이드와 동일합니다. 차이점은 레일즈(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 클러스터가 서버 호스트 이름별로 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 주 버전 업그레이드가 필요한 경우, 주 버전 프로세스를 따르세요.

다른 모든 버전의 업그레이드 프로세스는 모든 레플리카에서 수행됩니다. 그들이 업그레이드되면 리더에서 한 클러스터 장애 조치(failover)가 일어납니다. 이를 통해 장애 조치가 한 번만 필요하며 완료되면 새 리더가 업그레이드됩니다.

다음 절차를 따르세요:

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

    sudo gitlab-ctl patroni members

  2. 레플리카 중 하나에서 GitLab 패키지를 업그레이드하세요.

  3. 새 버전을 로드하려면 다시 시작하세요: 

    sudo gitlab-ctl restart
  4. 클러스터가 정상인지 확인하세요.
  5. 다른 레플리카에 대해 이러한 단계를 반복하세요: 업그레이드, 다시 시작, 상태 확인.
  6. 리더 노드를 업그레이드하고 레플리카와 동일한 패키지 업그레이드를 따르세요.

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

    sudo gitlab-ctl restart
  8. 클러스터가 정상인지 확인하세요

PgBouncer 노드 업그레이드

PgBouncer를 Rails(응용 프로그램) 노드에서 실행 중인 경우 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)에 대해 생략하세요.

  2. 만약 PgBouncer를 사용 중이라면:

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

    PgBouncer를 사용하여 데이터베이스 마이그레이션을 실행하는 동안 동일한 데이터베이스에서 동시 마이그레이션을 방지하기 위해 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']를 및 gitlab_rails['db_port']를 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
클라우드 네이티브 하이브리드

모든 상태 유지(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 패키지를 업그레이드하세요.