다운타임 없는 업그레이드

GitLab 인스턴스를 오프라인으로 전환하지 않고도 GitLab의 최신 메이저, 마이너 또는 패치 버전으로 업그레이드할 수 있습니다. 그러나 이것이 작동하려면 다음 요구 사항이 있습니다.

• 한 번에 하나의 부 릴리스만 업그레이드할 수 있습니다. 따라서 13.3이 아닌 13.1에서 13.2로. 릴리스를 건너뛰면 데이터베이스 수정이 잘못된 순서로 실행되고 데이터베이스 스키마가 손상된 상태로 남을 수 있습니다 .
• 배포 후 마이그레이션 을 사용해야 합니다 .
• PostgreSQL을 사용하고 있습니다. GitLab 12.1부터 MySQL은 지원되지 않습니다.
• 다중 노드 GitLab 인스턴스. 단일 노드 인스턴스는 서비스가 다시 시작될 때 잠시 중단될 수 있습니다(특히 Puma) .

위의 모든 요구 사항을 충족하는 경우 다음 지침을 순서대로 따르십시오. 배포 유형에 따라 세 가지 단계 세트가 있습니다.

배포 유형설명

단일 노드	단일 노드의 GitLab CE/EE
지탈리 클러스터	Gitaly Cluster용 HA 아키텍처를 사용하는 GitLab CE/EE
다중 노드 / PostgreSQL HA	PostgreSQL용 HA 아키텍처를 사용하는 GitLab CE/EE
다중 노드 / Redis HA	Redis용 HA 아키텍처를 사용하는 GitLab CE/EE
지역	지역이 활성화된 GitLab EE
다중 노드 / HA(Geo 포함)	여러 노드의 GitLab CE/EE

각 배포 유형에서는 업그레이드한 후 이러한 서비스를 실행하는 모든 노드에서 핫 리로드 puma및 프로세스가 필요합니다. sidekiq그 이유는 이러한 프로세스가 시작할 때 데이터베이스 스키마를 읽고 메모리로 로드하는 GitLab Rails 애플리케이션을 각각 로드하기 때문입니다. sidekiq배포 후 마이그레이션에 의해 수행된 데이터베이스 변경 사항을 다시 읽으려면 이러한 각 프로세스를 다시 로드(또는 의 경우 다시 시작해야 함 )해야 합니다.

대부분의 경우 패치 릴리스가 최신 버전이 아닌 경우 패치 릴리스에서 다음 부 릴리스로 안전하게 업그레이드할 수 있습니다. 예를 들어 14.1.1에서 14.2.0으로 업그레이드하는 것은 14.1.2가 릴리스된 경우에도 안전해야 합니다. 한 번에 하나의 릴리스를 업그레이드해야 하는 마이그레이션이 포함된 경우를 대비하여 현재 버전과 대상 버전 사이의 릴리스 게시물을 확인하는 것이 좋습니다.

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

특정 주/부 릴리스를 완료하려면 백그라운드 마이그레이션 세트가 필요할 수 있습니다. 이를 보장하기 위해 이러한 릴리스는 업그레이드 절차를 계속하기 전에 나머지 작업을 처리합니다. 가동 중지 시간이 필요하지 않지만(위의 조건이 충족되는 경우) 각 주/부 릴리스 업그레이드 사이 에 백그라운드 마이그레이션이 완료될 때까지 기다려야 합니다 . background_migration대기열 의 작업을 처리할 수 있는 Sidekiq 작업자의 수를 늘리면 이러한 마이그레이션을 완료하는 데 필요한 시간을 줄일 수 있습니다 . 이 대기열의 크기를 보려면 업그레이드하기 전에 백그라운드 마이그레이션을 확인하십시오 .

지침에 따르면 10GB보다 작은 데이터베이스는 업그레이드하는 데 너무 많은 시간이 걸리지 않습니다. 마이너 릴리스당 최대 1시간. 그러나 더 큰 데이터베이스는 더 많은 시간이 필요할 수 있지만 이는 데이터베이스의 크기와 수행 중인 마이그레이션에 따라 크게 달라집니다.

이를 설명하는 데 도움이 되도록 몇 가지 예를 살펴보겠습니다.

예 1: 13.4의 최신 패치 릴리스인 버전 13.4.2를 사용하여 대규모 GitLab 설치를 실행하고 있습니다. GitLab 13.5.0이 출시되면 위에서 언급한 요구 사항이 충족되면 가동 중지 시간 없이 이 설치를 13.5.0으로 안전하게 업그레이드할 수 있습니다. 13.5.0을 건너뛰고 릴리스된 후 13.5.1로 업그레이드할 수도 있지만 13.6.0으로 바로 업그레이드 할 수는 없습니다 . 먼저 13.5.Z 릴리스로 업그레이드해야 합니다 .

예 2: 13.4의 최신 패치 릴리스인 버전 13.4.2를 사용하여 대규모 GitLab 설치를 실행하고 있습니다. GitLab 13.5에는 일부 백그라운드 마이그레이션이 포함되어 있으며 14.0에서는 이러한 마이그레이션을 완료해야 합니다(나머지 작업 처리). 다운타임 없이 13.5를 건너뛸 수 없으며 백그라운드 마이그레이션으로 인해 백그라운드 마이그레이션이 완료되는 데 걸리는 시간에 따라 잠재적으로 몇 시간의 다운타임이 필요할 수 있습니다. 이 문제를 해결하려면 먼저 13.5.Z로 업그레이드한 다음 14.0으로 업그레이드하기 전에 최소 일주일을 기다려야 합니다.

예 3: MySQL을 GitLab의 데이터베이스로 사용합니다. 새로운 주/부 릴리스로 업그레이드하려면 가동 중지 시간이 필요합니다. 릴리스에 백그라운드 마이그레이션이 포함된 경우 데이터베이스 크기에 따라 잠재적으로 몇 시간의 가동 중지 시간이 발생할 수 있습니다. 이 문제를 해결하려면 PostgreSQL을 사용하고 위에서 언급한 다른 온라인 업그레이드 요구 사항을 충족해야 합니다.

단일 노드 배포

이 지침을 따르기 전에 다음 중요 정보 에 유의하십시오.

• 한 번에 하나의 부 릴리스만 업그레이드할 수 있습니다. 따라서 13.6에서 13.7로, 13.8에서는 아닙니다. 부 릴리스를 두 개 이상 시도하면 업그레이드가 실패할 수 있습니다.
• 단일 노드 Omnibus 배포에서 Puma는 항상 완전한 재시작이 필요하기 때문에 Puma를 사용할 때 가동 중지 시간이 없는 업데이트는 불가능합니다. 이는 Puma의 단계별 재시작 기능이 GitLab 올인원 패키지(앱 사전 로드가 있는 클러스터 모드)에서 구성된 방식으로 작동하지 않기 때문입니다.
• 이 지침을 따르면 단일 노드 인스턴스에서 가동 중지 시간을 최소화할 수 있지만 항상 가동 중지 시간 업데이트를 0으로 만드는 것은 불가능합니다 . 다시 시작해야 하는 서비스에 따라 일부 연결 시간 초과가 표시되거나 몇 분 동안 거부될 수 있습니다.
• Omnibus 배포에서는 구성/etc/gitlab/gitlab.rb 파일 에 . gitlab_rails['auto_migrate'] = true

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

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

3. GitLab 패키지를 업데이트합니다.
   • GitLab 엔터프라이즈 에디션 의 경우 :

   • # Debian/Ubuntu
               sudo apt-get update
               sudo apt-get install gitlab-ee
               
               # Centos/RHEL
               sudo yum install gitlab-ee
               

   • GitLab 커뮤니티 에디션의 경우:

   • # Debian/Ubuntu
               sudo apt-get update
               sudo apt-get install gitlab-ce
               
               # Centos/RHEL
               sudo yum install gitlab-ce
               

4. 정기적인 마이그레이션과 최신 코드를 얻으려면 다음을 실행하십시오.

5. sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure
         

6. 노드가 업데이트되고 reconfigure성공적으로 완료되면 다음을 사용하여 배포 후 마이그레이션을 실행합니다.

7. sudo gitlab-rake db:migrate
         

8. 핫 리로드 puma및 sidekiq서비스

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

앞으로 제로 다운타임 업그레이드를 실행하지 않으려면 /etc/gitlab/skip-auto-reconfigure이 단계를 완료한 후 제거해야 합니다.