• 시작하기 전에
• 요구 사항 및 고려 사항
• 업그레이드 순서
• 다중 노드 / 고가용성(HA) 배포
  • Consul, PostgreSQL, PgBouncer 및 Redis
  • Gitaly
  • Praefect
  • Rails
  • Sidekiq
• Multi-node / HA 배포와 Geo
  • 기본 사이트
  • 보조 사이트(s)
    • Rails
    • Sidekiq
  • 배포 후 마이그레이션

제로 다운타임 업그레이드

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

고수준에서 이 프로세스는 특정 순서로 GitLab 노드를 순차적으로 업그레이드하여 다운타임을 최소화하기 위해 로드 밸런싱, HA 시스템 및 순응적 재시작을 조합해 수행됩니다.

이 가이드는 해당되는 경우 핵심 GitLab 구성 요소에만 관련됩니다. AWS RDS와 같은 제3자 서비스의 업그레이드나 관리에 대해서는 해당 문서를 참조하시기 바랍니다.

시작하기 전에

업그레이드 과정에서 진정한 제로 다운타임을 달성하는 것은 모든 분산 애플리케이션에 대해 특히 어렵습니다. 이 가이드에 설명된 프로세스는 우리의 HA 참조 아키텍처에서 제공된 대로 테스트되었으며, 실제로 관찰 가능한 다운타임이 없었습니다. 그러나 특정 시스템 구성에 따라 결과가 다를 수 있음을 유의하시기 바랍니다.

추가적인 확신을 위해 일부 고객은 특정 로드 밸런서 또는 인프라 기능을 통해 노드를 수동으로 비우는 등의 추가 기술로 성공을 찾았습니다. 이러한 기술은 기본 인프라 기능에 크게 의존하므로 이 가이드에서는 다루지 않습니다. 추가 정보는 GitLab 담당자에게 문의하시거나 지원 팀에 연락해 주시기 바랍니다.

요구 사항 및 고려 사항

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

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

위의 사항 외에도 다음 사항을 유의하시기 바랍니다:

• 대부분의 경우 패치 릴리스의 다음 마이너 릴리스로 안전하게 업그레이드할 수 있습니다. 패치 릴리스가 최신이 아닐 경우, 예를 들어 16.3.2에서 16.4.1로 업그레이드하는 것은 안전해야 합니다. 귀하는 다음 업그레이드 경로에 해당하는 버전별 업그레이드 지침을 확인하고 필요한 업그레이드 중지 사항을 유의하시기 바랍니다:
  • GitLab 17 변경 사항
  • GitLab 16 변경 사항
  • GitLab 15 변경 사항
• 일부 릴리스에는 백그라운드 마이그레이션이 포함될 수 있습니다. 이러한 마이그레이션은 Sidekiq에 의해 백그라운드에서 수행되며 데이터 마이그레이션에 자주 사용됩니다. 백그라운드 마이그레이션은 월간 릴리스에만 추가됩니다.
  • 특정 주요 또는 마이너 릴리스는 완료된 상태의 백그라운드 마이그레이션이 필요할 수 있습니다. 위의 조건이 충족되면 다운타임은 필요하지 않지만, 각 주요 또는 마이너 릴리스 업그레이드 사이에 백그라운드 마이그레이션이 완료될 때까지 기다려야 합니다.
  • 이러한 마이그레이션을 완료하는 데 필요한 시간은 background_migration 큐에서 작업을 처리할 수 있는 Sidekiq 작업자의 수를 늘림으로써 줄일 수 있습니다. 업그레이드 전에 백그라운드 마이그레이션을 확인하세요.
• PostgreSQL 주요 버전 업그레이드는 별도의 프로세스이며 제로 다운타임 업그레이드의 범위에 포함되지 않습니다(소규모 업그레이드는 다루어집니다).
• 제로 다운타임 업그레이드는 GitLab 리눅스 패키지로 배포한 모든 GitLab 구성 요소를 지원합니다. 선택한 구성 요소를 AWS RDS의 PostgreSQL 또는 GCP Memorystore의 Redis와 같은 지원되는 제3자 서비스를 통해 배포하는 경우, 이러한 서비스의 업그레이드는 표준 프로세스에 따라 별도로 수행해야 합니다.
• 일반적인 지침으로, 데이터 양이 많을수록 업그레이드 완료에 더 많은 시간이 걸립니다. 테스트에서 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) 배포

이번 섹션에서는 업그레이드 순서에 따라 각 노드를 순차적으로 통해 다중 노드 GitLab 환경을 업그레이드하는 핵심 프로세스를 살펴보겠습니다.

이 가이드를 위해 우리는 200 RPS 또는 10,000 레퍼런스 아키텍처를 Linux 패키지로 구축한 것을 업그레이드할 것입니다.

Consul, PostgreSQL, PgBouncer 및 Redis

Consul, PostgreSQL,

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

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

1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이 파일은 업그레이드가 gitlab-ctl 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는 조기에 부드럽게 다시 로드할 수 있는 기능이 내장되어 있습니다. 다른 모든 구성 요소는 여전히 재시작해야 합니다.

참고: 업그레이드 프로세스는 새로운 Gitaly 프로세스로의 부드러운 인계를 시도합니다.

업그레이드 이전에 시작된 기존의 장기 실행 Git 요청은 이 인계가 발생할 때 중단될 수 있습니다.

미래에는 이 기능이 변경될 수 있으며, 이 Epic을 참조하세요 추가 정보를 위해.

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

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

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

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

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
   

Praefect

Gitaly 클러스터 설정의 경우, Praefect가 배포되고 유사한 방식으로 부드러운 재시작을 통해 업그레이드해야 합니다.

참고: 업그레이드 과정은 새로운 Praefect 프로세스로의 부드러운 이양을 시도합니다.

업그레이드 전 시작된 기존의 장기 실행 Git 요청들은 이양이 발생하는 동안 최종적으로 중단될 수 있습니다.

앞으로 이 기능은 변경될 수 있으며, 더 많은 정보는 이 에픽을 참조하세요.

Praefect에 대한 한 가지 추가 단계는 데이터 업그레이드를 위해 데이터베이스 마이그레이션을 실행해야 한다는 점입니다.

마이그레이션은 충돌을 피하기 위해 단 하나의 Praefect 노드에서만 실행되어야 합니다.

이는 배포 노드를 하나 선택하여 수행하는 것이 가장 좋습니다.

이 타겟 노드는 나머지 노드는 마이그레이션을 실행하지 않고 마이그레이션을 실행하도록 구성됩니다.

우리는 이 노드를 아래에서 Praefect 배포 노드 라고 부를 것입니다:

1. Praefect 배포 노드에서:

   1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다.

      이 파일은 업그레이드 중에 gitlab-ctl 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-ctl reconfigure를 실행하지 않도록 합니다.

      기본적으로 GitLab을 자동으로 중단하고 모든 데이터베이스 마이그레이션을 실행한 다음 GitLab을 재시작합니다:

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

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

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

   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가 현재 사용 중이라면, Rails가 마이그레이션을 시도할 때 발생할 수 있는 동시 마이그레이션을 방지하기 위해 우선 우회되어야 합니다.

이러한 잠금은 트랜잭션 간에 공유되지 않으므로, ActiveRecord::ConcurrentMigrationError 및 다른 문제들이 발생할 수 있습니다.

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. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다.

      이 파일은 업그레이드 중에 gitlab-ctl 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 마스터 프로세스에 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. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다.

      이 파일은 업그레이드 중에 gitlab-ctl reconfigure를 실행하지 않도록 합니다.

      기본적으로 GitLab을 자동으로 중단하고 모든 데이터베이스 마이그레이션을 실행한 다음 GitLab을 재시작합니다:

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

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

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

   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. 다시 재구성을 실행하여 정규 구성을 다시 적용하고 재시작합니다:

      sudo gitlab-ctl reconfigure
      sudo gitlab-ctl restart
      

Sidekiq

Sidekiq는 중단 없이 업그레이드하는 동일한 기본 프로세스를 따릅니다.

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

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

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

2. GitLab 패키지를 업그레이드하세요.

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

   sudo gitlab-ctl reconfigure
   sudo gitlab-ctl restart
   

Multi-node / HA 배포와 Geo

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

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

참고: Geo와 함께 라이브 GitLab 환경을 업그레이드하는 데 동일한 요구 사항 및 고려 사항이 적용됩니다.

기본 사이트

기본 사이트의 업그레이드 프로세스는 정상 프로세스와 동일하지만, 모든 보조 사이트가 업데이트된 후까지 배포 후 마이그레이션을 실행하지 않는다는 예외가 있습니다.

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

보조 사이트(s)

모든 보조 사이트의 업그레이드 프로세스는 일반적인 프로세스와 동일한 단계를 따르지만, 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. Geo Log Cursor 프로세스를 중지하여 다른 노드로 장애 조치를 보장합니다:

      gitlab-ctl stop geo-logcursor
      

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

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

      gitlab-ctl stop geo-logcursor
      

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

      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가 사용되고 있다면 데이터베이스 구성을 다시 한 번 PgBouncer를 가리키도록 설정해야 합니다.

   5. 정상 구성을 다시 적용하고 재시작하기 위해 다시 리구리파이합니다:

      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