• 멀티 노드 / HA 배포
  • 웹 (Puma) 노드 앞에서 로드 밸런서 사용
  • Gitaly 또는 Gitaly 클러스터
    • Gitaly 노드 업그레이드
    • Praefect 업그레이드
  • PostgreSQL
  • Redis HA (Sentinel 사용)
    • 애플리케이션 노드에서
    • Redis의 보조 노드에서
    • Redis의 주 노드에서
    • 애플리케이션 노드 업데이트
• Geo 배포
  • Geo 기본 사이트 업데이트
  • Geo 보조 사이트 업데이트
  • 업데이트 완료
• Geo와 함께하는 Multi-node / HA 배포
  • 단계 1: 각 배포에 대한 “배포 노드” 선택
  • 단계 2: Geo 주요 멀티 노드 배포 업데이트
  • 단계 3: 각 Geo secondary 멀티 노드 배포 업데이트
  • 단계 4: 배포 후 마이그레이션 및 확인 실행

제로 다운타임 업그레이드

GitLab의 새로운 major, minor 또는 patch 버전으로 업그레이드할 때 GitLab 인스턴스를 오프라인 상태로 전환할 필요 없이 업그레이드할 수 있습니다. 그러나 이를 가능하게 하려면 다음과 같은 요구 사항이 있습니다:

• 한 번에 하나의 minor 버전만 업그레이드할 수 있습니다. 따라서 13.1에서 13.2로 업그레이드하며, 13.3으로 넘어가지 않습니다. 리소스를 건너뛰면 데이터베이스 수정이 잘못된 순서로 실행될 수 있습니다. 그런 데 이는 데이터베이스 스키마가 망가지게 됩니다.
• 포스트-배포 마이그레이션을 사용해야 합니다.
• PostgreSQL을 사용해야 합니다. GitLab 12.1부터 MySQL은 지원되지 않습니다.
• 멀티 노드 GitLab 인스턴스를 설정해야 합니다. Cloud Native Hybrid 설치는 제로 다운타임 업그레이드를 지원하지 않습니다.

여러 버전을 업그레이드하거나 다른 요구 사항을 충족하지 못하는 경우:

• 다운타임이 있는 단일 노드 업그레이드를 수행하세요.
• 다운타임이 있는 멀티 노드 인스턴스 업그레이드를 수행하세요.

위의 모든 요구 사항을 충족한다면, 다음 순서대로 이 지침을 따르세요. 배포 유형에 따라 세 가지 세트의 단계가 있습니다.

각 배포 유형은 최신 GitLab 버전을 사용한 모든 노드에서 puma 및 sidekiq 프로세스를 hot reload해야 합니다. 그 이유는 각각의 프로세스가 GitLab Rails 애플리케이션을로드하는데, 애플리케이션이 시작될 때 데이터베이스 스키마를 읽고로드하기 때문입니다. 이러한 프로세스 중 하나는 재로드해야 합니다 (sidekiq의 경우 재시작) 했으며, 포스트-배포 마이그레이션에 의해 수행된 모든 데이터베이스 변경 사항을 다시 읽어야 합니다.

대부분의 경우, 최신 패치 버전에서 다음 minor 버전으로 안전하게 업그레이드할 수 있습니다. 예를 들어, 14.1.1에서 14.2.0으로 업그레이드하는 것은 안전할 수 있습니다. 14.1.2가 출시되었더라도 해당 버전의 패치가 최신 버전이 아니라면요. 하지만 현재 버전과 목표 버전 사이의 모든 릴리스의 릴리스 글을 확인하는 것을 권장합니다. 이 릴리스 글에는 단계별로 업그레이드할 필요가 있는 마이그레이션을 포함할 수 있으므로요.

또한, 버전별 업그레이드 지침과 관련된 업그레이드 경로를 확인하는 것을 권장합니다.

일부 릴리스에는 “백그라운드 마이그레이션”이라고 하는 것이 포함될 수 있습니다. 이러한 마이그레이션은 배경에서 Sidekiq에 의해 수행되며 데이터 이동에 자주 사용됩니다. 백그라운드 마이그레이션은 월간 릴리스에만 추가됩니다.

특정 major/minor 릴리스에는 진행해야 하는 일련의 백그라운드 마이그레이션이 있을 수 있습니다. 따라서 해당 릴리스는 업그레이드 프로시저를 계속하기 전에 남아있는 작업을 처리합니다. 이는 다운타임이 필요하지 않지만, (위의 조건이 충족된다면) 모든 major/minor 릴리스 업그레이드 사이에 백그라운드 마이그레이션이 완료될 때까지 기다려야 합니다.

이러한 마이그레이션을 완료하는 데 필요한 시간은 background_migration 큐에서 작업을 처리할 수 있는 Sidekiq 워커의 수를 늘리는 것으로 단축할 수 있습니다. 이 큐의 크기를 확인하려면, 업그레이드 전에 백그라운드 마이그레이션을 확인하세요.

일반적으로 데이터베이스 크기가 10GB 미만이라면 각 minor 릴리스마다 최대 한 시간 정도 소요됩니다. 그러나 더 큰 데이터베이스의 경우 더 많은 시간이 필요할 수 있지만, 이는 데이터베이스 크기와 수행 중인 마이그레이션에 매우 의존적입니다.

이를 설명하기 위해 몇 가지 예를 살펴보겠습니다:

예시 1: 최신 패치 릴리스인 13.4.2 버전을 사용하는 대규모 GitLab 설치를 실행 중입니다. 이 경우 업그레이드 요구 사항을 충족한다면 출시된지 얼마 안 된 13.5.0으로 안전하게 업그레이드할 수 있습니다. 또한 13.5.0을 건너뛰고 출시된 후 13.5.1로 업그레이드할 수 있지만, 13.6.0으로 직접 업그레이드할 수는 없습니다. 반드시 먼저 13.5.Z 릴리스로 업그레이드해야 합니다.

예시 2: 최신 패치 릴리스인 13.4.2 버전을 사용하는 대규모 GitLab 설치를 실행 중입니다. GitLab 13.5에는 일부 백그라운드 마이그레이션이 포함되어 있고, 14.0 버전은 백그라운드 마이그레이션을 완료해야 합니다 (남아 있는 모든 작업을 처리함). 13.5를 건너뛸 수 없으며, 백그라운드 마이그레이션에 소요되는 시간에 따라 몇 시간의 다운타임이 필요합니다. 이를 피하기 위해 먼저 13.5.Z로 업그레이드해야 하고, 그 후에 최소 한 주를 기다려야 14.0으로 업그레이드할 수 있습니다.

예시 3: GitLab의 데이터베이스로 MySQL을 사용합니다. 새로운 major/minor 릴리스로 업그레이드하는 경우 다운타임이 필요합니다. 릴리스에 백그라운드 마이그레이션이 포함되어 있다면 데이터베이스의 크기에 따라 몇 시간의 다운타임이 필요할 수 있습니다. 이를 해결하려면 PostgreSQL을 사용하고 앞에서 언급된 다른 온라인 업그레이드 요구 사항을 충족해야 합니다.

멀티 노드 / HA 배포

웹 (Puma) 노드 앞에서 로드 밸런서 사용

Puma로는 더 이상 단일 노드 제로 다운타임 업데이트가 불가능합니다. HA를 달성하려면 적어도 두 노드를 사용하여 연결을 적절하게 분산하는 로드 밸런서와 함께 사용되어야합니다.

응용 프로그램 노드 앞의 로드 밸런서는 서비스가 트래픽을 수락하는지 여부를 확인하기 위해 적절한 상태 체크 엔드포인트를 확인하도록 구성되어야합니다. Puma의 경우 /-/readiness 엔드포인트를 사용해야 하며, Sidekiq 및 기타 서비스의 경우 /readiness 엔드포인트를 사용해야합니다.

웹 (Puma) 노드의 업그레이드는 굉장히 중요합니다. 항상 최소한 하나의 노드가 트래픽을 제공할 수 있도록 다른 노드를 올려야합니다. 이는 제로 다운타임을 보장하기 위해 필요합니다.

Puma는 업그레이드의 일환이며, 이 과정 중에 노드는 여전히 연결을 수락하지만 각각의 상태 체크 엔드포인트를 비정상적으로 표시하게 될 것입니다. 이를 확인하면 로드 밸런서가 문제없이 연결을 끊어야합니다.

Puma는 현재 처리 중인 모든 요청을 완료한 후에만 재시작합니다. 이는 데이터 및 서비스의 무결성을 보장합니다. 재시작된 후 상태 체크 엔드포인트가 정상적으로 표시됩니다.

노드를 최신 GitLab 버전으로 업데이트하려면 다음과 같은 순서로 업데이트해야합니다.

1. 배포 노드로 하나의 응용 프로그램 노드를 선택하고 다음 단계를 완료하세요:

   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'] = true가 있어야합니다.

      sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure
      

   4. 서비스가 최신 코드를 사용하도록 확인하세요:

      sudo gitlab-ctl hup puma
      sudo gitlab-ctl restart sidekiq
      

2. 다른 Puma/Sidekiq 노드에서 다음 단계를 계속 완료하세요. 항상 적어도 하나의 이러한 노드가 실행 중이고 로드 밸런서에 연결된 상태로 진행하기 전에 다음 노드로 계속 진행해야합니다.

   1. GitLab 패키지를 업그레이드하고 업그레이드의 일환이 실행되었는지 확인하세요. (기본적으로 /etc/gitlab/skip-auto-reconfigure 파일이 있어서 그럴 때는 매뉴얼으로 sudo gitlab-ctl reconfigure를 실행해야합니다.)

   2. 서비스가 최신 코드를 사용하도록 확인하세요:

      sudo gitlab-ctl hup puma
      sudo gitlab-ctl restart sidekiq
      

3. 배포 노드에서 포스트-배포 마이그레이션을 실행하세요:

      sudo gitlab-rake db:migrate
   

Gitaly 또는 Gitaly 클러스터

Gitaly 노드는 자체 서버에 위치할 수 있으며 샤딩 설정이나 Gitaly 클러스터의 일부로 위치할 수 있습니다.

GitLab 애플리케이션을 업데이트하기 전에 다음과 같은 순서로 진행해야 합니다:

1. 별도의 서버에 위치한 Gitaly 노드를 업그레이드합니다.
2. Gitaly 클러스터를 사용하는 경우 Praefect도 업그레이드합니다.

알려진 문제로 인해 Gitaly 및 Gitaly 클러스터 업그레이드는 일부 다운타임을 유발합니다.

Gitaly 노드 업그레이드

Gitaly 노드에서는 Git 리포지터리 접근이 유지되도록 하기 위해 Gitaly 노드를 하나씩 순차적으로 GitLab 패키지를 업그레이드합니다.

Praefect 업그레이드

Praefect 노드에서 Praefect 배포 노드를 선택합니다. 새 Omnibus 패키지를 먼저 배포 노드에 설치하고 데이터베이스 마이그레이션을 실행합니다.

1. Praefect 배포 노드에서:

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

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

   2. /etc/gitlab/gitlab.rb에서 praefect['auto_migrate'] = true로 설정되어 있는지 확인합니다.

2. 나머지 Praefect 노드에서:

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

3. Praefect 배포 노드에서:

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

   2. Praefect 데이터베이스 마이그레이션을 적용하고 Praefect를 다시 시작하려면 다음을 실행합니다:

      sudo gitlab-ctl reconfigure
      

4. 나머지 Praefect 노드에서:

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

   2. 노드가 최신 코드를 실행하도록합니다:

      sudo gitlab-ctl reconfigure
      

PostgreSQL

배포 노드를 선택합니다. 애플리케이션 노드이거나 프로세스 중에 동일한 노드여야 합니다.

배포 노드

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

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

배포 노드를 포함한 모든 노드

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

PostgreSQL 전용 노드

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

• 노드가 최신 코드를 실행하도록합니다.

  sudo gitlab-ctl reconfigure
  

배포 노드

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

• PgBouncer를 사용하는 경우:

  데이터베이스 마이그레이션을 실행하기 전에 반드시 PgBouncer 우회하고 데이터베이스 리더에 직접 연결해야 합니다.

  데이터베이스 마이그레이션을 실행하려면 Rails가 트랜잭션 풀링 모드에서 PgBouncer를 사용할 때 동시 마이그레이션 실행을 방지하기 위해 즉석 잠금을 사용합니다. 이러한 잠금은 트랜잭션 간에 공유되지 않으므로 ActiveRecord::ConcurrentMigrationError 및 기타 문제가 발생할 수 있습니다.

  리더 노드를 찾으려면 데이터베이스 노드에서 다음을 실행합니다:

  sudo gitlab-ctl patroni members
  

  그런 다음 배포 노드의 gitlab.rb 파일에서 gitlab_rails['db_host'] 및 gitlab_rails['db_port']를 데이터베이스 리더의 호스트 및 포트로 업데이트합니다.

• 정규 데이터베이스 마이그레이션과 최신 코드를 적용하려면 다음을 실행합니다.

  sudo gitlab-ctl reconfigure
  sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate
  

배포 노드를 제외한 모든 노드

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

• 노드가 최신 코드를 실행하도록합니다.

  sudo gitlab-ctl reconfigure
  

배포 노드

• 배포 노드에서 다음을 실행하여 배포 후 데이터베이스 마이그레이션을 완료합니다.

  sudo gitlab-rake db:migrate
  

Puma 또는 Sidekiq를 실행 중인 노드의 경우

• puma 및 sidekiq 서비스를 핫 리로드합니다.

  sudo gitlab-ctl hup puma
  sudo gitlab-ctl restart sidekiq
  

• PgBouncer를 사용하는 경우:

  gitlab.rb를 PgBouncer로 다시 지정하고 다음을 실행합니다:

  sudo gitlab-ctl reconfigure
  

향후 제로 다운타임 업그레이드를 실행하지 않으려면 이러한 단계를 완료한 후 /etc/gitlab/skip-auto-reconfigure를 제거하고 /etc/gitlab/gitlab.rb에서 gitlab_rails['auto_migrate'] = false 설정을 되돌리도록합니다.

Redis HA (Sentinel 사용)

패키지 업그레이드에는 번들된 Redis 서비스의 버전 업데이트가 포함될 수 있습니다. Redis를 사용하여 확장하는 인스턴스의 경우 최소한의 다운 타임을 보장하기 위해 업그레이드를 다음과 같은 적절한 순서로 진행해야 합니다. 이 문서는 Redis HA를 설정하기 위해 공식 가이드를 따르고 있다고 가정합니다.

애플리케이션 노드에서

공식 Redis 문서에 따르면 Sentinel을 사용하여 HA 인스턴스를 업데이트하는 가장 쉬운 방법은 두 번째 로컬 인스턴스를 하나씩 업그레이드한 다음 현재 프라이머리(이전 버전 실행)에서 최근에 업그레이드된 보조들로 매뉴얼 장애 조치를 수행하고 그런 다음 원래의 프라이머리를 업그레이드하는 것입니다. 이를 위해 현재 Redis 프라이머리의 주소를 알아야합니다.

• 애플리케이션 노드에서 GitLab 12.7.0 이상을 실행하는 경우 다음 명령을 사용하여 현재 Redis 프라이머리의 주소를 가져올 수 있습니다.

  sudo gitlab-ctl get-redis-master
  

• 애플리케이션 노드에서 GitLab 12.7.0보다 오래된 버전을 실행 중인 경우 기본 redis-cli 명령(사용되는 get-redis-master 명령이 사용하는 명령)을 실행해야합니다.

  1. /etc/gitlab/gitlab.rb에서 gitlab_rails['redis_sentinels']로 지정된 감시 노드 중 하나의 주소를 가져옵니다.

  2. /etc/gitlab/gitlab.rb에서 redis['master_name']으로 지정된 Redis 메인 이름을 가져옵니다.

  3. 다음 명령을 실행합니다.

     sudo /opt/gitlab/embedded/bin/redis-cli -h <sentinel host> -p <sentinel port> SENTINEL get-master-addr-by-name <redis master name>
     

Redis의 보조 노드에서

1. 만약 아직 하지 않았다면, gitlab.rb에 gitlab_rails['rake_cache_clear'] = false를 설정하세요. 그렇지 않으면 새로운 패키지를 설치한 후 재구성 중에 Redis::CommandError: READONLY You can't write against a read only replica.라는 오류가 발생할 수 있습니다.

2. 새 버전의 패키지를 설치하세요.

3. 재구성이 설치의 일부로 실행되지 않은 경우에는 sudo gitlab-ctl reconfigure를 실행하세요 (/etc/gitlab/skip-auto-reconfigure 파일이 있는 경우).

4. 재구성에서 보류 중인 Redis/Sentinel 재시작에 대해 경고가 표시된 경우, 해당 서비스를 다시 시작하세요.

   sudo gitlab-ctl restart redis
   sudo gitlab-ctl restart sentinel
   

Redis의 주 노드에서

Redis의 주 노드를 업그레이드하기 전에, 최근에 업그레이드된 보조 노드 중 하나가 새 주 노드가 되도록 장애 조치(failover)를 수행해야 합니다. 장애 조치가 완료되면 원래 주 노드를 업그레이드할 수 있습니다.

1. 보조 노드로의 장애 조치를 위해 Redis 서비스를 중지시킵니다.

   sudo gitlab-ctl stop redis
   

2. 장애 조치가 완료될 때까지 기다리세요. 현재 Redis 주 노드의 세부 정보를 주기적으로 확인하여 새 IP가 표시되면 장애 조치가 완료된 것입니다.

3. 해당 노드에서 Redis를 다시 시작하여 현재 주 노드를 따르도록 만드세요.

   sudo gitlab-ctl start redis
   

4. 새 버전에 해당하는 패키지를 설치하세요.

5. 재구성이 설치의 일부로 실행되지 않은 경우에는 sudo gitlab-ctl reconfigure를 실행하세요 (/etc/gitlab/skip-auto-reconfigure 파일이 있는 경우).

6. 재구성에서 보류 중인 Redis/Sentinel 재시작에 대해 경고가 표시된 경우, 해당 서비스를 다시 시작하세요.

   sudo gitlab-ctl restart redis
   sudo gitlab-ctl restart sentinel
   

애플리케이션 노드 업데이트

새 버전의 패키지를 설치하고 일반적인 패키지 업그레이드 절차를 따르세요.

Geo 배포

단계의 순서가 중요합니다. 이러한 단계를 따를 때 올바른 노드에서 올바른 순서대로 따르도록 하세요.

Geo 기본 사이트 업데이트

기본(primary) 노드에 로그인하여 다음을 실행하세요:

1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성하세요. 이렇게 하면 기본 설정으로 gitlab-ctl reconfigure이 실행되지 않아 GitLab이 자동으로 중지되지 않고 모든 데이터베이스 마이그레이션을 실행한 후 GitLab을 다시 시작하지 않습니다.

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

2. /etc/gitlab/gitlab.rb를 편집하고 다음이 있는지 확인하세요:

   gitlab_rails['auto_migrate'] = false
   

3. GitLab을 다시 구성하세요:

   sudo gitlab-ctl reconfigure
   

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

5. 데이터베이스 마이그레이션과 최신 코드를 적용하려면 다음을 실행하세요:

   sudo gitlab-ctl reconfigure
   

6. 노드가 업데이트되고 재구성이 성공적으로 완료된 후에 마이그레이션을 완료하세요:

   sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate
   

7. 주 사이트의 /etc/gitlab/gitlab-secrets.json 파일을 보조 사이트로 복사하세요. 파일은 사이트의 모든 노드에서 동일해야 합니다.

Geo 보조 사이트 업데이트

각 보조 노드에서 다음을 실행하세요:

1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성하세요. 이렇게 하면 기본 설정으로 gitlab-ctl reconfigure이 실행되지 않아 GitLab이 자동으로 중지되지 않고 모든 데이터베이스 마이그레이션을 실행한 후 GitLab을 다시 시작하지 않습니다.

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

2. /etc/gitlab/gitlab.rb를 편집하고 다음이 있는지 확인하세요:

   gitlab_rails['auto_migrate'] = false
   

3. GitLab을 다시 구성하세요:

   sudo gitlab-ctl reconfigure
   

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

5. 데이터베이스 마이그레이션을 실행하세요 (Geo 데이터베이스에 특화됨).

   sudo gitlab-rake db:migrate:geo
   

업데이트 완료

모든 보조 노드가 업데이트된 후, 기본 노드에서 업데이트를 완료하세요:

• 포스트-배포 데이터베이스 마이그레이션을 실행하세요.

  sudo gitlab-rake db:migrate
  

• 기본(primary) 노드에서 업데이트가 완료된 후, 모든 기본 및 보조 노드에서 puma를 핫 리로드하고 sidekiq 및 geo-logcursor 서비스를 다시 시작하세요.

  sudo gitlab-ctl hup puma
  sudo gitlab-ctl restart sidekiq
  sudo gitlab-ctl restart geo-logcursor
  

모든 노드(기본 및 모든 보조 노드)를 업데이트한 후, 상태를 확인하세요:

• Geo 구성 및 의존성 확인

  sudo gitlab-rake gitlab:geo:check
  

앞으로 영구 중지 시간이 없는 업그레이드를 실행하고 싶지 않다면, 이러한 단계를 완료한 후 /etc/gitlab/skip-auto-reconfigure를 제거하고 /etc/gitlab/gitlab.rb에서 gitlab_rails['auto_migrate'] = false 설정을 되돌리는지 확인하세요.

Geo와 함께하는 Multi-node / HA 배포

이 섹션에서는 Geo와 함께하는 Multi-node / HA 배포를 업그레이드하는 데 필요한 단계에 대해 설명합니다. 일부 단계는 특정 노드에서 수행해야 합니다. 이러한 노드는 “배포 노드”로서 다음 지침에서 확인할 수 있습니다.

업데이트는 다음 순서대로 수행해야 합니다:

1. Geo 기본 다중 노드 배포 업데이트
2. Geo 보조 다중 노드 배포 업데이트
3. 포스트-배포 마이그레이션 및 확인

단계 1: 각 배포에 대한 “배포 노드” 선택

이제 다음을 선택해야 합니다:

• Geo primary 멀티 노드 배포에서 “배포 노드”로 사용할 하나의 인스턴스
• 각 Geo secondary 멀티 노드 배포에서 “배포 노드”로 사용할 하나의 인스턴스

배포 노드는 Puma 또는 Sidekiq 또는 geo-logcursor가 실행되도록 구성되어야 합니다. 어떠한 다운타임도 피하기 위해 업데이트 중에 사용되지 않아야 합니다.

• Puma를 실행 중이면 배포 노드를 로드 밸런서에서 제거하세요.

• Sidekiq를 실행 중이라면 배포 노드가 작업을 처리하고 있지 않도록 확인하세요:

  sudo gitlab-ctl stop sidekiq
  

• geo-logcursor 데몬을 실행 중이라면 배포 노드가 이벤트를 처리하지 않도록 확인하세요:

  sudo gitlab-ctl stop geo-logcursor
  

무중단을 위해, Puma, Sidekiq 및 geo-logcursor는 업데이트 중에 다른 노드에서 실행 중이어야 합니다.

단계 2: Geo 주요 멀티 노드 배포 업데이트

“배포 노드”를 포함한 모든 주요 노드에서

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

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

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

2. 노드가 최신 코드를 실행하도록 확인합니다.

   sudo gitlab-ctl reconfigure
   

주요 Gitaly 전용 노드에서만

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

2. 노드가 최신 코드를 실행하도록 확인합니다.

   sudo gitlab-ctl reconfigure
   

주요 “배포 노드”에서

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

2. PgBouncer를 사용 중이라면:

   데이터베이스 마이그레이션을 실행하기 전에 반드시 PgBouncer를 우회하고 데이터베이스 리더에 직접 연결해야 합니다.

   Rails는 데이터베이스에서 동시에 마이그레이션을 실행하는 것을 막기 위해 고문서 잠금을 사용합니다. 이러한 잠금은 트랜잭션 간에 공유되지 않으므로 트랜잭션 풀링 모드에서 PgBouncer를 사용하여 데이터베이스 마이그레이션을 실행하는 경우 ActiveRecord::ConcurrentMigrationError 및 기타 문제가 발생합니다.

   리더 노드를 찾으려면 데이터베이스 노드에서 다음을 실행하세요:

   sudo gitlab-ctl patroni members
   

   그런 다음 배포 노드의 gitlab.rb 파일에서 gitlab_rails['db_host'] 및 gitlab_rails['db_port']를 데이터베이스 리더의 호스트 및 포트로 업데이트하세요.

3. 정규 데이터베이스 마이그레이션 및 최신 코드를 적용하려면 다음을 실행하세요.

   sudo gitlab-ctl reconfigure
   sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate
   

4. 이 배포 노드가 요청을 처리하거나 작업을 실행 중이라면, 이 단계에서 해당 서비스로 돌아가도 됩니다.

   • 요청을 처리하려면 배포 노드를 로드 밸런서에 추가하세요.

   • Sidekiq 작업을 다시 처리하려면 Sidekiq를 시작하세요:

     sudo gitlab-ctl start sidekiq
     

“배포 노드”를 제외한 모든 주요 노드에서

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

2. 노드가 최신 코드를 실행하도록 확인합니다.

   sudo gitlab-ctl reconfigure
   

주요 노드 전체의 Puma 또는 Sidekiq를 실행 중인 경우, “배포 노드”를 포함하여 모든 주요 노드에 대해

puma 및 sidekiq 서비스를 핫 리로드합니다:

sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq

1. gitlab-secrets.json 파일을 기본 사이트에서 보조 사이트로 복사합니다. 해당 사이트의 모든 노드에서 이 파일이 동일해야 합니다.

단계 3: 각 Geo secondary 멀티 노드 배포 업데이트

Geo primary 멀티 노드 배포의 모든 단계를 성공적으로 완료한 경우에만 진행하세요.

보조 노드 전체의 “배포 노드”를 포함하여 모든 보조 노드에서

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

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

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

2. 노드가 최신 코드를 실행하도록 확인합니다.

   sudo gitlab-ctl reconfigure
   

보조 Gitaly 전용 노드에서만

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

2. 노드가 최신 코드를 실행하도록 확인합니다.

   sudo gitlab-ctl reconfigure
   

보조 “배포 노드”에서

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

2. 정규 데이터베이스 마이그레이션 및 최신 코드를 적용하려면 다음을 실행하세요.

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

3. 이 배포 노드가 요청을 처리하거나 백그라운드 처리를 실행 중이라면, 이 단계에서 해당 서비스로 돌아가도 됩니다.

   • 요청을 처리하려면 배포 노드를 로드 밸런서에 추가하세요.

   • Sidekiq 작업을 다시 처리하려면 Sidekiq를 시작하세요.

     sudo gitlab-ctl start sidekiq
     

   • Geo 이벤트를 다시 처리하려면 geo-logcursor 데몬을 시작하세요.

     sudo gitlab-ctl start geo-logcursor
     

“배포 노드”를 제외한 모든 보조 노드에서

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

2. 노드가 최신 코드를 실행하도록 확인합니다.

   sudo gitlab-ctl reconfigure
   

보조 노드 전체의 Puma, Sidekiq 또는 geo-logcursor 데몬을 실행 중인 경우, “배포 노드”를 포함하여 모든 보조 노드에 대해

puma, sidekiq, geo-logcursor 서비스를 핫 리로드합니다:

sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq
sudo gitlab-ctl restart geo-logcursor

단계 4: 배포 후 마이그레이션 및 확인 실행

주 “배포 노드”에서

1. 배포 후 데이터베이스 마이그레이션 실행:

   sudo gitlab-rake db:migrate
   

2. Geo 구성 및 의존성 확인

   sudo gitlab-rake gitlab:geo:check
   

3. PgBouncer를 사용하는 경우:

   gitlab.rb를 PgBouncer를 가리키도록 변경하고 다음 명령을 실행하십시오:

   sudo gitlab-ctl reconfigure
   

모든 보조 “배포 노드”에서

1. Geo 데이터베이스에 특화된 배포 후 데이터베이스 마이그레이션 실행:

   sudo gitlab-rake db:migrate:geo
   

2. Geo 구성 및 의존성 확인

   sudo gitlab-rake gitlab:geo:check
   

3. Geo 상태 확인

   sudo gitlab-rake geo:status