• 시작하기 전에
• 요구 사항 및 고려 사항
• 업그레이드 순서
• 멀티 노드 / HA 배포
  • Consul, PostgreSQL, PgBouncer 및 Redis
  • Gitaly
  • Praefect
  • Rails
  • Sidekiq
• Multi-node / HA 배포와 지오
  • 기본 사이트
  • 보조 사이트
    • 레일스
    • Sidekiq
  • 배포 후 마이그레이션

제로 다운타임 업그레이드

제로 다운타임 업그레이드를 사용하면 GitLab 환경을 오프라인으로 전환하지 않고도 라이브 환경을 업그레이드할 수 있습니다. 이 안내서는 이러한 업그레이드의 핵심 프로세스를 진행합니다.

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

본 가이드는 해당되는 경우 핵심 GitLab 구성요소에만 적용됩니다. AWS RDS와 같은 서드파티 서비스의 업그레이드나 관리의 경우, 해당 문서를 참조하십시오.

시작하기 전에

업그레이드 중 실제로 제로 다운타임을 달성하는 것은 분산 애플리케이션의 경우 어려운 작업입니다. 이 안내서에 설명된 프로세스는 HA 참조 아키텍처에서 제공된 대로 테스트되었으며 실질적인 다운타임이 거의 없는 것으로 확인되었습니다. 그러나 사용 중인 시스템 구성에 따라 결과가 달라질 수 있음을 유의해 주십시오.

추가적인 확신을 얻기 위해 일부 고객들은 특정 로드 밸런서나 인프라 기능을 통해 노드를 수동으로 비우는 등의 방법을 통해 성공을 거두었습니다. 그러나 이러한 기술은 기반이 되는 인프라 기능에 크게 의존하기 때문에 해당 안내서에 포함되지 않았습니다. 추가 정보가 필요한 경우 GitLab 담당자나 지원팀에 문의하십시오.

요구 사항 및 고려 사항

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

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

이외에도 다음과 같은 고려 사항에 유의하십시오:

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

참고: 여러 릴리스를 업그레이드하려는 경우 또는 이러한 요구 사항을 충족하지 않는 경우 다운타임을 사용한 업그레이드를 대신 탐구해야 합니다.

업그레이드 순서

제로 다운타임을 사용한 업그레이드의 업그레이드 순서는 다음과 같이 “뒤에서 앞으로”를 추천합니다. 일반적으로 상태 유지형 백엔드를 먼저, 그들의 종속 요소를 다음으로, 그리고 그 다음에 이에 따라 프론트엔드를 업그레이드하는 것이 좋습니다. 배포 순서를 변경할 수는 있지만, GitLab 애플리케이션 코드 (Rails, Sidekiq)를 함께 배포하는 것이 최선입니다. 가능하다면, 지원 인프라 (PostgreSQL, PgBouncer, Consul, Gitaly, Praefect, Redis)를 별도로 업그레이드하십시오. 이러한 구성 요소는 주요 릴리스 내의 버전 업데이트에 대한 의존성이 없기 때문입니다. 따라서 일반적으로 다음을 권장합니다:

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

멀티 노드 / HA 배포

이 섹션에서는 각 노드에 업그레이드 순서에 따라 순차적으로 진행하고 로드 밸런서 및 HA 메커니즘이 각 노드의 다운타임을 처리하는 멀티 노드 GitLab 환경의 업그레이드 핵심 프로세스를 다룰 것입니다.

본 가이드에서는 Linux 패키지로 구축된 200 RPS 또는 10,000 참조 아키텍처를 업그레이드할 것입니다.

Consul, PostgreSQL, PgBouncer 및 Redis

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

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

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

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

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

3. 최신 코드를 가져오고 재구성하고 다시 시작합니다:

   sudo gitlab-ctl reconfigure
   sudo gitlab-ctl restart
   

Gitaly

Gitaly는 업그레이드할 때 동일한 핵심 프로세스를 따르지만 핵심적인 차이점으로는 Gitaly 프로세스 자체가 가능한 빨리 우아하게 다시로드되도록 내장된 프로세스를 재시작하지 않는다는 것입니다. 다른 구성 요소는 여전히 재시작해야 한다는 점을 유의하십시오.

참고: 업그레이드 프로세스는 새 Gitaly 프로세스에 정상적으로 권한을 위임하려고 시도합니다. 업그레이드하기 전에 시작된 기존 긴 실행 중인 Git 요청은 이러한 권한 위임이 발생하는 동안 최종적으로 삭제될 수 있습니다. 미래에 이 기능이 변경될 수 있으며 더 많은 정보는 이 에픽을 참조하십시오.

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

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

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

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

3. 최신 코드를 가져오고 재구성하며 Gitaly에 우아하게 다시로드하도록 다음 번 기회에 지시합니다:

   sudo gitlab-ctl reconfigure
   

4. 마지막으로, Gitaly가 다른 배포된 구성 요소를 우아하게 다시로드하더라도 여전히 재시작해야 합니다.

   # Gitaly 외에 배포된 다른 구성 요소 목록 가져오기
   sudo gitlab-ctl status
   
   # Consul, Node Exporter 및 Logrotate에 대한 예제를 들어 각 구성 요소 재시작
   sudo gitlab-ctl restart consul node-exporter logrotate
   

Praefect

Gitaly Cluster 설정의 경우 Praefect가 배포되어 있으며, 우아하게 다시로드하도록 유사한 방식으로 업그레이드해야 합니다.

참고: 업그레이드 프로세스는 새 Praefect 프로세스에 우아하게 권한을 위임하려고 시도합니다. 업그레이드하기 전에 시작된 기존 긴 실행 중인 Git 요청은 이러한 권한 위임이 발생하는 동안 최종적으로 삭제될 수 있습니다. 미래에 이 기능이 변경될 수 있으며 더 많은 정보는 이 에픽을 참조하십시오.

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 데이터베이스 마이그레이션을 적용하고, 우아하게 다시 시작하도록 다음 명령 실행:

      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가 설정되어 있는지 확인하여 reconfigure가 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 합니다.

   4. 최신 코드를 가져오고 우아하게 다시 시작하도록 다음 명령 실행:

      sudo gitlab-ctl reconfigure
      

3. 마지막으로, Praefect가 우아하게 다시로드하지만 다른 배포된 구성 요소는 여전히 재시작해야 합니다. 각 Praefect 노드에서:

   # Praefect 외에 배포된 다른 구성 요소 목록 가져오기
   sudo gitlab-ctl status
   
   # Praefect 예시와 같이 각 구성 요소 재시작을 위해:
   sudo gitlab-ctl restart consul node-exporter logrotate
   

Rails

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

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

위의 내용과 더불어, Rails는 주된 데이터베이스 마이그레이션이 실행되는 곳입니다. Praefect와 마찬가지로, 이는 디플로이 노드 접근 방식을 통해 실행하는 것이 가장 좋습니다. 현재 PgBouncer를 사용하고 있다면, Rails가 동일한 데이터베이스에서 동시 마이그레이션을 방지하기 위해 추천된 것은 PgBouncer를 우회하는 것입니다. 이러한 잠금은 트랜잭션 간에 공유되지 않으며, 데이터베이스 마이그레이션을 실행할 때 ActiveRecord::ConcurrentMigrationError 및 기타 문제가 발생할 수 있습니다.

1. Rails 디플로이 노드에서:

   1. 노드에서 트래픽을 우아하게 차단합니다. 다양한 방법으로 수행할 수 있지만, 예를 들어 다음 쉘 스크립트를 통해 NGINX를 통해 QUIT 시그널을 보내고 서비스를 중지할 수 있습니다:

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

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

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

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

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

   4. 최신 코드를 가져오고, 우아하게 다시 시작하도록 다음 명령 실행:

      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로 설정을 되돌려 놓고 noraml 구성을 다시 적용하도록 합니다.
      • PgBouncer를 사용하는 경우 데이터베이스 구성을 다시 이를 향하도록 설정해야 합니다.
   4. 다시 재구성하여 정상 구성

Sidekiq

Sidekiq은 다른 것들과 같은 기본 프로세스를 따라 다운타임 없이 업그레이드합니다.

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

1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl 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 배포와 지오

이 섹션에서는 지오와 함께 라이브 GitLab 환경을 업그레이드하는 데 필요한 단계에 대해 설명합니다.

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

참고: 지오를 사용하여 라이브 GitLab 환경을 업그레이드하는 경우 동일한 요구 사항 및 고려 사항이 적용됩니다.

기본 사이트

기본 사이트의 업그레이드 프로세스는 일반적인 프로세스와 크게 동일하지만 한 가지 예외가 있습니다. 모든 보조 사이트가 업데이트된 _후_에 포스트-배포 마이그레이션을 실행하지 않아야 합니다.

기본 사이트에 대해 동일한 단계를 실행하여 포스트-배포 마이그레이션을 실행하는 레일스 노드 단계에서 중지합니다.

보조 사이트

보조 사이트의 업그레이드 프로세스는 레일스 노드에서 필요한 몇 가지 추가 단계를 제외하고 일반 프로세스와 동일합니다.

보조 사이트를 업그레이드하려면 일반적인 프로세스 단계를 따라 진행하되 레일스 노드에 도달한 후 아래의 단계를 따릅니다.

레일스

1. 레일스 배포 노드에서:

   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. 다른 노드로의 Geo Log Cursor 프로세스를 중지하여 다른 노드로의 장애 조치를 보장합니다:

      gitlab-ctl stop geo-logcursor
      

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

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

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

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

   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. 모든 다른 레일스 노드에서 순차적으로:

   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. 다른 노드로의 Geo Log Cursor 프로세스를 중지하여 다른 노드로의 장애 조치를 보장합니다:

      gitlab-ctl stop geo-logcursor
      

   3. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 업그레이드가 gitlab-ctl 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를 거치고 있다면, 반드시 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 추적 마이그레이션을 실행하세요:

   1. 배포 후 Geo 추적 마이그레이션을 실행하세요:

      sudo gitlab-rake db:migrate:geo
      

   2. Geo 상태 확인:

       sudo gitlab-rake geo:status