InfoGrab Docs

다운타임 없이 다중 노드 인스턴스 업그레이드

요약

다운타임 없이 다중 노드 GitLab 환경을 업그레이드하는 프로세스는 업그레이드 순서에 따라 각 노드를 순차적으로 처리하는 것을 포함합니다. 다운타임 없이 업그레이드를 시작하기 전에 다운타임 옵션을 고려하십시오. 업그레이드의 일부로 다운타임 제로를 달성하는 것은 분산 애플리케이션에서 특히 어렵습니다.

다운타임 없이 다중 노드 GitLab 환경을 업그레이드하는 프로세스는 업그레이드 순서에 따라 각 노드를 순차적으로 처리하는 것을 포함합니다. 로드 밸런서 및 HA 메커니즘은 각 노드가 다운되는 상황을 적절히 처리합니다.

다운타임 없이 업그레이드를 시작하기 전에 다운타임 옵션을 고려하십시오.

시작하기 전에#

업그레이드의 일부로 다운타임 제로를 달성하는 것은 분산 애플리케이션에서 특히 어렵습니다. 문서는 HA 참조 아키텍처에 대해 테스트되었으며 사실상 관측 가능한 다운타임이 없었습니다. 그러나 특정 시스템 구성에 따라 결과가 다를 수 있음을 알고 있으십시오.

추가적인 확신을 위해 일부 고객은 특정 로드 밸런서 또는 인프라 기능을 사용하여 노드를 수동으로 드레인하는 것과 같은 추가 기술을 성공적으로 사용했습니다. 이러한 기술은 기본 인프라 기능에 크게 의존합니다.

추가 정보는 GitLab 담당자 또는 지원팀에 문의하십시오.

요구 사항#

다운타임 제로 업그레이드 프로세스는 다음과 같이 구성된 로드 밸런싱 및 사용 가능한 HA 메커니즘이 있는 Linux 패키지로 구축된 다중 노드 GitLab 환경이 필요합니다:

  • readiness (/-/readiness) 엔드포인트에 대한 상태 확인이 활성화된 GitLab 애플리케이션 노드를 위한 외부 로드 밸런서.
  • TCP 상태 확인이 활성화된 PgBouncer 및 Praefect 구성 요소를 위한 내부 로드 밸런서.
  • 존재하는 경우 Consul, Postgres 및 Redis 구성 요소를 위해 구성된 HA 메커니즘.

다운타임 제로 업그레이드를 위해서는 다음을 수행해야 합니다:

고려 사항#

다운타임 제로 업그레이드를 고려할 때 다음을 알고 있으십시오:

  • 대부분의 경우 패치 릴리스가 최신 버전이 아닌 경우 패치 릴리스에서 다음 마이너 릴리스로 안전하게 업그레이드할 수 있습니다. 예를 들어 16.3.3이 릴리스된 경우에도 16.3.2에서 16.4.1로 업그레이드하는 것이 안전합니다. 업그레이드 경로와 관련된 버전별 업그레이드 노트를 확인하고 필수 업그레이드 중지 지점을 알고 있어야 합니다:

  • 일부 릴리스에는 백그라운드 마이그레이션이 포함될 수 있습니다. 이러한 마이그레이션은 Sidekiq에 의해 백그라운드에서 수행되며 종종 데이터를 마이그레이션하는 데 사용됩니다. 백그라운드 마이그레이션은 월간 릴리스에만 추가됩니다.

    • 특정 주요 또는 마이너 릴리스에서는 백그라운드 마이그레이션 세트가 완료되어야 할 수 있습니다. 이는 다운타임을 필요로 하지 않지만(이전 조건이 충족된 경우), 각 주요 또는 마이너 릴리스 업그레이드 사이에 백그라운드 마이그레이션이 완료될 때까지 기다려야 합니다.
    • 이러한 마이그레이션을 완료하는 데 필요한 시간은 background_migration 큐의 작업을 처리할 수 있는 Sidekiq 작업자 수를 늘려 줄일 수 있습니다. 이 큐의 크기를 보려면 업그레이드 전에 백그라운드 마이그레이션을 확인하십시오.

  • 우아한 리로드 메커니즘으로 인해 Gitaly에 대해 다운타임 제로 업그레이드를 수행할 수 있습니다. Gitaly 클러스터(Praefect) 구성 요소도 다운타임 없이 직접 업그레이드할 수 있습니다. 그러나 Linux 패키지는 Praefect 데이터베이스에 대한 HA 또는 다운타임 제로 지원을 제공하지 않습니다. 다운타임을 방지하기 위해 타사 데이터베이스 솔루션이 필요합니다.

  • PostgreSQL 주요 버전 업그레이드는 별도의 프로세스이며 다운타임 제로 업그레이드에 포함되지 않습니다. 더 작은 업그레이드는 포함됩니다.

  • 다운타임 제로 업그레이드는 Linux 패키지로 배포한 언급된 GitLab 구성 요소에 지원됩니다. AWS RDS의 PostgreSQL 또는 GCP Memorystore의 Redis와 같이 지원되는 타사 서비스를 통해 특정 구성 요소를 배포한 경우 해당 서비스의 업그레이드는 표준 프로세스에 따라 별도로 수행해야 합니다.

  • 일반적인 지침으로 데이터가 많을수록 업그레이드가 완료되는 데 더 많은 시간이 필요합니다. 테스트에서 10GB 미만의 데이터베이스는 일반적으로 1시간 이상 걸리지 않지만 결과가 다를 수 있습니다.

업그레이드 순서#

다운타임 제로로 업그레이드할 구성 요소의 순서로 뒤에서 앞으로 접근 방식을 취해야 합니다:

  1. 상태 저장 백엔드
  2. 백엔드 종속 구성 요소
  3. 프론트엔드

배포 순서를 변경할 수 있지만 GitLab 애플리케이션 코드를 실행하는 구성 요소(예: Rails 및 Sidekiq)를 함께 배포해야 합니다. 가능하면 지원 인프라를 별도로 업그레이드하십시오. 이러한 구성 요소는 주요 릴리스에 대한 버전 업그레이드에서 도입된 변경 사항에 의존성이 없기 때문입니다.

GitLab 구성 요소를 다음 순서로 업그레이드해야 합니다:

  1. Consul
  2. PostgreSQL
  3. PgBouncer
  4. Redis
  5. Gitaly
  6. Praefect
  7. Rails
  8. Sidekiq

Consul, PostgreSQL, PgBouncer 및 Redis 노드 업그레이드#

Consul, PostgreSQL, PgBouncer 및 Redis 구성 요소는 모두 다운타임 없이 업그레이드하는 것과 동일한 기본 프로세스를 따릅니다.

업그레이드를 수행할 각 구성 요소의 노드에서:

  1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

    sudo touch /etc/gitlab/skip-auto-reconfigure

  2. Linux 패키지로 업그레이드하여 노드를 업그레이드합니다.

  3. 재구성하고 재시작하여 최신 코드를 적용합니다:

    sudo gitlab-ctl reconfigure

PostgreSQL 페일오버가 원활하게 발생하도록 Consul 클라이언트를 먼저 재시작한 다음 다른 모든 서비스를 재시작합니다:

sudo gitlab-ctl restart consul
sudo gitlab-ctl restart-except consul

   sudo gitlab-ctl restart

Gitaly 노드 업그레이드#

Gitaly는 업그레이드 시 동일한 핵심 프로세스를 따르지만 가장 빠른 기회에 우아하게 리로드하는 내장 프로세스가 있어 Gitaly 프로세스 자체는 재시작되지 않는다는 점이 주요 차이입니다. 다른 구성 요소는 여전히 재시작해야 합니다.

이 프로세스는 Gitaly 샤드 및 클러스터 설정 모두에 적용됩니다. 업그레이드를 수행하기 위해 각 Gitaly 노드에서 다음 단계를 순차적으로 실행합니다:

  1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

    sudo touch /etc/gitlab/skip-auto-reconfigure

  2. Linux 패키지로 업그레이드하여 노드를 업그레이드합니다.

  3. reconfigure 명령을 실행하여 최신 코드를 적용하고 가장 빠른 기회에 Gitaly가 우아하게 리로드하도록 지시합니다:

    sudo gitlab-ctl reconfigure

  4. 마지막으로 Gitaly가 우아하게 리로드되는 동안 배포된 다른 구성 요소도 재시작해야 합니다:

    # Gitaly 외에 배포된 다른 구성 요소 목록 가져오기
sudo gitlab-ctl status

# Gitaly를 제외한 각 구성 요소 재시작. Consul, Node Exporter 및 Logrotate 예시
sudo gitlab-ctl restart consul node-exporter logrotate

Gitaly 클러스터(Praefect) 노드 업그레이드#

Note

이 섹션은 Praefect 구성 요소에만 초점을 맞추며 필수 PostgreSQL 데이터베이스는 포함되지 않습니다. GitLab Linux 패키지는 HA를 지원하지 않으며 따라서 Praefect 데이터베이스에 대한 다운타임 제로 지원도 없습니다. 다운타임을 방지하기 위해 타사 데이터베이스 솔루션이 필요합니다.

Gitaly 클러스터(Praefect) 설정의 경우 우아한 리로드를 사용하여 유사한 방식으로 Praefect를 배포하고 업그레이드해야 합니다.

Note

업그레이드 프로세스는 새 Praefect 프로세스로 우아한 핸드오버를 시도합니다. 업그레이드 전에 시작된 기존의 장시간 실행 Git 요청은 이 핸드오버가 발생하면서 결국 삭제될 수 있습니다. 이 기능은 향후 변경될 수 있습니다. 자세한 내용은 이 에픽을 참조하십시오.

Praefect는 기존 데이터를 업그레이드하기 위해 데이터베이스 마이그레이션도 수행해야 합니다. 충돌을 방지하기 위해 마이그레이션은 하나의 Praefect 노드에서만 실행해야 합니다. 이를 위해 마이그레이션을 실행하는 Praefect 배포 노드를 지정합니다:

  1. Praefect 배포 노드에서:

    1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    2. Linux 패키지로 업그레이드하여 노드를 업그레이드합니다.

    3. 데이터베이스 마이그레이션이 실행되도록 /etc/gitlab/gitlab.rb에 praefect['auto_migrate'] = true가 설정되어 있는지 확인합니다.

    4. reconfigure 명령을 실행하여 최신 코드를 적용하고 Praefect 데이터베이스 마이그레이션을 적용하고 우아하게 재시작합니다:

      sudo gitlab-ctl reconfigure

  2. 나머지 모든 Praefect 노드에서:

    1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    2. Linux 패키지로 업그레이드하여 노드를 업그레이드합니다.

    3. reconfigure가 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 /etc/gitlab/gitlab.rb에 praefect['auto_migrate'] = false가 설정되어 있는지 확인합니다.

    4. reconfigure 명령을 실행하여 최신 코드를 적용하고 우아하게 재시작합니다:

      sudo gitlab-ctl reconfigure

  3. 마지막으로 Praefect가 우아하게 리로드되는 동안 배포된 다른 구성 요소도 재시작해야 합니다. 모든 Praefect 노드에서:

    # Praefect 외에 배포된 다른 구성 요소 목록 가져오기
sudo gitlab-ctl status

# Praefect를 제외한 각 구성 요소 재시작. Consul, Node Exporter 및 Logrotate 예시
sudo gitlab-ctl restart consul node-exporter logrotate

GitLab 애플리케이션(Rails) 노드 업그레이드#

웹 서버로서의 Rails는 주로 Puma, Workhorse 및 NGINX로 구성됩니다.

이러한 구성 요소는 라이브 업그레이드 시 다른 동작을 합니다. Puma는 우아한 리로드를 허용할 수 있지만 Workhorse는 그렇지 않습니다. 가장 좋은 접근 방식은 로드 밸런서를 사용하는 것과 같이 다른 방법으로 노드를 우아하게 드레인하는 것입니다. 또한 노드의 NGINX에서 우아한 종료 기능을 통해 이 작업을 수행할 수도 있습니다. 이 섹션에서는 NGINX 접근 방식을 설명합니다.

이전 내용 외에도 Rails는 기본 데이터베이스 마이그레이션이 실행되어야 하는 곳입니다. Praefect와 마찬가지로 가장 좋은 접근 방식은 배포 노드를 사용하는 것입니다. PgBouncer를 현재 사용 중인 경우 Rails는 마이그레이션을 실행하려고 할 때 동일한 데이터베이스에서 동시 마이그레이션이 실행되지 않도록 권고 잠금을 사용하므로 우회해야 합니다. 이러한 잠금은 트랜잭션 간에 공유되지 않아 트랜잭션 풀링 모드에서 PgBouncer를 사용하여 데이터베이스 마이그레이션을 실행할 때 ActiveRecord::ConcurrentMigrationError 및 기타 이슈가 발생합니다.

  1. Rails 배포 노드에서:

    1. 노드의 트래픽을 우아하게 드레인합니다. 이를 수행하는 다양한 방법이 있지만 하나의 접근 방식은 QUIT 신호를 보내고 서비스를 중지하여 NGINX를 사용하는 것입니다. 예를 들어 다음 쉘 스크립트를 사용하여 이 작업을 수행할 수 있습니다:

      # Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx

    2. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    3. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

    4. /etc/gitlab/gitlab.rb 구성 파일에서 gitlab_rails['auto_migrate'] = true를 설정하여 정규 마이그레이션이 실행되도록 구성합니다.

      • 배포 노드가 데이터베이스에 도달하기 위해 PgBouncer를 통해 가는 경우 마이그레이션을 실행하기 전에 우회하고 데이터베이스 리더에 직접 연결해야 합니다.
      • 데이터베이스 리더를 찾으려면 모든 데이터베이스 노드에서 다음 명령을 실행합니다 - sudo gitlab-ctl patroni members.

    5. 정규 마이그레이션을 실행하고 최신 코드를 적용합니다:

      sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure

    6. 나중에 포스트 배포 마이그레이션을 실행하기 위해 돌아올 때까지 이 노드를 그대로 둡니다.

  2. 다른 모든 Rails 노드에서 순차적으로:

    1. 노드의 트래픽을 우아하게 드레인합니다. 이를 수행하는 다양한 방법이 있지만 하나의 접근 방식은 QUIT 신호를 보내고 서비스를 중지하여 NGINX를 사용하는 것입니다. 예를 들어 다음 쉘 스크립트를 사용하여 이 작업을 수행할 수 있습니다:

      # Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx

    2. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    3. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

    4. reconfigure가 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 /etc/gitlab/gitlab.rb에 gitlab_rails['auto_migrate'] = false가 설정되어 있는지 확인합니다.

    5. reconfigure 명령을 실행하여 최신 코드를 적용하고 재시작합니다:

      sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

  3. Rails 배포 노드에서 포스트 배포 마이그레이션을 실행합니다:

    1. 배포 노드가 여전히 데이터베이스 리더를 직접 가리키고 있는지 확인합니다. 노드가 데이터베이스에 도달하기 위해 PgBouncer를 통해 가는 경우 마이그레이션을 실행하기 전에 우회하고 데이터베이스 리더에 직접 연결해야 합니다.

      • 데이터베이스 리더를 찾으려면 모든 데이터베이스 노드에서 다음 명령을 실행합니다 - sudo gitlab-ctl patroni members.

    2. 포스트 배포 마이그레이션을 실행합니다:

      sudo gitlab-rake gitlab:db:configure

      이 작업은 ClickHouse 마이그레이션도 실행하고 스키마를 로드하여 상태에 따라 데이터베이스를 구성합니다.

    3. /etc/gitlab/gitlab.rb 구성 파일에서 gitlab_rails['auto_migrate'] = false를 설정하여 구성을 정상으로 되돌립니다.

      • PgBouncer를 사용 중인 경우 데이터베이스 구성이 다시 PgBouncer를 가리키도록 설정되어 있는지 확인합니다.

    4. 정상 구성을 다시 적용하고 재시작하기 위해 reconfigure를 다시 실행합니다:

      sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Sidekiq 노드 업그레이드#

Sidekiq은 다운타임 없이 업그레이드하기 위해 다른 구성 요소와 동일한 기본 프로세스를 따릅니다.

업그레이드를 수행하기 위해 각 구성 요소 노드에서 다음 단계를 순차적으로 실행합니다:

  1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

    sudo touch /etc/gitlab/skip-auto-reconfigure

  2. Linux 패키지로 업그레이드하여 노드를 업그레이드합니다.

  3. reconfigure 명령을 실행하여 최신 코드를 적용하고 재시작합니다:

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

다중 노드 Geo 인스턴스 업그레이드#

이 섹션에서는 Geo를 사용하여 라이브 GitLab 환경 배포를 업그레이드하는 데 필요한 단계를 설명합니다.

전반적으로 접근 방식은 각 보조 사이트에 필요한 추가 단계가 있다는 점에서 정상 프로세스와 거의 동일합니다. 필수 순서는 먼저 기본 사이트를 업그레이드한 다음 보조 사이트를 업그레이드하는 것입니다. 또한 모든 보조 사이트가 업데이트된 후 기본 사이트에서 포스트 배포 마이그레이션을 실행해야 합니다.

Note

동일한 요구 사항과 고려 사항이 Geo가 있는 라이브 GitLab 환경 업그레이드에도 적용됩니다.

기본 사이트#

기본 사이트의 업그레이드 프로세스는 포스트 배포 마이그레이션을 모든 보조 사이트가 업데이트될 때까지 실행하지 않는다는 한 가지 예외를 제외하면 정상 프로세스와 동일합니다.

포스트 배포 마이그레이션을 실행하는 Rails 노드 단계에서 중지하되 설명된 것과 동일한 단계를 기본 사이트에서 실행합니다.

보조 사이트#

보조 사이트의 업그레이드 프로세스는 Rails 노드를 제외하고 정상 프로세스와 동일한 단계를 따릅니다. 업그레이드 프로세스는 기본 및 보조 사이트 모두 동일합니다. 그러나 보조 사이트의 Rails 노드에 대해 다음 추가 단계를 수행해야 합니다.

Rails#

  1. Rails 배포 노드에서:

    1. 노드의 트래픽을 우아하게 드레인합니다. 이를 수행하는 다양한 방법이 있지만 하나의 접근 방식은 QUIT 신호를 보내고 서비스를 중지하여 NGINX를 사용하는 것입니다. 예를 들어 다음 쉘 스크립트를 사용하여 이 작업을 수행할 수 있습니다:

      # Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx

    2. 다른 노드로 페일오버가 되도록 Geo Log Cursor 프로세스를 중지합니다:

      gitlab-ctl stop geo-logcursor

    3. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    4. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

    5. /etc/gitlab/gitlab-secrets.json 파일을 기본 사이트 Rails 노드에서 보조 사이트 Rails 노드로 복사합니다(다른 경우). 파일은 사이트의 모든 노드에서 동일해야 합니다.

    6. /etc/gitlab/gitlab.rb 구성 파일에서 gitlab_rails['auto_migrate'] = false 및 geo_secondary['auto_migrate'] = false를 설정하여 마이그레이션이 자동으로 실행되도록 구성되지 않도록 합니다.

    7. reconfigure 명령을 실행하여 최신 코드를 적용하고 재시작합니다:

      sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

    8. 정규 Geo 추적 마이그레이션을 실행하고 최신 코드를 적용합니다:

      sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate:geo

  2. 다른 모든 Rails 노드에서 순차적으로:

    1. 노드의 트래픽을 우아하게 드레인합니다. 이를 수행하는 다양한 방법이 있지만 하나의 접근 방식은 QUIT 신호를 보내고 서비스를 중지하여 NGINX를 사용하는 것입니다. 예를 들어 다음 쉘 스크립트를 사용하여 이 작업을 수행할 수 있습니다:

      # Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx

    2. 다른 노드로 페일오버가 되도록 Geo Log Cursor 프로세스를 중지합니다:

      gitlab-ctl stop geo-logcursor

    3. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    4. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

    5. /etc/gitlab/gitlab.rb 구성 파일에서 gitlab_rails['auto_migrate'] = false 및 geo_secondary['auto_migrate'] = false를 설정하여 마이그레이션이 자동으로 실행되도록 구성되지 않도록 합니다.

    6. reconfigure 명령을 실행하여 최신 코드를 적용하고 재시작합니다:

      sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Sidekiq#

메인 프로세스 이후 남은 것은 Sidekiq를 업그레이드하는 것뿐입니다.

메인 섹션에 설명된 것과 동일한 방식으로 Sidekiq를 업그레이드합니다.

포스트 배포 마이그레이션#

마지막으로 기본 사이트로 돌아가 포스트 배포 마이그레이션을 실행하여 업그레이드를 완료합니다:

  1. 기본 사이트의 Rails 배포 노드에서 포스트 배포 마이그레이션을 실행합니다:

    1. 배포 노드가 여전히 데이터베이스 리더를 직접 가리키고 있는지 확인합니다. 노드가 데이터베이스에 도달하기 위해 PgBouncer를 통해 가는 경우 마이그레이션을 실행하기 전에 우회하고 데이터베이스 리더에 직접 연결해야 합니다.

      • 데이터베이스 리더를 찾으려면 모든 데이터베이스 노드에서 다음 명령을 실행합니다 - sudo gitlab-ctl patroni members.

    2. 포스트 배포 마이그레이션을 실행합니다:

      sudo gitlab-rake gitlab:db:configure

    3. Geo 구성 및 종속성을 확인합니다:

      sudo gitlab-rake gitlab:geo:check

    4. /etc/gitlab/gitlab.rb 구성 파일에서 gitlab_rails['auto_migrate'] = false를 설정하여 구성을 정상으로 되돌립니다.

      • PgBouncer를 사용 중인 경우 데이터베이스 구성이 다시 PgBouncer를 가리키도록 설정되어 있는지 확인합니다.

    5. 정상 구성을 다시 적용하고 재시작하기 위해 reconfigure를 다시 실행합니다:

      sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

  2. 보조 사이트의 Rails 배포 노드에서 포스트 배포 Geo 추적 마이그레이션을 실행합니다:

    1. 포스트 배포 Geo 추적 마이그레이션을 실행합니다:

      sudo gitlab-rake db:migrate:geo

    2. Geo 상태를 확인합니다:

      sudo gitlab-rake geo:status

다운타임 없이 다중 노드 인스턴스 업그레이드

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

다운타임 없이 다중 노드 GitLab 환경을 업그레이드하는 프로세스는 업그레이드 순서에 따라 각 노드를 순차적으로 처리하는 것을 포함합니다. 다운타임 없이 업그레이드를 시작하기 전에 다운타임 옵션을 고려하십시오. 업그레이드의 일부로 다운타임 제로를 달성하는 것은 분산 애플리케이션에서 특히 어렵습니다.

다운타임 없이 다중 노드 GitLab 환경을 업그레이드하는 프로세스는 업그레이드 순서에 따라 각 노드를 순차적으로 처리하는 것을 포함합니다. 로드 밸런서 및 HA 메커니즘은 각 노드가 다운되는 상황을 적절히 처리합니다.

다운타임 없이 업그레이드를 시작하기 전에 다운타임 옵션을 고려하십시오.

시작하기 전에#

업그레이드의 일부로 다운타임 제로를 달성하는 것은 분산 애플리케이션에서 특히 어렵습니다. 문서는 HA 참조 아키텍처에 대해 테스트되었으며 사실상 관측 가능한 다운타임이 없었습니다. 그러나 특정 시스템 구성에 따라 결과가 다를 수 있음을 알고 있으십시오.

추가적인 확신을 위해 일부 고객은 특정 로드 밸런서 또는 인프라 기능을 사용하여 노드를 수동으로 드레인하는 것과 같은 추가 기술을 성공적으로 사용했습니다. 이러한 기술은 기본 인프라 기능에 크게 의존합니다.

추가 정보는 GitLab 담당자 또는 지원팀에 문의하십시오.

요구 사항#

다운타임 제로 업그레이드 프로세스는 다음과 같이 구성된 로드 밸런싱 및 사용 가능한 HA 메커니즘이 있는 Linux 패키지로 구축된 다중 노드 GitLab 환경이 필요합니다:

  • readiness (/-/readiness) 엔드포인트에 대한 상태 확인이 활성화된 GitLab 애플리케이션 노드를 위한 외부 로드 밸런서.
  • TCP 상태 확인이 활성화된 PgBouncer 및 Praefect 구성 요소를 위한 내부 로드 밸런서.
  • 존재하는 경우 Consul, Postgres 및 Redis 구성 요소를 위해 구성된 HA 메커니즘.

다운타임 제로 업그레이드를 위해서는 다음을 수행해야 합니다:

고려 사항#

다운타임 제로 업그레이드를 고려할 때 다음을 알고 있으십시오:

  • 대부분의 경우 패치 릴리스가 최신 버전이 아닌 경우 패치 릴리스에서 다음 마이너 릴리스로 안전하게 업그레이드할 수 있습니다. 예를 들어 16.3.3이 릴리스된 경우에도 16.3.2에서 16.4.1로 업그레이드하는 것이 안전합니다. 업그레이드 경로와 관련된 버전별 업그레이드 노트를 확인하고 필수 업그레이드 중지 지점을 알고 있어야 합니다:

  • 일부 릴리스에는 백그라운드 마이그레이션이 포함될 수 있습니다. 이러한 마이그레이션은 Sidekiq에 의해 백그라운드에서 수행되며 종종 데이터를 마이그레이션하는 데 사용됩니다. 백그라운드 마이그레이션은 월간 릴리스에만 추가됩니다.

    • 특정 주요 또는 마이너 릴리스에서는 백그라운드 마이그레이션 세트가 완료되어야 할 수 있습니다. 이는 다운타임을 필요로 하지 않지만(이전 조건이 충족된 경우), 각 주요 또는 마이너 릴리스 업그레이드 사이에 백그라운드 마이그레이션이 완료될 때까지 기다려야 합니다.
    • 이러한 마이그레이션을 완료하는 데 필요한 시간은 background_migration 큐의 작업을 처리할 수 있는 Sidekiq 작업자 수를 늘려 줄일 수 있습니다. 이 큐의 크기를 보려면 업그레이드 전에 백그라운드 마이그레이션을 확인하십시오.

  • 우아한 리로드 메커니즘으로 인해 Gitaly에 대해 다운타임 제로 업그레이드를 수행할 수 있습니다. Gitaly 클러스터(Praefect) 구성 요소도 다운타임 없이 직접 업그레이드할 수 있습니다. 그러나 Linux 패키지는 Praefect 데이터베이스에 대한 HA 또는 다운타임 제로 지원을 제공하지 않습니다. 다운타임을 방지하기 위해 타사 데이터베이스 솔루션이 필요합니다.

  • PostgreSQL 주요 버전 업그레이드는 별도의 프로세스이며 다운타임 제로 업그레이드에 포함되지 않습니다. 더 작은 업그레이드는 포함됩니다.

  • 다운타임 제로 업그레이드는 Linux 패키지로 배포한 언급된 GitLab 구성 요소에 지원됩니다. AWS RDS의 PostgreSQL 또는 GCP Memorystore의 Redis와 같이 지원되는 타사 서비스를 통해 특정 구성 요소를 배포한 경우 해당 서비스의 업그레이드는 표준 프로세스에 따라 별도로 수행해야 합니다.

  • 일반적인 지침으로 데이터가 많을수록 업그레이드가 완료되는 데 더 많은 시간이 필요합니다. 테스트에서 10GB 미만의 데이터베이스는 일반적으로 1시간 이상 걸리지 않지만 결과가 다를 수 있습니다.

업그레이드 순서#

다운타임 제로로 업그레이드할 구성 요소의 순서로 뒤에서 앞으로 접근 방식을 취해야 합니다:

  1. 상태 저장 백엔드
  2. 백엔드 종속 구성 요소
  3. 프론트엔드

배포 순서를 변경할 수 있지만 GitLab 애플리케이션 코드를 실행하는 구성 요소(예: Rails 및 Sidekiq)를 함께 배포해야 합니다. 가능하면 지원 인프라를 별도로 업그레이드하십시오. 이러한 구성 요소는 주요 릴리스에 대한 버전 업그레이드에서 도입된 변경 사항에 의존성이 없기 때문입니다.

GitLab 구성 요소를 다음 순서로 업그레이드해야 합니다:

  1. Consul
  2. PostgreSQL
  3. PgBouncer
  4. Redis
  5. Gitaly
  6. Praefect
  7. Rails
  8. Sidekiq

Consul, PostgreSQL, PgBouncer 및 Redis 노드 업그레이드#

Consul, PostgreSQL, PgBouncer 및 Redis 구성 요소는 모두 다운타임 없이 업그레이드하는 것과 동일한 기본 프로세스를 따릅니다.

업그레이드를 수행할 각 구성 요소의 노드에서:

  1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

    sudo touch /etc/gitlab/skip-auto-reconfigure

  2. Linux 패키지로 업그레이드하여 노드를 업그레이드합니다.

  3. 재구성하고 재시작하여 최신 코드를 적용합니다:

    sudo gitlab-ctl reconfigure

PostgreSQL 페일오버가 원활하게 발생하도록 Consul 클라이언트를 먼저 재시작한 다음 다른 모든 서비스를 재시작합니다:

sudo gitlab-ctl restart consul
sudo gitlab-ctl restart-except consul

   sudo gitlab-ctl restart

Gitaly 노드 업그레이드#

Gitaly는 업그레이드 시 동일한 핵심 프로세스를 따르지만 가장 빠른 기회에 우아하게 리로드하는 내장 프로세스가 있어 Gitaly 프로세스 자체는 재시작되지 않는다는 점이 주요 차이입니다. 다른 구성 요소는 여전히 재시작해야 합니다.

이 프로세스는 Gitaly 샤드 및 클러스터 설정 모두에 적용됩니다. 업그레이드를 수행하기 위해 각 Gitaly 노드에서 다음 단계를 순차적으로 실행합니다:

  1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

    sudo touch /etc/gitlab/skip-auto-reconfigure

  2. Linux 패키지로 업그레이드하여 노드를 업그레이드합니다.

  3. reconfigure 명령을 실행하여 최신 코드를 적용하고 가장 빠른 기회에 Gitaly가 우아하게 리로드하도록 지시합니다:

    sudo gitlab-ctl reconfigure

  4. 마지막으로 Gitaly가 우아하게 리로드되는 동안 배포된 다른 구성 요소도 재시작해야 합니다:

    # Gitaly 외에 배포된 다른 구성 요소 목록 가져오기
sudo gitlab-ctl status

# Gitaly를 제외한 각 구성 요소 재시작. Consul, Node Exporter 및 Logrotate 예시
sudo gitlab-ctl restart consul node-exporter logrotate

Gitaly 클러스터(Praefect) 노드 업그레이드#

Note

이 섹션은 Praefect 구성 요소에만 초점을 맞추며 필수 PostgreSQL 데이터베이스는 포함되지 않습니다. GitLab Linux 패키지는 HA를 지원하지 않으며 따라서 Praefect 데이터베이스에 대한 다운타임 제로 지원도 없습니다. 다운타임을 방지하기 위해 타사 데이터베이스 솔루션이 필요합니다.

Gitaly 클러스터(Praefect) 설정의 경우 우아한 리로드를 사용하여 유사한 방식으로 Praefect를 배포하고 업그레이드해야 합니다.

Note

업그레이드 프로세스는 새 Praefect 프로세스로 우아한 핸드오버를 시도합니다. 업그레이드 전에 시작된 기존의 장시간 실행 Git 요청은 이 핸드오버가 발생하면서 결국 삭제될 수 있습니다. 이 기능은 향후 변경될 수 있습니다. 자세한 내용은 이 에픽을 참조하십시오.

Praefect는 기존 데이터를 업그레이드하기 위해 데이터베이스 마이그레이션도 수행해야 합니다. 충돌을 방지하기 위해 마이그레이션은 하나의 Praefect 노드에서만 실행해야 합니다. 이를 위해 마이그레이션을 실행하는 Praefect 배포 노드를 지정합니다:

  1. Praefect 배포 노드에서:

    1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    2. Linux 패키지로 업그레이드하여 노드를 업그레이드합니다.

    3. 데이터베이스 마이그레이션이 실행되도록 /etc/gitlab/gitlab.rb에 praefect['auto_migrate'] = true가 설정되어 있는지 확인합니다.

    4. reconfigure 명령을 실행하여 최신 코드를 적용하고 Praefect 데이터베이스 마이그레이션을 적용하고 우아하게 재시작합니다:

      sudo gitlab-ctl reconfigure

  2. 나머지 모든 Praefect 노드에서:

    1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    2. Linux 패키지로 업그레이드하여 노드를 업그레이드합니다.

    3. reconfigure가 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 /etc/gitlab/gitlab.rb에 praefect['auto_migrate'] = false가 설정되어 있는지 확인합니다.

    4. reconfigure 명령을 실행하여 최신 코드를 적용하고 우아하게 재시작합니다:

      sudo gitlab-ctl reconfigure

  3. 마지막으로 Praefect가 우아하게 리로드되는 동안 배포된 다른 구성 요소도 재시작해야 합니다. 모든 Praefect 노드에서:

    # Praefect 외에 배포된 다른 구성 요소 목록 가져오기
sudo gitlab-ctl status

# Praefect를 제외한 각 구성 요소 재시작. Consul, Node Exporter 및 Logrotate 예시
sudo gitlab-ctl restart consul node-exporter logrotate

GitLab 애플리케이션(Rails) 노드 업그레이드#

웹 서버로서의 Rails는 주로 Puma, Workhorse 및 NGINX로 구성됩니다.

이러한 구성 요소는 라이브 업그레이드 시 다른 동작을 합니다. Puma는 우아한 리로드를 허용할 수 있지만 Workhorse는 그렇지 않습니다. 가장 좋은 접근 방식은 로드 밸런서를 사용하는 것과 같이 다른 방법으로 노드를 우아하게 드레인하는 것입니다. 또한 노드의 NGINX에서 우아한 종료 기능을 통해 이 작업을 수행할 수도 있습니다. 이 섹션에서는 NGINX 접근 방식을 설명합니다.

이전 내용 외에도 Rails는 기본 데이터베이스 마이그레이션이 실행되어야 하는 곳입니다. Praefect와 마찬가지로 가장 좋은 접근 방식은 배포 노드를 사용하는 것입니다. PgBouncer를 현재 사용 중인 경우 Rails는 마이그레이션을 실행하려고 할 때 동일한 데이터베이스에서 동시 마이그레이션이 실행되지 않도록 권고 잠금을 사용하므로 우회해야 합니다. 이러한 잠금은 트랜잭션 간에 공유되지 않아 트랜잭션 풀링 모드에서 PgBouncer를 사용하여 데이터베이스 마이그레이션을 실행할 때 ActiveRecord::ConcurrentMigrationError 및 기타 이슈가 발생합니다.

  1. Rails 배포 노드에서:

    1. 노드의 트래픽을 우아하게 드레인합니다. 이를 수행하는 다양한 방법이 있지만 하나의 접근 방식은 QUIT 신호를 보내고 서비스를 중지하여 NGINX를 사용하는 것입니다. 예를 들어 다음 쉘 스크립트를 사용하여 이 작업을 수행할 수 있습니다:

      # Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx

    2. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    3. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

    4. /etc/gitlab/gitlab.rb 구성 파일에서 gitlab_rails['auto_migrate'] = true를 설정하여 정규 마이그레이션이 실행되도록 구성합니다.

      • 배포 노드가 데이터베이스에 도달하기 위해 PgBouncer를 통해 가는 경우 마이그레이션을 실행하기 전에 우회하고 데이터베이스 리더에 직접 연결해야 합니다.
      • 데이터베이스 리더를 찾으려면 모든 데이터베이스 노드에서 다음 명령을 실행합니다 - sudo gitlab-ctl patroni members.

    5. 정규 마이그레이션을 실행하고 최신 코드를 적용합니다:

      sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure

    6. 나중에 포스트 배포 마이그레이션을 실행하기 위해 돌아올 때까지 이 노드를 그대로 둡니다.

  2. 다른 모든 Rails 노드에서 순차적으로:

    1. 노드의 트래픽을 우아하게 드레인합니다. 이를 수행하는 다양한 방법이 있지만 하나의 접근 방식은 QUIT 신호를 보내고 서비스를 중지하여 NGINX를 사용하는 것입니다. 예를 들어 다음 쉘 스크립트를 사용하여 이 작업을 수행할 수 있습니다:

      # Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx

    2. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    3. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

    4. reconfigure가 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 /etc/gitlab/gitlab.rb에 gitlab_rails['auto_migrate'] = false가 설정되어 있는지 확인합니다.

    5. reconfigure 명령을 실행하여 최신 코드를 적용하고 재시작합니다:

      sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

  3. Rails 배포 노드에서 포스트 배포 마이그레이션을 실행합니다:

    1. 배포 노드가 여전히 데이터베이스 리더를 직접 가리키고 있는지 확인합니다. 노드가 데이터베이스에 도달하기 위해 PgBouncer를 통해 가는 경우 마이그레이션을 실행하기 전에 우회하고 데이터베이스 리더에 직접 연결해야 합니다.

      • 데이터베이스 리더를 찾으려면 모든 데이터베이스 노드에서 다음 명령을 실행합니다 - sudo gitlab-ctl patroni members.

    2. 포스트 배포 마이그레이션을 실행합니다:

      sudo gitlab-rake gitlab:db:configure

      이 작업은 ClickHouse 마이그레이션도 실행하고 스키마를 로드하여 상태에 따라 데이터베이스를 구성합니다.

    3. /etc/gitlab/gitlab.rb 구성 파일에서 gitlab_rails['auto_migrate'] = false를 설정하여 구성을 정상으로 되돌립니다.

      • PgBouncer를 사용 중인 경우 데이터베이스 구성이 다시 PgBouncer를 가리키도록 설정되어 있는지 확인합니다.

    4. 정상 구성을 다시 적용하고 재시작하기 위해 reconfigure를 다시 실행합니다:

      sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Sidekiq 노드 업그레이드#

Sidekiq은 다운타임 없이 업그레이드하기 위해 다른 구성 요소와 동일한 기본 프로세스를 따릅니다.

업그레이드를 수행하기 위해 각 구성 요소 노드에서 다음 단계를 순차적으로 실행합니다:

  1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

    sudo touch /etc/gitlab/skip-auto-reconfigure

  2. Linux 패키지로 업그레이드하여 노드를 업그레이드합니다.

  3. reconfigure 명령을 실행하여 최신 코드를 적용하고 재시작합니다:

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

다중 노드 Geo 인스턴스 업그레이드#

이 섹션에서는 Geo를 사용하여 라이브 GitLab 환경 배포를 업그레이드하는 데 필요한 단계를 설명합니다.

전반적으로 접근 방식은 각 보조 사이트에 필요한 추가 단계가 있다는 점에서 정상 프로세스와 거의 동일합니다. 필수 순서는 먼저 기본 사이트를 업그레이드한 다음 보조 사이트를 업그레이드하는 것입니다. 또한 모든 보조 사이트가 업데이트된 후 기본 사이트에서 포스트 배포 마이그레이션을 실행해야 합니다.

Note

동일한 요구 사항과 고려 사항이 Geo가 있는 라이브 GitLab 환경 업그레이드에도 적용됩니다.

기본 사이트#

기본 사이트의 업그레이드 프로세스는 포스트 배포 마이그레이션을 모든 보조 사이트가 업데이트될 때까지 실행하지 않는다는 한 가지 예외를 제외하면 정상 프로세스와 동일합니다.

포스트 배포 마이그레이션을 실행하는 Rails 노드 단계에서 중지하되 설명된 것과 동일한 단계를 기본 사이트에서 실행합니다.

보조 사이트#

보조 사이트의 업그레이드 프로세스는 Rails 노드를 제외하고 정상 프로세스와 동일한 단계를 따릅니다. 업그레이드 프로세스는 기본 및 보조 사이트 모두 동일합니다. 그러나 보조 사이트의 Rails 노드에 대해 다음 추가 단계를 수행해야 합니다.

Rails#

  1. Rails 배포 노드에서:

    1. 노드의 트래픽을 우아하게 드레인합니다. 이를 수행하는 다양한 방법이 있지만 하나의 접근 방식은 QUIT 신호를 보내고 서비스를 중지하여 NGINX를 사용하는 것입니다. 예를 들어 다음 쉘 스크립트를 사용하여 이 작업을 수행할 수 있습니다:

      # Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx

    2. 다른 노드로 페일오버가 되도록 Geo Log Cursor 프로세스를 중지합니다:

      gitlab-ctl stop geo-logcursor

    3. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    4. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

    5. /etc/gitlab/gitlab-secrets.json 파일을 기본 사이트 Rails 노드에서 보조 사이트 Rails 노드로 복사합니다(다른 경우). 파일은 사이트의 모든 노드에서 동일해야 합니다.

    6. /etc/gitlab/gitlab.rb 구성 파일에서 gitlab_rails['auto_migrate'] = false 및 geo_secondary['auto_migrate'] = false를 설정하여 마이그레이션이 자동으로 실행되도록 구성되지 않도록 합니다.

    7. reconfigure 명령을 실행하여 최신 코드를 적용하고 재시작합니다:

      sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

    8. 정규 Geo 추적 마이그레이션을 실행하고 최신 코드를 적용합니다:

      sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate:geo

  2. 다른 모든 Rails 노드에서 순차적으로:

    1. 노드의 트래픽을 우아하게 드레인합니다. 이를 수행하는 다양한 방법이 있지만 하나의 접근 방식은 QUIT 신호를 보내고 서비스를 중지하여 NGINX를 사용하는 것입니다. 예를 들어 다음 쉘 스크립트를 사용하여 이 작업을 수행할 수 있습니다:

      # Send QUIT to NGINX master process to drain and exit
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID

# Wait for drain to complete
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done

# Stop NGINX service to prevent automatic restarts
gitlab-ctl stop nginx

    2. 다른 노드로 페일오버가 되도록 Geo Log Cursor 프로세스를 중지합니다:

      gitlab-ctl stop geo-logcursor

    3. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl reconfigure를 실행하지 않습니다. gitlab-ctl reconfigure는 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다:

      sudo touch /etc/gitlab/skip-auto-reconfigure

    4. Linux 패키지로 업그레이드하여 GitLab을 업그레이드합니다.

    5. /etc/gitlab/gitlab.rb 구성 파일에서 gitlab_rails['auto_migrate'] = false 및 geo_secondary['auto_migrate'] = false를 설정하여 마이그레이션이 자동으로 실행되도록 구성되지 않도록 합니다.

    6. reconfigure 명령을 실행하여 최신 코드를 적용하고 재시작합니다:

      sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Sidekiq#

메인 프로세스 이후 남은 것은 Sidekiq를 업그레이드하는 것뿐입니다.

메인 섹션에 설명된 것과 동일한 방식으로 Sidekiq를 업그레이드합니다.

포스트 배포 마이그레이션#

마지막으로 기본 사이트로 돌아가 포스트 배포 마이그레이션을 실행하여 업그레이드를 완료합니다:

  1. 기본 사이트의 Rails 배포 노드에서 포스트 배포 마이그레이션을 실행합니다:

    1. 배포 노드가 여전히 데이터베이스 리더를 직접 가리키고 있는지 확인합니다. 노드가 데이터베이스에 도달하기 위해 PgBouncer를 통해 가는 경우 마이그레이션을 실행하기 전에 우회하고 데이터베이스 리더에 직접 연결해야 합니다.

      • 데이터베이스 리더를 찾으려면 모든 데이터베이스 노드에서 다음 명령을 실행합니다 - sudo gitlab-ctl patroni members.

    2. 포스트 배포 마이그레이션을 실행합니다:

      sudo gitlab-rake gitlab:db:configure

    3. Geo 구성 및 종속성을 확인합니다:

      sudo gitlab-rake gitlab:geo:check

    4. /etc/gitlab/gitlab.rb 구성 파일에서 gitlab_rails['auto_migrate'] = false를 설정하여 구성을 정상으로 되돌립니다.

      • PgBouncer를 사용 중인 경우 데이터베이스 구성이 다시 PgBouncer를 가리키도록 설정되어 있는지 확인합니다.

    5. 정상 구성을 다시 적용하고 재시작하기 위해 reconfigure를 다시 실행합니다:

      sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

  2. 보조 사이트의 Rails 배포 노드에서 포스트 배포 Geo 추적 마이그레이션을 실행합니다:

    1. 포스트 배포 Geo 추적 마이그레이션을 실행합니다:

      sudo gitlab-rake db:migrate:geo

    2. Geo 상태를 확인합니다:

      sudo gitlab-rake geo:status