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

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

  • Elastic network interfaces (ENI)를 사용하는 경우, AMI 프로세스를 통해 업그레이드할 수 있습니다. ENI를 사용하면 Gitaly가 작동하는 데 중요한 사항인 개인 DNS 이름을 유지할 수 있습니다.
  • ENI를 사용하지 않는 경우, Gitaly 클러스터에서는 서버 호스트 이름에 의해 Git 리포지터리의 복제본을 추적하므로 새로운 호스트 이름이 나오면 Gitaly 클러스터가 작동하지 않게 됩니다. 따라서 AMI를 사용하지 않고 GitLab 패키지를 업그레이드해야 합니다.

그러나 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 서버를 업그레이드하려면 GitLab 패키지를 업그레이드합니다.

여러 Gitaly 샤드를 갖거나 NFS를 사용하는 여러 로드 밸런스된 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 (application) 노드에서 PgBouncer를 실행 중이라면, PgBouncer는 애플리케이션 서버 업그레이드의 일부로 업그레이드됩니다.

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

Redis 노드 업그레이드

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

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.rb에서 gitlab_rails['auto_migrate'] 설정은 아무 값으로 설정할 수 있습니다.

이러한 노드는 병렬로 업그레이드할 수 있습니다:

  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>

Monitor 노드 업그레이드

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