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 명령이 사용하는)을 실행하여 기본에 대한 정보를 가져와야 합니다.
- 다음과 같이 지정된 센티넬 노드 중 하나의 주소를 가져옵니다 gitlab_rails['redis_sentinels']./etc/gitlab/gitlab.rb
- 다음과 같이 지정된 Redis 마스터 이름을 가져옵니다 redis['master_name']. /etc/gitlab/gitlab.rb
- 다음 명령을 실행
-
sudo /opt/gitlab/embedded/bin/redis-cli -h <sentinel host> -p <sentinel port> SENTINEL get-master-addr-by-name <redis master name>
Redis 보조 노드에서
- 새 버전용 패키지를 설치합니다.
- 재구성이 설치의 일부로 실행 sudo gitlab-ctl reconfigure되지 않는 경우 실행하십시오( /etc/gitlab/skip-auto-reconfigure파일이 있기 때문에).
- reconfigure가 보류 중인 Redis/Sentinel 다시 시작에 대해 경고하는 경우 해당 서비스를 다시 시작합니다.
-
sudo gitlab-ctl restart redis sudo gitlab-ctl restart sentinel
Redis 기본 노드에서
Redis 기본 노드를 업그레이드하기 전에 최근에 업그레이드된 보조 노드 중 하나가 새 기본 노드가 되도록 장애 조치를 수행해야 합니다. 장애 조치가 완료되면 계속 진행하여 원래 기본 노드를 업그레이드할 수 있습니다.
- Redis 기본 노드에서 Redis 서비스를 중지하여 보조 노드로 장애 조치합니다.
-
sudo gitlab-ctl stop redis
- 장애 조치가 완료될 때까지 기다립니다. 위에서 언급한 것처럼 현재 Redis 기본 노드의 세부 정보를 주기적으로 확인하여 확인할 수 있습니다. 새 IP 보고를 시작하면 장애 조치가 완료된 것입니다.
- 해당 노드에서 Redis를 다시 시작하여 현재 기본 노드를 따라 시작하도록 합니다.
-
sudo gitlab-ctl start redis
- 새 버전에 해당하는 패키지를 설치합니다.
- 재구성이 설치의 일부로 실행 sudo gitlab-ctl reconfigure되지 않는 경우 실행하십시오( /etc/gitlab/skip-auto-reconfigure파일이 있기 때문에).
- reconfigure가 보류 중인 Redis/Sentinel 다시 시작에 대해 경고하는 경우 해당 서비스를 다시 시작합니다.
-
sudo gitlab-ctl restart redis sudo gitlab-ctl restart sentinel
애플리케이션 노드 업데이트
새 버전용 패키지를 설치하고 정기적인 패키지 업그레이드 절차를 따르십시오.
지리적 배포
단계의 순서가 중요합니다. 이 단계를 수행하는 동안 올바른 노드에서 올바른 순서로 수행해야 합니다.
다음을 실행하여 기본 노드 에 로그인합니다 .
- 에 빈 파일을 만듭니다 /etc/gitlab/skip-auto-reconfigure. 이렇게 하면 gitlab-ctl 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 패키지 업데이트
-
# Debian/Ubuntu sudo apt-get update && sudo apt-get install gitlab-ee # Centos/RHEL sudo yum install gitlab-ee
- 데이터베이스 마이그레이션 및 최신 코드를 제자리에 가져오려면 다음을 실행하십시오.
-
sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure
- 핫 리로드 puma및 sidekiq서비스
-
sudo gitlab-ctl hup puma sudo gitlab-ctl restart sidekiq
각 보조 노드에서 다음을 실행합니다.
- 에 빈 파일을 만듭니다 /etc/gitlab/skip-auto-reconfigure. 이렇게 하면 gitlab-ctl 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 패키지 업데이트
-
# Debian/Ubuntu sudo apt-get update && sudo apt-get install gitlab-ee # Centos/RHEL sudo yum install gitlab-ee
- 데이터베이스 마이그레이션 및 최신 코드를 제자리에 가져오려면 다음을 실행하십시오.
-
sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure
- 핫 리로드 puma및 서비스 sidekiq재시작geo-logcursor
-
sudo gitlab-ctl hup puma sudo gitlab-ctl restart sidekiq sudo gitlab-ctl restart geo-logcursor
- Geo 데이터베이스와 관련된 배포 후 데이터베이스 마이그레이션 실행
-
sudo gitlab-rake geo:db:migrate
모든 보조 노드가 업데이트된 후 기본 노드에서 업데이트를 완료합니다.
- 배포 후 데이터베이스 마이그레이션 실행
-
sudo gitlab-rake db:migrate
모든 노드( 기본 및 모든 보조 모두 )를 업데이트한 후 상태를 확인합니다.
- 지리적 구성 및 종속성 확인
-
sudo gitlab-rake gitlab:geo:check
향후 다운타임 없는 업그레이드를 실행하지 않으려면 이 단계를 완료한 후 /etc/gitlab/skip-auto-reconfigure설정을 제거하고 되돌리 gitlab_rails['auto_migrate'] = false십시오 ./etc/gitlab/gitlab.rb
'GitLab_가이드' 카테고리의 다른 글
컨테이너에서 GitLab Runner 실행 (0) | 2022.08.02 |
---|---|
Geo를 사용한 다중 노드/HA 배포 (0) | 2022.08.02 |
PostgreSQL HA 사용 (0) | 2022.08.02 |
다중 노드/HA 배포 (0) | 2022.08.02 |
다운타임 없는 업그레이드 (0) | 2022.08.01 |