GitLab 업그레이드 계획 만들기
이 문서는 자가 관리형 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 버전의 변경 사항을 고려하세요. 자세한 내용은 다음을 참조하세요:
-
대상 GitLab 버전과의 OS 호환성을 확인하세요.
-
-
필요한 데이터베이스 및 고급 검색 백그라운드 마이그레이션을 확인하세요. 백그라운드 마이그레이션이 있을 경우 추가 업그레이드 전에 일시 중지하세요. 모든 마이그레이션이 완료되어야 다음 업그레이드가 가능합니다.
-
GitLab 인스턴스에 연관된 러너가 있는 경우, 현재 GitLab 버전에 맞게 업그레이드해야 합니다. 이는 GitLab 버전과의 호환성을 보장합니다.
-
시작 버전에서 사용할 수 있는 경우 업그레이드 중 유지 관리 모드 활성화를 고려하세요.
-
PostgreSQL에 관하여:
-
왼쪽 사이드바 하단에서 Admin을 선택하세요.
-
사용 중인 PostgreSQL 버전을 확인하세요. 만약 PostgreSQL 업그레이드가 필요하다면, 관련된 패키지된 또는 비패키지된 단계를 고려하세요.
-
추가 기능
위의 일반 정보 외에도, 특별한 계획이 필요한 기능을 활성화했을 수 있습니다.
Geo, 외부 Gitaly, 또는 Elasticsearch와 같이 설정에 적용되지 않는 기능에 대한 섹션은 무시해도 됩니다.
외부 Gitaly
외부 Gitaly 서버를 사용하는 경우, 애플리케이션 서버를 업그레이드하기 전에 최신 버전으로 업그레이드해야 합니다.
지오
Geo를 사용하는 경우:
- Geo 업그레이드 문서를 검토하세요.
-
Geo 버전별 업데이트 지침에 대해 읽어보세요:
- 데이터베이스 업그레이드 시 Geo 특화 단계를 검토하세요.
- 각 Geo 사이트(주 사이트 및 각 보조 사이트)에 대한 업그레이드 및 롤백 계획을 수립하세요.
러너
GitLab을 업데이트한 후, 새 GitLab 버전에 맞게 러너를 업그레이드하세요.
Kubernetes용 GitLab 에이전트
GitLab과 연결된 Kubernetes 클러스터가 있는 경우, Kubernetes용 GitLab 에이전트를 업그레이드하여 새 GitLab 버전과 맞추세요.
Elasticsearch
GitLab을 업데이트하기 전에 대기 중인 고급 검색 마이그레이션을 확인하여 고급 검색 마이그레이션이 완료되었는지 확인하세요.
GitLab을 업데이트한 후, 새 버전이 호환성을 깨뜨릴 경우 Elasticsearch를 업그레이드해야 할 수 있습니다.
Elasticsearch 업데이트는 GitLab 지원 범위를 벗어납니다.
문제 해결
예상대로 진행되지 않는 경우:
-
시간이 중요하다면, 오류를 복사하고 나중에 분석할 로그를 수집하며,
마지막으로 작동하던 버전으로 롤백하세요. 데이터를 수집하는 데 도움이 되는 다음 도구를 사용할 수 있습니다: -
지원을 받으려면:
- GitLab 지원에 문의하고, 고객 성공 관리자가 있는 경우 그와 함께 연락하세요.
- 상황이 자격이 되는 경우와 귀하의 계획이 긴급 지원을 포함하는 경우, 긴급 티켓을 생성하세요.