영점 다운타임 업그레이드

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

GitLab의 새로운 주요, 마이너 또는 패치 버전으로 업그레이드할 수 있습니다. GitLab 인스턴스를 오프라인 상태로 만들지 않고도 업그레이드할 수 있습니다. 그러나 이를 위해 다음과 같은 요구 사항이 있습니다:

한 번에 한 개의 마이너 릴리스만 업그레이드할 수 있습니다. 따라서 13.1에서 13.2로 업그레이드해야 하며 13.3으로는 업그레이드할 수 없습니다. 릴리스를 건너뛰면 데이터베이스 수정이 잘못된 순서로 실행될 수 있으며 데이터베이스 스키마가 손상된 상태로 남을 수 있습니다.
포스트-배포 마이그레이션(post-deployment migrations)을 사용해야 합니다.
PostgreSQL을 사용해야 합니다. GitLab 12.1부터 MySQL은 지원되지 않습니다.
Multi-node GitLab 인스턴스를 설정해야 합니다. 클라우드 네이티브 하이브리드 설치는 영점 다운타임 업그레이드를 지원하지 않습니다.

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

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

Deployment type	Description
Gitaly 또는 Gitaly 클러스터	Gitaly 또는 Gitaly 클러스터를 위한 GitLab CE/EE HA 아키텍처
멀티 노드 / PostgreSQL HA	PostgreSQL을 위한 GitLab CE/EE HA 아키텍처
멀티 노드 / Redis HA	Redis를 위한 GitLab CE/EE HA 아키텍처
Geo	Geo가 활성화된 GitLab EE
멀티 노드 / Geo와 HA	여러 노드에서 GitLab CE/EE

각 배포 유형에는 이후 해당 서비스를 실행하는 모든 노드에서 puma 및 sidekiq 프로세스를 핫 리로드해야 합니다. 이유는 이러한 프로세스마다 GitLab Rails 애플리케이션을 로드하여 시작할 때 데이터베이스 스키마를 메모리로 읽고 로드하기 때문입니다. 이러한 각각의 프로세스는 배포 후 마이그레이션에 의해 발생한 데이터베이스 변경 내용을 다시 읽기 위해 리로드(또는 sidekiq의 경우 재시작)해야 합니다.

대부분의 경우, 최신 패치 릴리스가 아닌 경우 다음 마이너 릴리스로 안전하게 업그레이드할 수 있습니다. 예를 들어, 14.1.1에서 14.2.0으로 업그레이드하는 것은 14.1.2가 출시되었더라도 안전할 것입니다. 그러나 현재 버전과 대상 버전 사이에 포함된 마이그레이션이 추가되었는지 확인하는 것을 권장합니다.

또한 업그레이드 경로와 관련된 버전별 업그레이드 지침을 확인할 것을 권장합니다.

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

특정 주요/마이너 릴리스에는 완료해야 하는 일련의 백그라운드 마이그레이션이 필요할 수 있습니다. 이를 보장하기 위해 해당 릴리스는 업그레이드 절차를 계속하기 전에 남아있는 작업을 처리합니다. 이는 오프라인 상태가 필요하지 않습니다(위의 조건을 충족하는 경우), 그러나 각 주요/마이너 릴리스 업그레이드 사이에는 백그라운드 마이그레이션의 완료를 기다려야만 합니다. 이러한 마이그레이션을 완료하는 데 필요한 시간은 background_migration 큐에서 작업을 처리할 수 있는 Sidekiq 작업자의 수를 늘림으로써 줄일 수 있습니다. 이 큐의 크기를 확인하려면 업그레이드 전 백그라운드 마이그레이션 확인을 참조하십시오.

일반적인 경우, 10GB 미만의 데이터베이스는 업그레이드하는 데 많은 시간이 소요되지 않습니다. 아마도 마이너 릴리스 당 최대 한 시간 정도일 것입니다. 그러나 더 큰 데이터베이스는 더 많은 시간이 필요할 수 있지만, 이는 데이터베이스의 크기와 수행 중인 마이그레이션에 크게 의존합니다.

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

예제 1: 13.4.2 버전을 사용하는 큰 규모의 GitLab 설치가 실행 중이며, 이는 13.4 버전의 최신 패치 릴리스입니다. GitLab 13.5.0이 출시되면 이 설치는 상기된 요구 사항을 충족하는 경우 다운타임 없이 13.5.0으로 안전하게 업그레이드할 수 있습니다. 또한 13.5.0으로 건너뛰어 13.5.1로 업그레이드할 수 있지만, 13.6.0으로 바로 업그레이드할 수 없습니다. 반드시 먼저 13.5.Z 릴리스로 업그레이드해야 합니다.

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

예제 3: GitLab의 데이터베이스로 MySQL을 사용 중입니다. 새로운 주요/마이너 릴리스로의 업그레이드에는 다운타임이 필요합니다. 릴리스에 백그라운드 마이그레이션이 포함되어 있다면 데이터베이스 크기에 따라 수십 시간의 다운타임이 필요할 수 있습니다. 이를 해결하기 위해 PostgreSQL을 사용하고 상기된 온라인 업그레이드 요구 사항을 충족해야 합니다.

Multi-node / HA 배포

경고: 한 번에 한 개의 마이너 릴리스만 업그레이드할 수 있습니다. 따라서 15.6에서 15.7로 가는 것이 아니라 15.8로 가지 않아야 합니다. 한 번에 여러 마이너 릴리스를 시도하면 업그레이드가 실패할 수 있습니다.

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

Puma를 사용하면 단일 노드로는 다운타임 없는 업데이트가 더 이상 불가능합니다. 다운타임 없는 업데이트를 위해 적어도 두 개의 노드가 로드 밸런서와 함께 사용되어 연결을 올바르게 분배해야 합니다.

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

웹(Puma) 노드의 업그레이드는 롤링 방식으로 하나씩 연속해서 이루어져야 하며, 항상 적어도 한 개의 노드가 트래픽을 제공할 수 있도록해야 합니다. 이는 다운타임이 없도록 보장하기 위해 필요합니다.

업그레이드의 일환으로 Puma는 노드가 계속해서 연결을 수락하지만 각각의 상태 체크 엔드포인트를 정상 여부가 아닌 것으로 표시하는 검은 기간에 진입합니다. 이를 보고 로드 밸런서는 안전하게 연결을 해제해야 합니다.

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

다음 순서대로 노드를 업데이트해야 하며, 최신 GitLab 버전을 사용하는 HA 인스턴스를 업데이트합니다.

배포 노드로 사용할 응용 프로그램 노드를 선택하고 다음 단계를 완료합니다.
1. /etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 기본적으로 GitLab을 자동으로 중지시키고 모든 데이터베이스 마이그레이션을 실행한 후 GitLab을 다시 시작하는 gitlab-ctl reconfigure가 업그레이드되지 않습니다.
```
 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
```
다음 순서대로 다른 Puma/Sidekiq 노드에서 다음 단계를 완료합니다. 다음 노드로 진행하기 전에 항상 적어도 하나의 노드가 실행 중이고 로드 밸런서에 연결되어 있는지 확인합니다.
1. Gitaly 노드를 업그레이드하고, 필요하다면 (/etc/gitlab/skip-auto-reconfigure 파일로 인해) reconfigure가 수동으로 실행되지 않도록 합니다.
2. 서비스가 최신 코드를 사용하는지 확인합니다.
```
sudo gitlab-ctl hup puma
sudo gitlab-ctl restart sidekiq
```
배포 노드에서 포스트-배포 마이그레이션을 실행합니다.
```
   sudo gitlab-rake db:migrate
```

Gitaly 또는 Gitaly Cluster

Gitaly 노드는 따로 있는 서버에 위치할 수 있으며 이는 샤딩 설정 또는 Gitaly Cluster의 일부로 사용될 수 있습니다.

GitLab 애플리케이션의 주요 업그레이드를 진행하기 전에 다음을 (순서대로) 수행해야 합니다:

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

알려진 이슈로 인해 Gitaly 및 Gitaly Cluster 업그레이드는 약간의 다운타임을 야기합니다.

Gitaly 노드 업그레이드

별도의 서버에 위치한 Gitaly 노드에서 GitLab 패키지를 한 번에 한 대씩 업그레이드하여 Git 저장소에 대한 액세스를 유지합니다.

Praefect 업그레이드

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

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가 설정되어 있는지 확인합니다.
나머지 Praefect 노드에서는 /etc/gitlab/gitlab.rb에서 praefect['auto_migrate'] = false가 설정되어 있어야 합니다.
Praefect 배포 노드에서:
1. GitLab 패키지를 업그레이드합니다.
2. Praefect 데이터베이스 마이그레이션을 적용하고 Praefect를 다시 시작하려면 다음을 실행합니다:
```
sudo gitlab-ctl reconfigure
```
나머지 Praefect 노드에서:
1. GitLab 패키지를 업그레이드합니다.
2. 노드가 최신 코드를 실행하도록 합니다:
```
sudo gitlab-ctl reconfigure
```

PostgreSQL

배포 노드를 지정하세요. 어떤 애플리케이션 노드든 상관없지만, 프로세스 전체에서는 동일한 노드여아 합니다.

배포 노드

/etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 함으로써 업그레이드가 gitlab-ctl reconfigure를 자동으로 실행하는 것을 방지할 수 있습니다. 이 명령은 기본적으로 GitLab을 자동으로 중지시키고 모든 데이터베이스 마이그레이션을 실행하고 GitLab을 재시작합니다.
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```

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

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

PostgreSQL 전용 노드

GitLab 패키지를 업그레이드합니다.
노드가 최신 코드를 실행하고 있는지 확인합니다.
```
sudo gitlab-ctl reconfigure
```

배포 노드

GitLab 패키지를 업그레이드합니다.
PgBouncer를 사용하는 경우:
마이그레이션을 실행하기 전에 반드시 PgBouncer를 우회하고 데이터베이스 리더에 직접 연결해야 합니다.
Rails는 마이그레이션 실행을 시도할 때 동시 마이그레이션을 방지하기 위해 consultative lock을 사용합니다. 이러한 lock은 트랜잭션을 통해 공유되지 않기 때문에 트랜잭션 풀링 모드의 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 (using Sentinel)

Tier: Premium, Ultimate Offering: Self-managed

패키지 업그레이드에는 번들된 Redis 서비스의 버전 업데이트가 포함될 수 있습니다. 확장 용도의 Redis를 사용하는 인스턴스의 경우, downtime을 최소화하기 위해 업그레이드는 아래 지정된 순서를 따라야 합니다. 본 문서는 Redis HA를 설정하기 위해 공식 가이드가 따르고 있다고 가정합니다.

애플리케이션 노드에서

공식 Redis 문서에 따르면 Sentinel을 사용하여 HA 인스턴스를 업데이트하는 가장 쉬운 방법은 두 번째 노드부터 하나씩 업그레이드하고, 현재 기존 버전을 실행 중인 주된(primary) Redis에서 최근에 업그레이드한 보조(secondary)로 수동 장애 조치를 수행하고, 그런 다음 기존 주된을 업그레이드하는 것입니다. 이를 위해 현재 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']로 지정된 sentinel 노드 중 하나의 주소를 가져옵니다.
2. /etc/gitlab/gitlab.rb에 redis['master_name']으로 지정된 Redis 메인 이름을 가져옵니다.
3. 다음 명령을 실행합니다.
```
sudo /opt/gitlab/embedded/bin/redis-cli -h <sentinel 호스트> -p <sentinel 포트> SENTINEL get-master-addr-by-name <redis 메인 이름>
```

Redis 보조 노드에서

이미 설정하지 않은 경우 gitlab.rb에서 gitlab_rails['rake_cache_clear'] = false를 설정하세요. 설정하지 않은 경우 새로운 패키지 설치 후 리콘피규레이션 중 Redis::CommandError: READONLY You can't write against a read only replica. 오류가 발생할 수 있습니다.
새 버전을 위한 패키지를 설치하세요.
설치 과정에서 리콘피규레이션이 실행되지 않은 경우(이는 /etc/gitlab/skip-auto-reconfigure 파일이 존재하는 경우), 다음을 실행하세요.
```
sudo gitlab-ctl reconfigure
```
리콘피규레이션이 Redis/Sentinel 재시작을 경고하는 경우, 해당 서비스를 재시작하세요.
```
sudo gitlab-ctl restart redis
sudo gitlab-ctl restart sentinel
```

Redis 주 노드에서

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

보조 노드로 장애 조치시키기 위해 Redis 서비스를 중지하세요.
```
sudo gitlab-ctl stop redis
```
장애 조치가 완료될 때까지 기다리세요. 주 Redis 노드의 세부 정보를 주기적으로 확인하여 새 IP가 보고되기 시작하면 장애 조치가 완료된 것입니다.
해당 노드에서 Redis를 다시 시작하여 현재 주 노드를 따르도록 하세요.
```
sudo gitlab-ctl start redis
```
새 버전에 해당하는 패키지를 설치하세요.
설치 과정에서 리콘피규레이션이 실행되지 않은 경우(이는 /etc/gitlab/skip-auto-reconfigure 파일이 존재하는 경우), 다음을 실행하세요.
```
sudo gitlab-ctl reconfigure
```
리콘피규레이션이 Redis/Sentinel 재시작을 경고하는 경우, 해당 서비스를 재시작하세요.
```
sudo gitlab-ctl restart redis
sudo gitlab-ctl restart sentinel
```

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

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

Geo 배포

Tier: Premium, Ultimate Offering: Self-Managed

한 번에 하나의 마이너 업그레이드만 수행할 수 있습니다.

단계의 순서가 중요합니다. 이러한 단계를 따를 때, 올바른 순서로 올바른 노드에 따라가는지 확인하세요.

Geo 주 사이트 업데이트

주 사이트에 로그인하여 다음을 실행하세요.

/etc/gitlab/skip-auto-reconfigure에 빈 파일을 만드세요. 이렇게 하면 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 수행하며 GitLab을 재시작하는 업그레이드가 실행되지 않습니다.
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
/etc/gitlab/gitlab.rb를 편집하고 다음이 포함되어 있는지 확인하세요.
```
gitlab_rails['auto_migrate'] = false
```
GitLab을 다시 구성하세요.
```
sudo gitlab-ctl reconfigure
```
GitLab 패키지 업그레이드.
노드가 업데이트되고 리콘피규레이션이 성공적으로 완료되면 마이그레이션을 실행하세요.
```
sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate
```
중요: /etc/gitlab/gitlab-secrets.json 파일을 기본 사이트에서 보조 사이트로 복사하세요. 파일은 사이트의 모든 노드에서 동일해야 합니다.

Geo 보조 사이트 업데이트

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

/etc/gitlab/skip-auto-reconfigure에 빈 파일을 만드세요. 이렇게 하면 기본적으로 GitLab을 자동으로 중지하고 모든 데이터베이스 마이그레이션을 수행하며 GitLab을 재시작하는 업그레이드가 실행되지 않습니다.
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
/etc/gitlab/gitlab.rb를 편집하고 다음이 포함되어 있는지 확인하세요.
```
gitlab_rails['auto_migrate'] = false
```
GitLab을 다시 구성하세요.
```
sudo gitlab-ctl reconfigure
```
GitLab 패키지 업그레이드.
노드가 업데이트되고 리콘피규레이션이 성공적으로 완료된 경우, Geo 데이터베이스에 특화된 후배치 데이터베이스 마이그레이션을 실행하세요.
```
sudo gitlab-rake db:migrate:geo
```

업데이트 완료

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

후배치 데이터베이스 마이그레이션 실행
```
sudo gitlab-rake db:migrate
```
주 노드에서 업데이트가 완료된 후 모든 주 및 보조 노드의 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 설정을 되돌려야 합니다.

Multi-node / HA 배포와 Geo

Tier: 프리미엄, 얼티메이트 Offering: Self-managed

경고:
한 번에 하나의 마이너 릴리스만 업그레이드할 수 있습니다. 또한 먼저 Gitaly 클러스터를 시작해야 하며, Gitaly를 한 번에 한 노드씩 업데이트해야 합니다. 이렇게 함으로써 업그레이드 프로세스의 나머지 부분에서 Git 저장소에 액세스할 수 있습니다.

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

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

Geo primary multi-node 배포 업데이트
Geo secondary multi-node 배포 업데이트
배포 후 마이그레이션 및 확인

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

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

Geo primary multi-node 배포의 primary “배포 노드”로 사용할 인스턴스 하나
각 Geo secondary multi-node 배포의 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 primary multi-node 배포 업데이트

모든 primary 노드(및 primary “배포 노드”를 포함한)에서

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

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

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

primary Gitaly 전용 노드에서

GitLab 패키지를 업그레이드합니다.
노드가 최신 코드를 실행하고 있는지 확인합니다
```
sudo gitlab-ctl reconfigure
```

primary “배포 노드”에서

GitLab 패키지를 업그레이드합니다.
PgBouncer를 사용 중인 경우:
데이터베이스 마이그레이션을 실행하기 전에 반드시 PgBouncer를 우회하고 데이터베이스 리더에 직접 연결해야 합니다.
Rails는 동시 마이그레이션을 방지하기 위해 마이그레이션을 실행하려고 할 때 advisory lock을 사용합니다. 이러한 잠금은 트랜잭션 간에 공유되지 않으며, 트랜잭션 풀링 모드에서 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
```
이 배포 노드가 서비스를 제공하거나 작업을 처리하는 경우, 이 단계에서 서비스를 되돌릴 수 있습니다.
- 요청을 서비스하기 위해 배포 노드를 로드 밸런서에 추가합니다.
- Sidekiq 작업을 다시 처리하려면 Sidekiq를 시작합니다:
```
sudo gitlab-ctl start sidekiq
```

primary “배포 노드”를 포함한 모든 primary 노드 제외

GitLab 패키지를 업그레이드합니다.
노드가 최신 코드를 실행하고 있는지 확인합니다
```
sudo gitlab-ctl reconfigure
```

primary 노드 중 Puma 또는 Sidekiq를 실행하는 모든 primary 노드(및 primary “배포 노드”를 포함한)

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

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

primary 사이트와 secondary 사이트가 다른 경우 primary 사이트에서 /etc/gitlab/gitlab-secrets.json 파일을 secondary 사이트로 복사합니다.
파일은 사이트의 모든 노드에서 동일해야 합니다.

단계 3: 각 Geo 보조 다중 노드 배포 업데이트

Geo primary 다중 노드 배포의 모든 단계를 성공적으로 완료한 경우에만 진행하십시오.

모든 보조 노드 및 “배포 노드”를 포함한 모든 보조 노드에서

/etc/gitlab/skip-auto-reconfigure에 빈 파일을 생성합니다. 이렇게 하면 기본적으로 GitLab을 자동으로 중지시키고 모든 데이터베이스 마이그레이션을 실행한 후 GitLab을 다시 시작하는 업그레이드가 실행되지 않습니다.
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
데이터베이스 마이그레이션의 자동 실행을 방지하려면 /etc/gitlab/gitlab.rb에 geo_secondary['auto_migrate'] = false로 설정되어 있는지 확인하십시오.
노드가 최신 코드를 실행하도록 합니다.
```
sudo gitlab-ctl reconfigure
```

보조 Gitaly 전용 노드에서만

GitLab 패키지를 업그레이드하십시오.
노드가 최신 코드를 실행하도록 합니다.
```
sudo gitlab-ctl reconfigure
```

“배포 노드”에서만

GitLab 패키지를 업그레이드하십시오.
일반적인 데이터베이스 마이그레이션 및 최신 코드를 가져오려면 다음을 실행하십시오.
```
sudo gitlab-ctl reconfigure
sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-rake db:migrate:geo
```
이 배포 노드가 요청을 처리하거나 백그라운드 처리를 수행하는 경우 이 단계에서 해당 서비스를 재개할 수 있습니다.
- 요청을 처리하려면 배포 노드를 로드 밸런서에 추가하십시오.
- Sidekiq 작업을 다시 처리하려면 Sidekiq를 시작하십시오:
```
sudo gitlab-ctl start sidekiq
```
- Geo 이벤트를 다시 처리하려면 geo-logcursor 데몬을 시작하십시오:
```
sudo gitlab-ctl start geo-logcursor
```

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

GitLab 패키지를 업그레이드하십시오.
노드가 최신 코드를 실행하도록 합니다.
```
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: 배포 후 마이그레이션 및 확인 실행

주요 “배포 노드”에서

배포 후 데이터베이스 마이그레이션 실행:
```
sudo gitlab-rake db:migrate
```
Geo 구성 및 종속 항목 확인
```
sudo gitlab-rake gitlab:geo:check
```
PgBouncer를 사용하는 경우:
gitlab.rb를 다시 PgBouncer로 지정하고 다음을 실행하십시오:
```
sudo gitlab-ctl reconfigure
```

모든 “배포 노드”에서

Geo 데이터베이스에 특화된 배포 후 데이터베이스 마이그레이션 실행:
```
sudo gitlab-rake db:migrate:geo
```
Geo 구성 및 종속 항목 확인
```
sudo gitlab-rake gitlab:geo:check
```
Geo 상태 확인
```
sudo gitlab-rake geo:status
```

영점 다운타임 업그레이드

Multi-node / HA 배포

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

Gitaly 또는 Gitaly Cluster

Gitaly 노드 업그레이드

Praefect 업그레이드

PostgreSQL

Redis HA (using Sentinel)

애플리케이션 노드에서

Redis 보조 노드에서

Redis 주 노드에서

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

Geo 배포

Geo 주 사이트 업데이트

Geo 보조 사이트 업데이트

업데이트 완료

Multi-node / HA 배포와 Geo

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

단계 2: Geo primary multi-node 배포 업데이트

단계 3: 각 Geo 보조 다중 노드 배포 업데이트

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

도움말

기능 사용 가능성과 제품 평가판

도움받기