GitLab 업그레이드 계획 작성
이 문서는 Self-Managed GitLab 인스턴스를 업그레이드하기 위한 강력한 계획을 작성하는 가이드로 사용됩니다.
일반 사항:
- 가능하다면, 본인의 프로덕션 인스턴스를 업데이트하기 전에 테스트 환경에서 업그레이드를 테스트해야 합니다. 이상적으로, 귀하의 테스트 환경은 귀하의 프로덕션 환경과 최대한 유사하게 모방되어야 합니다.
-
지원팀과 작업을 하는 경우, 아키텍처의 세부 정보를 공유하세요. 이에는 다음이 포함됩니다:
- GitLab가 어떻게 설치되었는가?
- 노드의 운영 체제는 무엇인가요? (나중의 업데이트가 가능한지 확인하려면 지원되지 않는 OS 버전을 확인하세요).
- 단일 노드인가요, 아니면 멀티 노드 설정인가요? 멀티 노드를 사용하는 경우, 각 노드에 대한 아키텍처 세부 정보를 공유해 주세요.
- GitLab Geo를 사용하고 있는가요? 그렇다면, 각 보조 노드에 대한 아키텍처 세부 정보를 공유해 주세요.
- 귀하의 설정에서 중요할 수 있는 고유하거나 흥미로운 요소가 무엇인가요?
- 현재 GitLab 버전에서 알려진 문제에 부딪히고 있나요?
업그레이드 전과 후 확인 사항
업그레이드 직전과 직후에, GitLab의 주요 구성 요소가 작동하는지 확인하기 위해 업그레이드 전과 후 확인을 수행하세요:
-
sudo gitlab-rake gitlab:check
-
암호화된 데이터베이스 값이 해독될 수 있는지 확인:
sudo gitlab-rake gitlab:doctor:secrets
- GitLab UI에서 다음을 확인하세요:
- 사용자가 로그인할 수 있는지.
- 프로젝트 목록이 표시되는지.
- 프로젝트 이슈 및 병합 요청에 접근 가능한지.
- 사용자가 GitLab에서 저장소를 복제할 수 있는지.
- 사용자가 GitLab에 커밋을 푸시할 수 있는지.
- GitLab CI/CD의 경우, 다음을 확인하세요:
- 러너가 작업을 가져가는지.
- Docker 이미지가 레지스트리에서 푸시 및 풀할 수 있는지.
-
Geo를 사용하는 경우, 기본 및 각 보조 노드에 대해 관련 확인을 실행하세요:
sudo gitlab-rake gitlab:geo:check
- Elasticsearch를 사용하는 경우, 검색이 성공적으로 이루어지는지 확인하세요.
만약 무슨 문제가 발생한다면, 문제 해결 방법을 참조하세요.
롤백 계획
업그레이드 중에 문제가 발생할 수 있기 때문에, 해당 시나리오의 롤백 계획이 존재하는 것이 매우 중요합니다. 적절한 롤백 계획은 인스턴스를 최근 작동 상태로 되돌릴 수 있는 명확한 경로를 만듭니다. 이것은 인스턴스를 백업하고 복원하는 방법으로 이루어집니다.
GitLab 백업
GitLab 및 모든 데이터 (데이터베이스, 저장소, 업로드, 빌드, 아티팩트, LFS 객체, 레지스트리, 페이지)의 백업을 만드세요. 이렇게 함으로써, 업그레이드에 문제가 발생하는 경우 GitLab을 이전의 작동 상태로 롤백할 수 있습니다:
- GitLab 백업을 만드는 방법을 따르세요. 설치 방법에 따라 지침을 따르십시오. 비밀 및 구성 파일을 백업하는 것을 잊지 마세요.
- 또는 인스턴스의 스냅샷을 만드세요. 여러 노드로 구성된 설치인 경우 각 노드를 스냅샷해야 합니다. 이 프로세스는 GitLab 지원 범위를 벗어납니다.
GitLab 복원
프로덕션 환경을 모방하는 테스트 환경이 있다면, 모든 것이 예상대로 작동하는지 확인하기 위해 복원을 테스트해야 합니다.
GitLab 백업을 복원하려면:
- 복원하기 전에, 준비 사항을 확인하세요. 특히, 백업된 GitLab 버전과 새 GitLab 인스턴스의 버전이 반드시 동일해야 합니다.
- GitLab 복원을 수행하세요. 설치 방법에 따라 지침을 따르십시오. 비밀 및 구성 파일이 복원되었는지 확인하세요.
- 스냅샷으로 부터 복원하는 경우, 이를 수행하는 방법을 알아두세요. 이 프로세스는 GitLab 지원 범위를 벗어납니다.
업그레이드 계획
업그레이드 계획을 위해서, 먼저 귀하의 인스턴스에 최적화되는 계획 개요를 작성한 후 사용하는 관련 기능에 대해 업그레이드하세요.
- 관련 문서를 읽고 이해하여 업그레이드 계획을 생성하세요:
- 어떤 버전으로 업그레이드해야 하는가:
- 따를 업그레이드 경로를 결정하세요.
- 현재 버전 및 대상 버전의 버전별 업데이트 지침을 고려하세요.
- 버전별 변경 사항을 고려하세요.
- 대상 GitLab 버전과의 OS 호환성을 확인하세요.
- 백그라운드 마이그레이션으로 인해, 추가 업그레이드를 진행하기 전에 일시적으로 일시 중지할 계획을 세우세요. 모든 마이그레이션이 완료되어야 합니다.
- 시작 버전에서 사용 가능한 경우, 업그레이드 동안 유지 보수 모드를 사용할 수 있습니다.
- PostgreSQL에 관한 사항:
- 왼쪽 사이드바에서 맨 아래에서 Admin Area를 선택하세요.
- 사용 중인 PostgreSQL 버전을 확인하세요. PostgreSQL 업그레이드가 필요한 경우, 관련 패키지 또는 비패키지 단계를 고려하세요.
추가 기능
일반 정보 외에도 특별한 계획이 필요한 기능을 활성화할 수 있습니다.
설정에 적용되지 않는 기능에 대한 섹션은 무시해도 괜찮습니다. 예를 들어, Geo, 외부 Gitaly, 또는 Elasticsearch와 관련된 섹션은 무시해도 됩니다.
외부 Gitaly
외부 Gitaly 서버를 사용하는 경우, 응용 프로그램 서버를 업그레이드하기 전에 외부 Gitaly 서버를 최신 버전으로 업그레이드해야 합니다.
Geo
Geo를 사용하는 경우:
- Geo 업그레이드 설명서를 검토하세요.
- Geo 버전별 업데이트 지침에 대해 알아보세요.
- 데이터베이스를 업그레이드할 때 Geo별 단계를 검토하세요.
- 각 Geo 사이트(기본 및 각 보조)에 대한 업그레이드 및 롤백 계획을 수립하세요.
러너
GitLab을 업데이트한 후, 러너를 새 GitLab 버전에 맞게 업그레이드하세요.
Kubernetes용 GitLab 에이전트
GitLab과 연결된 Kubernetes 클러스터가 있는 경우, 새 GitLab 버전에 맞게 GitLab Kubernetes 에이전트를 업그레이드하세요.
Elasticsearch
GitLab을 업데이트하기 전에, 진행 중인 고급 검색 마이그레이션이 완료되었는지 확인하세요. 보류 중인 고급 검색 마이그레이션을 확인하여 확인하세요.
GitLab을 업데이트한 후, 새 버전이 호환성을 깨뜨린 경우 Elasticsearch를 업그레이드해야 할 수 있습니다. Elasticsearch의 업그레이드는 GitLab 지원 범위를 벗어납니다.
문제 해결
만약 예기치 않은 문제가 발생했다면:
- 시급한 경우 오류를 복사하고 로그를 수집하여 나중에 분석하고, 그 후 마지막 작동 버전으로 롤백하세요. 데이터 수집을 돕는 다음 도구를 사용할 수 있습니다:
- 지원이 필요한 경우:
- GitLab 지원팀에 문의하고, 고객 관리 담당자가 있는 경우 연락하세요.
- 상황이 지원 조치를 필요로 하는 경우 및 귀하의 요금제에 응급 지원이 포함된 경우, 응급 티켓을 생성하세요.