다운타임으로 멀티 노드 인스턴스 업그레이드

다운타임이 있는 멀티 노드 Linux 패키지 기반 또는 클라우드 네이티브 인스턴스를 업그레이드합니다.

다운타임이 있는 멀티 노드 GitLab 인스턴스를 업그레이드하려면: GitLab 애플리케이션을 종료합니다. Consul 서버를 업그레이드합니다. Gitaly, Rails, PostgreSQL, Redis 및 PgBouncer를 임의의 순서로 업그레이드합니다. 클라우드 플랫폼의 PostgreSQL 또는 Redis를 사용하고 업그레이드가 필요한 경우 이 지침 대신 클라우드 공급자의 지침을 따릅니다. GitLab 애플리케이션(Sidekiq, Puma)을 업그레이드하고 애플리케이션을 시작합니다. 다운타임이 있는 업그레이드를 시작하기 전에 다운타임 옵션을 고려합니다 . GitLab 애플리케이션 종료 # 업그레이드하기 전에 GitLab 애플리케이션을 종료하여 데이터베이스에 대한 쓰기를 중지해야 합니다. 프로세스는 설치 방법 에 따라 다릅니다. Linux package (Omnibus) Helm chart (Kubernetes) 이러한 프로세스를 실행하는 모든 서버에서 Puma와 Sidekiq를 종료합니다: sudo gitlab-ctl stop sidekiq sudo gitlab-ctl stop puma Helm chart 인스턴스의 경우: 이후 재시작을 위해 데이터베이스 클라이언트의 현재 복제본 수를 기록합니다: kubectl get deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.replicas}{"\n"}{end}' 데이터베이스 클라이언트를 중지합니다: kubectl scale deploy -n <namespace> -l release=<helm release name> -l 'app in (prometheus,webservice,sidekiq)' --replicas=0 Consul 노드 업그레이드 # Consul 노드 업그레이드 에 대한 지침을 따릅니다. 요약하면: Consul 노드가 모두 정상인지 확인합니다. Linux 패키지로 업그레이드 하여 모든 Consul 서버를 업그레이드합니다. 한 번에 하나의 노드씩 모든 GitLab 서비스를 재시작합니다: sudo gitlab-ctl restart Consul 클러스터 프로세스가 자체 서버에 있지 않고 Redis HA 또는 Patroni와 같은 다른 서비스와 공유될 수 있습니다. 이 경우 해당 서버를 업그레이드할 때: 한 번에 하나의 서버에서만 서비스를 재시작합니다. 서비스를 업그레이드하거나 재시작하기 전에 Consul 클러스터가 정상인지 확인합니다. Gitaly 및 Gitaly Cluster(Praefect) 업그레이드 # Gitaly Cluster(Praefect)에 속하지 않는 Gitaly 서버의 경우 Linux 패키지로 업그레이드 하여 서버를 업그레이드합니다. 여러 Gitaly 샤드가 있는 경우 임의의 순서로 Gitaly 서버를