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

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

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 Cluster)

Gitaly 클러스터를 실행 중인 경우, zero downtime process를 따르세요.

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

  • Elastic network interfaces (ENI)를 사용하는 경우 AMI 프로세스를 통해 업그레이드할 수 있습니다. ENI를 사용하면 Gitaly가 작동하는 데 필수적인 개인 DNS 이름을 AMI 인스턴스 변경을 통해 유지할 수 있습니다.
  • ENI를 사용하지 않는 경우, Gitaly를 패키지를 통해 업그레이드해야 합니다. 이는 Gitaly 클러스터가 서버 호스트 이름을 통해 Git 리포지터리의 복제본을 추적하기 때문에 AMI를 사용한 재배포는 노드에 새 호스트 이름을 지정합니다. 저장 공간은 동일하지만 호스트 이름이 변경되면 Gitaly 클러스터가 작동하지 않습니다.

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

  1. AMI 재배포 프로세스에 gitlab-ctl reconfigure를 포함해야 합니다. 모든 노드에 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 노드 업그레이드

만약 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)을 위해 생략하세요.

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

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

    PgBouncer를 사용할 때 데이터베이스 마이그레이션을 실행하면 동시 마이그레이션이 동일한 데이터베이스에서 실행되는 것을 방지하기 위해 보조 잠금을 사용합니다. 이러한 잠금은 트랜잭션 간에 공유되지 않으므로 ActiveRecord::ConcurrentMigrationError 및 기타 문제가 발생합니다. 트랜잭션 풀링 모드에서 PgBouncer를 사용하여 데이터베이스 마이그레이션을 실행하는 경우 사이에서 UTILIZATION의 주장 잠금을 사용합니다.

    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
Cloud Native Hybrid

모든 상태 유지 컴포넌트를 업그레이드한 후, 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 패키지를 업그레이드하세요.