InfoGrab Docs

다운타임으로 멀티 노드 인스턴스 업그레이드

요약

다운타임이 있는 멀티 노드 GitLab 인스턴스를 업그레이드하려면: 다운타임이 있는 업그레이드를 시작하기 전에 다운타임 옵션을 고려합니다. 업그레이드하기 전에 GitLab 애플리케이션을 종료하여 데이터베이스에 대한 쓰기를 중지해야 합니다.

다운타임이 있는 멀티 노드 GitLab 인스턴스를 업그레이드하려면:

  1. GitLab 애플리케이션을 종료합니다.
  2. Consul 서버를 업그레이드합니다.
  3. Gitaly, Rails, PostgreSQL, Redis 및 PgBouncer를 임의의 순서로 업그레이드합니다. 클라우드 플랫폼의 PostgreSQL 또는 Redis를 사용하고 업그레이드가 필요한 경우 이 지침 대신 클라우드 공급자의 지침을 따릅니다.
  4. GitLab 애플리케이션(Sidekiq, Puma)을 업그레이드하고 애플리케이션을 시작합니다.

다운타임이 있는 업그레이드를 시작하기 전에 다운타임 옵션을 고려합니다.

GitLab 애플리케이션 종료#

업그레이드하기 전에 GitLab 애플리케이션을 종료하여 데이터베이스에 대한 쓰기를 중지해야 합니다. 프로세스는 설치 방법에 따라 다릅니다.

이러한 프로세스를 실행하는 모든 서버에서 Puma와 Sidekiq를 종료합니다:

sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl stop puma

Helm chart 인스턴스의 경우:

  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. Linux 패키지로 업그레이드하여 모든 Consul 서버를 업그레이드합니다.

  3. 한 번에 하나의 노드씩 모든 GitLab 서비스를 재시작합니다:

    sudo gitlab-ctl restart

Consul 클러스터 프로세스가 자체 서버에 있지 않고 Redis HA 또는 Patroni와 같은 다른 서비스와 공유될 수 있습니다. 이 경우 해당 서버를 업그레이드할 때:

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

Gitaly 및 Gitaly Cluster(Praefect) 업그레이드#

Gitaly Cluster(Praefect)에 속하지 않는 Gitaly 서버의 경우 Linux 패키지로 업그레이드하여 서버를 업그레이드합니다. 여러 Gitaly 샤드가 있는 경우 임의의 순서로 Gitaly 서버를 업그레이드할 수 있습니다.

Gitaly Cluster(Praefect)를 실행 중이라면 Gitaly Cluster(Praefect)의 무중단 업그레이드 프로세스를 따릅니다.

Amazon Machine Images 사용 시#

AWS에서 Amazon Machine Images(AMI)를 사용하는 경우 AMI 재배포 프로세스를 사용하여 Gitaly 노드를 업그레이드할 수 있습니다. 이 프로세스를 사용하려면 Elastic network interfaces(ENI)를 사용해야 합니다. Gitaly Cluster(Praefect)는 서버 호스트 이름으로 Git 저장소의 복제본을 추적합니다. ENI는 인스턴스가 재배포될 때 프라이빗 DNS 이름이 동일하게 유지되도록 보장할 수 있습니다. 스토리지가 동일하더라도 새 호스트 이름으로 노드가 재배포되면 Gitaly Cluster(Praefect)가 작동하지 않을 수 있습니다.

ENI를 사용하지 않는 경우 Linux 패키지를 사용하여 Gitaly 노드를 업그레이드해야 합니다.

AMI 재배포 프로세스를 사용하여 Gitaly Cluster(Praefect) 노드를 업그레이드하려면:

  1. AMI 재배포 프로세스에 gitlab-ctl reconfigure를 포함해야 합니다. AMI에 praefect['auto_migrate'] = false를 설정하여 모든 노드에 이를 적용합니다. 이 설정은 reconfigure가 데이터베이스 마이그레이션을 자동으로 실행하는 것을 방지합니다.
  2. 업그레이드된 이미지로 먼저 재배포할 첫 번째 노드는 배포 노드여야 합니다.
  3. 배포된 후 gitlab.rb에서 praefect['auto_migrate'] = true를 설정하고 gitlab-ctl reconfigure로 적용합니다.
  4. 이 명령은 데이터베이스 마이그레이션을 실행합니다.
  5. 다른 Gitaly Cluster(Praefect) 노드를 재배포합니다.

PostgreSQL 노드 업그레이드#

클러스터화되지 않은 PostgreSQL 서버의 경우:

  1. Linux 패키지로 업그레이드하여 서버를 업그레이드합니다.

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

    sudo gitlab-ctl restart

Patroni 노드 업그레이드#

Patroni는 PostgreSQL을 사용하여 고가용성을 달성하는 데 사용됩니다.

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

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

Patroni 노드를 업그레이드하려면:

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

    sudo gitlab-ctl patroni members

  2. Linux 패키지로 업그레이드하여 복제본 노드 중 하나를 업그레이드합니다.

  3. 새 버전을 로드하기 위해 재시작합니다:

    sudo gitlab-ctl restart

  4. 클러스터가 정상인지 확인합니다.

  5. 다른 복제본에 대해 업그레이드, 재시작 및 상태 확인 단계를 반복합니다.

  6. 복제본과 동일한 Linux 패키지 업그레이드를 따라 리더 노드를 업그레이드합니다.

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

    sudo gitlab-ctl restart

  8. 클러스터가 정상인지 확인합니다

PgBouncer 노드 업그레이드#

GitLab 애플리케이션(Rails) 노드에서 PgBouncer를 실행하는 경우 PgBouncer는 애플리케이션 서버 업그레이드의 일부로 업그레이드됩니다. 그렇지 않으면 Linux 패키지로 업그레이드하여 PgBouncer 노드를 업그레이드합니다.

Redis 노드 업그레이드#

독립 실행형 Redis 서버를 업그레이드하려면 Linux 패키지로 업그레이드합니다.

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

Redis HA를 사용하는 경우 Redis HA 클러스터를 업그레이드하기 위해 무중단 지침을 따릅니다.

GitLab 애플리케이션 구성 요소 업그레이드#

GitLab 애플리케이션을 업그레이드하는 프로세스는 설치 방법에 따라 다릅니다.

이전에 모든 Puma 및 Sidekiq 프로세스가 종료되었습니다. 각 GitLab 애플리케이션 노드에서:

  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에 직접 연결해야 합니다.

    Rails는 마이그레이션 실행 시 동시 마이그레이션이 동일한 데이터베이스에서 실행되는 것을 방지하기 위해 advisory lock을 사용합니다. 이러한 잠금은 트랜잭션 간에 공유되지 않아 트랜잭션 풀링 모드에서 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. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

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

    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. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

  2. 모든 서비스가 재시작되었는지 확인합니다:

    sudo gitlab-ctl restart

모든 상태 저장 구성 요소가 업그레이드된 후 GitLab chart 업그레이드 단계를 따라 상태 비저장 구성 요소(Webservice, Sidekiq, 기타 지원 서비스)를 업그레이드합니다.

GitLab chart 업그레이드를 수행한 후 데이터베이스 클라이언트를 재개합니다:

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>

모니터 노드 업그레이드#

Prometheus를 독립 실행형 모니터링 노드로 구성했을 수 있습니다. 예를 들어 60 RPS 또는 3,000 사용자 참조 아키텍처 구성의 일부로.

모니터 노드를 업그레이드하려면 Linux 패키지로 업그레이드합니다.

다운타임으로 멀티 노드 인스턴스 업그레이드

Tier: Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

다운타임이 있는 멀티 노드 GitLab 인스턴스를 업그레이드하려면: 다운타임이 있는 업그레이드를 시작하기 전에 다운타임 옵션을 고려합니다. 업그레이드하기 전에 GitLab 애플리케이션을 종료하여 데이터베이스에 대한 쓰기를 중지해야 합니다.

다운타임이 있는 멀티 노드 GitLab 인스턴스를 업그레이드하려면:

  1. GitLab 애플리케이션을 종료합니다.
  2. Consul 서버를 업그레이드합니다.
  3. Gitaly, Rails, PostgreSQL, Redis 및 PgBouncer를 임의의 순서로 업그레이드합니다. 클라우드 플랫폼의 PostgreSQL 또는 Redis를 사용하고 업그레이드가 필요한 경우 이 지침 대신 클라우드 공급자의 지침을 따릅니다.
  4. GitLab 애플리케이션(Sidekiq, Puma)을 업그레이드하고 애플리케이션을 시작합니다.

다운타임이 있는 업그레이드를 시작하기 전에 다운타임 옵션을 고려합니다.

GitLab 애플리케이션 종료#

업그레이드하기 전에 GitLab 애플리케이션을 종료하여 데이터베이스에 대한 쓰기를 중지해야 합니다. 프로세스는 설치 방법에 따라 다릅니다.

이러한 프로세스를 실행하는 모든 서버에서 Puma와 Sidekiq를 종료합니다:

sudo gitlab-ctl stop sidekiq
sudo gitlab-ctl stop puma

Helm chart 인스턴스의 경우:

  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. Linux 패키지로 업그레이드하여 모든 Consul 서버를 업그레이드합니다.

  3. 한 번에 하나의 노드씩 모든 GitLab 서비스를 재시작합니다:

    sudo gitlab-ctl restart

Consul 클러스터 프로세스가 자체 서버에 있지 않고 Redis HA 또는 Patroni와 같은 다른 서비스와 공유될 수 있습니다. 이 경우 해당 서버를 업그레이드할 때:

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

Gitaly 및 Gitaly Cluster(Praefect) 업그레이드#

Gitaly Cluster(Praefect)에 속하지 않는 Gitaly 서버의 경우 Linux 패키지로 업그레이드하여 서버를 업그레이드합니다. 여러 Gitaly 샤드가 있는 경우 임의의 순서로 Gitaly 서버를 업그레이드할 수 있습니다.

Gitaly Cluster(Praefect)를 실행 중이라면 Gitaly Cluster(Praefect)의 무중단 업그레이드 프로세스를 따릅니다.

Amazon Machine Images 사용 시#

AWS에서 Amazon Machine Images(AMI)를 사용하는 경우 AMI 재배포 프로세스를 사용하여 Gitaly 노드를 업그레이드할 수 있습니다. 이 프로세스를 사용하려면 Elastic network interfaces(ENI)를 사용해야 합니다. Gitaly Cluster(Praefect)는 서버 호스트 이름으로 Git 저장소의 복제본을 추적합니다. ENI는 인스턴스가 재배포될 때 프라이빗 DNS 이름이 동일하게 유지되도록 보장할 수 있습니다. 스토리지가 동일하더라도 새 호스트 이름으로 노드가 재배포되면 Gitaly Cluster(Praefect)가 작동하지 않을 수 있습니다.

ENI를 사용하지 않는 경우 Linux 패키지를 사용하여 Gitaly 노드를 업그레이드해야 합니다.

AMI 재배포 프로세스를 사용하여 Gitaly Cluster(Praefect) 노드를 업그레이드하려면:

  1. AMI 재배포 프로세스에 gitlab-ctl reconfigure를 포함해야 합니다. AMI에 praefect['auto_migrate'] = false를 설정하여 모든 노드에 이를 적용합니다. 이 설정은 reconfigure가 데이터베이스 마이그레이션을 자동으로 실행하는 것을 방지합니다.
  2. 업그레이드된 이미지로 먼저 재배포할 첫 번째 노드는 배포 노드여야 합니다.
  3. 배포된 후 gitlab.rb에서 praefect['auto_migrate'] = true를 설정하고 gitlab-ctl reconfigure로 적용합니다.
  4. 이 명령은 데이터베이스 마이그레이션을 실행합니다.
  5. 다른 Gitaly Cluster(Praefect) 노드를 재배포합니다.

PostgreSQL 노드 업그레이드#

클러스터화되지 않은 PostgreSQL 서버의 경우:

  1. Linux 패키지로 업그레이드하여 서버를 업그레이드합니다.

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

    sudo gitlab-ctl restart

Patroni 노드 업그레이드#

Patroni는 PostgreSQL을 사용하여 고가용성을 달성하는 데 사용됩니다.

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

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

Patroni 노드를 업그레이드하려면:

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

    sudo gitlab-ctl patroni members

  2. Linux 패키지로 업그레이드하여 복제본 노드 중 하나를 업그레이드합니다.

  3. 새 버전을 로드하기 위해 재시작합니다:

    sudo gitlab-ctl restart

  4. 클러스터가 정상인지 확인합니다.

  5. 다른 복제본에 대해 업그레이드, 재시작 및 상태 확인 단계를 반복합니다.

  6. 복제본과 동일한 Linux 패키지 업그레이드를 따라 리더 노드를 업그레이드합니다.

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

    sudo gitlab-ctl restart

  8. 클러스터가 정상인지 확인합니다

PgBouncer 노드 업그레이드#

GitLab 애플리케이션(Rails) 노드에서 PgBouncer를 실행하는 경우 PgBouncer는 애플리케이션 서버 업그레이드의 일부로 업그레이드됩니다. 그렇지 않으면 Linux 패키지로 업그레이드하여 PgBouncer 노드를 업그레이드합니다.

Redis 노드 업그레이드#

독립 실행형 Redis 서버를 업그레이드하려면 Linux 패키지로 업그레이드합니다.

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

Redis HA를 사용하는 경우 Redis HA 클러스터를 업그레이드하기 위해 무중단 지침을 따릅니다.

GitLab 애플리케이션 구성 요소 업그레이드#

GitLab 애플리케이션을 업그레이드하는 프로세스는 설치 방법에 따라 다릅니다.

이전에 모든 Puma 및 Sidekiq 프로세스가 종료되었습니다. 각 GitLab 애플리케이션 노드에서:

  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에 직접 연결해야 합니다.

    Rails는 마이그레이션 실행 시 동시 마이그레이션이 동일한 데이터베이스에서 실행되는 것을 방지하기 위해 advisory lock을 사용합니다. 이러한 잠금은 트랜잭션 간에 공유되지 않아 트랜잭션 풀링 모드에서 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. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

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

    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. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

  2. 모든 서비스가 재시작되었는지 확인합니다:

    sudo gitlab-ctl restart

모든 상태 저장 구성 요소가 업그레이드된 후 GitLab chart 업그레이드 단계를 따라 상태 비저장 구성 요소(Webservice, Sidekiq, 기타 지원 서비스)를 업그레이드합니다.

GitLab chart 업그레이드를 수행한 후 데이터베이스 클라이언트를 재개합니다:

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>

모니터 노드 업그레이드#

Prometheus를 독립 실행형 모니터링 노드로 구성했을 수 있습니다. 예를 들어 60 RPS 또는 3,000 사용자 참조 아키텍처 구성의 일부로.

모니터 노드를 업그레이드하려면 Linux 패키지로 업그레이드합니다.