제로 다운타임 업그레이드

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

제로 다운타임 업그레이드를 통해 GitLab 환경을 중지시키지 않고 라이브 GitLab 환경을 업그레이드할 수 있습니다. 이 안내서에서는 이러한 업그레이드의 핵심 프로세스를 안내합니다.

고수준에서, 이 프로세스는 일정한 순서로 GitLab 노드를 순차적으로 업그레이드하여 중단을 최소화하기 위해 로드 밸런싱, 고가용성 시스템 및 우아한 리로딩을 활용합니다.

이 안내서의 목적은 적용 가능한 경우에만 핵심 GitLab 컴포넌트와 관련이 있습니다. AWS RDS와 같은 타사 서비스의 업그레이드나 관리와 같은 경우에는 각각의 설명서를 참조하시기 바랍니다.

시작하기 전에

업그레이드의 일환으로 진정한 제로 다운타임을 달성하는 것은 분산 애플리케이션에 대해 주목할 만한 어려운 작업입니다. 이 안내서에 설명된 프로세스는 저희의 HA 참조 아키텍처에 대한 테스트를 통해 주요 시스템에 실질적인 다운타임이 없음이 확인되었지만, 특정 시스템 구성에 따라 결과가 달라질 수 있음을 인지하십시오.

추가적인 신뢰를 얻기 위해 일부 고객들은 특정 로드 밸런서나 인프라 기능을 통해 노드를 매뉴얼으로 드레인하는 등 추가 기법을 성공적으로 시도한 경우가 있습니다. 이러한 기법은 기본 인프라 기능에 크게 의존하므로 이러한 내용은 이 안내서에서 다루지 않습니다. 추가 정보가 필요한 경우 GitLab 담당자나 지원팀에 문의하십시오.

요구사항 및 고려 사항

제로 다운타임 업그레이드 프로세스에는 다음과 같은 요구 사항이 있습니다:

  • 리눅스 패키지로 구성된 멀티 노드 GitLab 환경에서만 지원됩니다.
    • Rails 노드용으로 활성화된 외부 로드 밸런서는 준비 상태(/-/readiness) 엔드포인트에 대한 활성화된 상태 체크이 구성되어 있어야 합니다.
    • PgBouncer 및 Praefect 컴포넌트용으로 활성화된 TCP 상태 체크이 구성된 내부 로드 밸런서가 있어야 합니다.
    • HA 메커니즘이 Consul, Postgres 및 Redis 컴포넌트에 구성되어 있어야 합니다.
      • HA 방식으로 배포되지 않은 이러한 컴포넌트 중 하나는 별도로 다운타임을 사용하여 업그레이드해야 합니다.
  • 마이너 릴리스마다 하나씩만 업그레이드할 수 있습니다. 16.1에서 16.2로 업그레이드할 수 있지만, 16.3으로는 업그레이드할 수 없습니다. 릴리스를 건너뛰면 데이터베이스 수정이 잘못된 순서로 실행될 수 있으며 데이터베이스 스키마가 깨진 상태로 남을 수 있습니다.
  • 포스트-배포 마이그레이션을 사용해야 합니다.
  • GitLab 차트에서는 제로 다운타임 업그레이드를 지원하지 않습니다. 따라서 이 유형의 업그레이드는 클라우드 네이티브 하이브리드 환경에서 사용할 수 없습니다.

위 사항에 더해 다음 사항에 유의하십시오:

  • 대부분의 경우, 최신 패치 릴리스가 아닌 경우 패치 릴리스에서 다음 마이너 릴리스로 안전하게 업그레이드할 수 있습니다. 예를 들어, 16.3.2에서 16.4.1로 업그레이드하는 것은 16.3.3이 출시된 경우에도 안전합니다. 릴리즈별 업그레이드 안내서를 확인하고 업그레이드 경로 및 필요한 업그레이드 중지 사항을 인지해야 합니다.
  • 일부 릴리스에는 백그라운드 마이그레이션이 포함될 수 있습니다. 이러한 마이그레이션은 백그라운드에서 Sidekiq에 의해 수행되며 데이터 이동에 사용됩니다. 백그라운드 마이그레이션은 매월 릴리스에만 추가됩니다.
    • 특정한 주요 또는 마이너 릴리스의 경우 일련의 백그라운드 마이그레이션이 완료되어야 합니다. (위의 조건을 충족한다면) 이는 다운타임을 필요로 하지는 않지만, 매 이전 주요 또는 마이너 릴리스 업그레이드 사이에서 백그라운드 마이그레이션 완료를 기다려야 합니다.
    • 이러한 마이그레이션을 완료하는 데 필요한 시간은 background_migration 큐에서 작업을 처리할 수 있는 Sidekiq 워커 수를 증가시킴으로써 줄일 수 있습니다. 업그레이드 전에 백그라운드 마이그레이션 확인하여 이 큐의 크기를 확인하십시오.
  • PostgreSQL 주요 버전 업그레이드는 별도의 프로세스이며 제로 다운타임 업그레이드로 처리되지 않습니다 (작은 업그레이드는 처리됨).
  • 제로 다운타임 업그레이드는 GitLab Linux 패키지를 사용하여 배포한 모든 GitLab 컴포넌트에서 지원됩니다. 지원되는 타사 서비스를 통해 일부 컴포넌트를 배포한 경우, 해당 서비스의 표준 프로세스에 따라 해당 서비스의 업그레이드를 별도로 수행해야 합니다.
  • 일반적인 지침으로 데이터가 많을수록 업그레이드하는 데 걸리는 시간도 길어질 것입니다. 테스트 결과, 10GB 미만의 데이터베이스는 일반적으로 1시간 이상 소요되지 않지만, 개별 상황에 따라 달라질 수 있습니다.
note
변경 사항을 변경하고 싶다면 다운타임이 필요한 업그레이드를 대신 고려해보시기 바랍니다.

업그레이드 순서

제로 다운타임 업그레이드를 위한 컴포넌트 업그레이드 순서에 대해 “뒤로 앞으로” 방식을 권장합니다. 일반적으로 상태 유지(Stateful)형 백엔드를 먼저, 그 이후에 그에 종속된 컴포넌트, 그리고 마지막으로 프론트엔드를 업그레이드하는 것이 좋습니다. 배포 순서는 변경할 수 있지만, 가능하다면 GitLab 애플리케이션 코드가 실행되는 컴포넌트(Rails, Sidekiq)를 함께 배포하는 것이 좋습니다. 가능한 경우, 지원 인프라(포스트그레스, PgBouncer, 콘설, Gitaly, Praefect, 레디스)를 따로 업그레이드하고, 이러한 컴포넌트는 주요 릴리스 내의 버전 업데이트에 대한 의존성이 없기 때문입니다. 따라서 일반적으로 다음과 같은 순서를 권장합니다:

  1. 콘설
  2. 포스트그레스
  3. PgBouncer
  4. 레디스
  5. Gitaly
  6. Praefect
  7. Rails
  8. Sidekiq

멀티 노드/HA 배포

본 섹션에서는 업그레이드 순서 및 로드 밸런서/HA 메커니즘이 각 노드가 순차적으로 다운될 때 처리되는 방식을 통해 멀티 노드 GitLab 환경의 핵심 프로세스를 업그레이드합니다.

이 안내서의 목적은 리눅스 패키지로 빌드된 200 RPS 또는 10,000 참조 아키텍처를 업그레이드하는 것입니다.

콘설, 포스트그레스, PgBouncer 및 레디스

콘설, 포스트그레스, PgBouncer 및 레디스 컴포넌트는 모두 다운타임 없이 업그레이드하는 데 동일한 기본적인 프로세스를 따릅니다.

다음 단계를 각 컴포넌트 노드마다 순차적으로 실행하여 업그레이드를 수행합니다:

  1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 만듭니다. 이렇게 함으로써 기본적으로 GitLab을 중지하고 모든 데이터베이스 마이그레이션을 실행한 후 GitLab을 다시 시작시키는 gitlab-ctl reconfigure를 업그레이드에서 실행하지 못하게 합니다. 

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

  2. GitLab 패키지를 업그레이드합니다.

  3. 최신 코드를 적용하고 Gitaly이 다음 기회에 우아하게 리로드하도록 하기 위해 다시 구성하고 다시 시작합니다: 

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Gitaly

Gitaly은 업그레이드 시마다 핵심적인 프로세스를 따르지만, Gitaly 프로세스 자체가 우아하게 리로드되므로 별도의 프로세스가 다시 시작되지는 않는다는 점이 차이점입니다. 기존에 시작된 오랜 지속 시간의 Git 요청은 리로드가 발생하는 동안 최종적으로 드롭되기도 합니다. 추후 이 기능이 변경될 수 있습니다. 자세한 내용은 이 Epic을 참조하십시오.

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

  1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 만듭니다. 이렇게 함으로써 기본적으로 GitLab을 중지하고 모든 데이터베이스 마이그레이션을 실행한 후 GitLab을 다시 시작시키는 gitlab-ctl reconfigure를 업그레이드에서 실행하지 못하게 합니다. 

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

  2. GitLab 패키지를 업그레이드합니다.

  3. 최신 코드를 적용하고 Gitaly이 가능한 최초의 기회에 우아하게 리로드하도록 지시하기 위해 reconfigure 명령을 실행합니다: 

    sudo gitlab-ctl reconfigure

  4. 마지막으로, Gitaly이 사용하고 있는 다른 컴포넌트를 우아하게 리로드하지만, 여전히 재시작해야 합니다: 

    # Gitaly 이외의 각 컴포넌트의 디렉터리 가져오기. Consul, Node Exporter 및 Logrotate의 예시
sudo gitlab-ctl status
   
# Consul, Node Exporter 및 Logrotate의 예시를 들어 각 컴포넌트 재시작
sudo gitlab-ctl restart consul node-exporter logrotate

Praefect

Gitaly 클러스터 설정의 경우, Praefect가 배포되어야 하며 우아한 리로드를 통해 업그레이드해야 합니다.

note
업그레이드 프로세스는 새로운 Praefect 프로세스로의 우아한 이전을 시도합니다. 업그레이드 전에 시작된 기존 장기 실행 Git 요청은 이 전환이 발생하는 동안 최종적으로 삭제될 수 있습니다. 나중에 이 기능이 변경될 수 있으며, 자세한 정보는 이 Epic를 참조하십시오.

그러나 Praefect에 대한 추가 단계는 해당 데이터를 업그레이드하기 위해 데이터베이스 마이그레이션을 실행해야 한다는 것입니다. 충돌을 피하기 위해 마이그레이션은 하나의 Praefect 노드에서만 실행해야 합니다. 이는 하나의 노드를 배포 노드로 선택하여 수행하는 것이 가장 좋습니다. 아래에서 Praefect 배포 노드로 참조하겠습니다:

  1. Praefect 배포 노드에서:

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

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

    2. GitLab 패키지를 업그레이드합니다.

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

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

      sudo gitlab-ctl reconfigure

  2. 나머지 Praefect 노드에서:

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

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

    2. GitLab 패키지를 업그레이드합니다.

    3. /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

Rails

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

이러한 각 컴포넌트는 라이브 업그레이드를 수행하는 경우 다른 동작을 합니다. Puma는 우아한 재로드를 허용할 수 있지만, Workhorse는 그렇지 않습니다. 따라서, 최선의 방법은 로드 밸런서를 통해 노드를 우아하게 비우는 것과 같은 다른 수단을 통해 그라시풀리 끄기입니다. 이는 노드 내에서 NGINX를 통해 우아한 종료 기능을 통해 수행할 수도 있습니다. 이 섹션에서는 NGINX 접근 방식을 사용하겠습니다.

위와 같이, Rails는 주 데이터베이스 마이그레이션을 실행해야 하는 곳입니다. Praefect와 마찬가지로, 이 작업은 배포 노드 접근 방식을 통해 가장 잘 수행됩니다. 현재 PgBouncer가 사용 중이라면, 동일한 데이터베이스에서 동시에 마이그레이션을 실행하지 못하도록 방지하기 위해 PgBouncer를 우회해야 하며, 트랜잭션 풀링 모드에서 PgBouncer를 사용하여 데이터베이스 마이그레이션을 실행할 때 ActiveRecord::ConcurrentMigrationError와 같은 문제 발생을 방지하기 위해 Rails에서 게시된 잠금을 사용합니다. 이러한 잠금은 트랜잭션 간에 공유되지 않으므로, ActiveRecord::ConcurrentMigrationError 및 다른 문제가 발생합니다.

  1. Rails 배포 노드에서:

    1. 노드를 우아하게 트래픽에서 비우세요. 다양한 방법으로 수행할 수 있지만, NGINX를 통해 QUIT 시그널을 보내고 서비스를 중지하는 것이 하나의 방법입니다. 다음은 해당 쉘 스크립트로 수행될 수 있습니다: 

      # NGINX 마스터 프로세스에게 드레인 및 종료 신호 보내기
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID
 
# 드레인이 완료될 때까지 기다리기
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done
 
# 자동 재시작을 방지하기 위해 NGINX 서비스 중지
gitlab-ctl stop nginx

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

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

    3. 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. 노드를 우아하게 트래픽에서 비우세요. 다양한 방법으로 수행할 수 있지만, NGINX를 통해 QUIT 시그널을 보내고 서비스를 중지하는 것이 하나의 방법입니다. 다음은 해당 쉘 스크립트로 수행될 수 있습니다: 

      # NGINX 마스터 프로세스에게 드레인 및 종료 신호 보내기
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID
 
# 드레인이 완료될 때까지 기다리기
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done
 
# 자동 재시작을 방지하기 위해 NGINX 서비스 중지
gitlab-ctl stop nginx

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

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

    3. GitLab 패키지를 업그레이드합니다.

    4. /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 db:migrate
    3. /etc/gitlab/gitlab.rb 설정 파일에서 gitlab_rails['auto_migrate'] = false로 다시 설정하여 정상적으로 구성을 복원합니다.
      • PgBouncer가 사용 중인 경우 데이터베이스 구성을 다시 직접 가리키도록 확인합니다.

    4. 정상 구성을 다시 적용하고 재시작하도록 다시 reconfigure 명령을 실행합니다: 

       sudo gitlab-ctl reconfigure
 sudo gitlab-ctl restart

Sidekiq

Sidekiq는 다른 것과 같은 기본적인 프로세스를 따라 다운타임 없이 업그레이드할 수 있습니다.

다음 단계를 각 컴포넌트 노드에서 순차적으로 실행하여 업그레이드를 수행합니다.

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

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

  2. GitLab 패키지를 업그레이드합니다.

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

    sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Multi-node / HA deployment with Geo

Tier: Premium, Ultimate Offering: Self-Managed

이 섹션에서는 Geo로 구성된 라이브 GitLab 환경을 업그레이드하는 데 필요한 단계에 대해 설명합니다.

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

note
Geo로 구성된 라이브 GitLab 환경을 업그레이드하는 데 동일한 요구 사항 및 고려 사항이 적용됩니다.

기본 사이트

기본 사이트의 업그레이드 프로세스는 후반 배포 마이그레이션을 모든 보조 사이트가 업데이트된 후에야 실행해야 한다는 한 가지 예외를 제외하고는 일반 프로세스와 동일합니다.

기본 사이트에 대해 후반 배포 마이그레이션 단계까지는 동일한 단계를 진행합니다.

보조 사이트

보조 사이트의 업그레이드 프로세스는 일반 프로세스와 (Rails 노드에서) 몇 가지 추가 단계를 따릅니다. 하단에 자세히 설명된 단계에 따라 사이트를 업그레이드하세요.

사이트를 업그레이드하려면 일반 프로세스 단계를 진행한 후에 Rails 노드에 도달한 다음 다음 단계를 따르세요.

Rails

  1. Rails 배포 노드에서:

    1. 노드에서 트래픽을 정상적으로 차단합니다. 여러 방법으로 수행할 수 있지만, NGINX를 통해 QUIT 시그널을 보내고 서비스를 중지하는 방법 중 하나입니다. 다음 셸 스크립트를 통해 이 작업을 수행할 수 있습니다. 

      # NGINX 마스터 프로세스에게 QUIT를 보내서 차단하고 종료
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID
 
# 차단이 완료될 때까지 대기
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done
 
# 자동 재시작을 방지하기 위해 NGINX 서비스 중지
gitlab-ctl stop nginx

    2. 다른 노드로 장애 조치 프로세스를 중지하여 다른 노드로 이전되도록 합니다. 

      gitlab-ctl stop geo-logcursor

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

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

    4. GitLab 패키지를 업그레이드합니다.

    5. 기본 사이트 Rails 노드와 다른 경우 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 보조 사이트 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. 노드에서 트래픽을 정상적으로 차단합니다. 여러 방법으로 수행할 수 있지만, NGINX를 통해 QUIT 시그널을 보내고 서비스를 중지하는 방법 중 하나입니다. 다음 셸 스크립트를 통해 이 작업을 수행할 수 있습니다. 

      # NGINX 마스터 프로세스에게 QUIT를 보내서 차단하고 종료
NGINX_PID=$(cat /var/opt/gitlab/nginx/nginx.pid)
kill -QUIT $NGINX_PID
 
# 차단이 완료될 때까지 대기
while kill -0 $NGINX_PID 2>/dev/null; do sleep 1; done
 
# 자동 재시작을 방지하기 위해 NGINX 서비스 중지
gitlab-ctl stop nginx

    2. 다른 노드로 장애 조치 프로세스를 중지하여 다른 노드로 이전되도록 합니다. 

      gitlab-ctl stop geo-logcursor

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

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

    4. 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 db:migrate

    3. Geo 구성 및 의존성 확인 

      sudo gitlab-rake gitlab:geo:check
    4. /etc/gitlab/gitlab.rb 구성 파일에서 gitlab_rails['auto_migrate'] = false로 다시 변경하여 구성을 정상 상태로 되돌립니다.
      • PgBouncer를 사용하는 경우 데이터베이스 구성을 다시 해당 구성으로 변경해야 합니다.

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

       sudo gitlab-ctl reconfigure
 sudo gitlab-ctl restart

  2. 보조 사이트의 Rails 배포 노드에서 후반 배포 Geo Tracking 마이그레이션을 실행합니다.

    1. 후반 배포 Geo Tracking 마이그레이션을 실행합니다. 

      sudo gitlab-rake db:migrate:geo

    2. Geo 상태 확인: 

       sudo gitlab-rake geo:status