InfoGrab Docs

업그레이드 전 준비 사항

요약

GitLab 인스턴스를 업그레이드하기 전에 다음 작업을 수행해야 합니다: 모든 사전 업그레이드 정보를 수집한 후 사전 업그레이드 단계를 진행할 수 있습니다. 업그레이드 중 문제가 발생할 수 있으므로 롤백 계획을 갖추는 것이 중요합니다.

GitLab 인스턴스를 업그레이드하기 전에 다음 작업을 수행해야 합니다:

  1. 업그레이드 준비를 위한 사전 업그레이드 정보를 수집합니다.
  2. GitLab 자체를 업그레이드하기 전에 사전 업그레이드 단계를 수행합니다.

사전 업그레이드 정보 수집#

업그레이드 계획 시:

  1. GitLab 릴리스 및 유지 관리 정책을 검토합니다.
  2. 호환성을 확인하기 위해 다양한 GitLab 버전의 GitLab 업그레이드 노트를 참조합니다.
  3. 해당하는 경우, 대상 GitLab 버전과 OS 호환성을 확인합니다.
  4. Geo를 사용하는 경우:
  5. 필요한 업그레이드 중지 지점을 포함하여 인스턴스에 적합한 업그레이드 경로를 결정합니다. 업그레이드 중지 지점은 여러 번의 업그레이드를 수행해야 할 수도 있습니다.
  6. 업그레이드 상태 점검을 실행하여 잠재적인 문제를 사전에 발견하고 해결합니다.
  7. 다음을 문서화하는 업그레이드 계획을 수립합니다:
    • 가능하고 필요한 경우 무중단 업그레이드를 포함하여 인스턴스 업그레이드 단계.
    • 업그레이드가 원활하지 않은 경우 취할 단계, 필요한 경우 GitLab 롤백 방법 포함.
  8. 프로덕션 환경의 복제본에서 업그레이드 계획을 테스트합니다. 이를 통해 계획되지 않은 중단의 위험을 줄이고 잠재적으로 오래 실행되는 마이그레이션의 소요 시간을 측정하는 데 도움이 됩니다.

모든 사전 업그레이드 정보를 수집한 후 사전 업그레이드 단계를 진행할 수 있습니다.

롤백 계획 및 백업 생성#

업그레이드 중 문제가 발생할 수 있으므로 롤백 계획을 갖추는 것이 중요합니다. 적절한 롤백 계획은 GitLab 인스턴스를 마지막 정상 상태로 되돌리는 명확한 경로를 만들며 다음을 포함합니다:

  • 인스턴스 백업 프로세스.
  • 인스턴스 복원 프로세스.

롤백 계획이 필요하기 전에 테스트해야 합니다. 롤백에 필요한 단계 개요는 이전 GitLab 버전으로 롤백을 참조하세요.

GitLab 백업 생성#

업그레이드에 문제가 있는 경우 GitLab을 롤백할 수 있도록 하려면 다음 중 하나를 수행하세요:

  • GitLab 백업을 생성합니다. 설치 방법에 따른 지침을 따르고 시크릿 및 구성 파일도 백업해야 합니다.
  • 인스턴스의 스냅샷을 생성합니다. 인스턴스가 다중 노드 설치인 경우 모든 노드의 스냅샷을 생성해야 합니다. 이 프로세스는 GitLab 지원 범위를 벗어납니다.

GitLab 롤백#

프로덕션 환경을 모방하는 테스트 환경이 있는 경우 복원을 테스트하여 모든 것이 예상대로 작동하는지 확인하세요.

GitLab 백업을 복원하려면:

  1. 복원 전제 조건을 참조하세요. 가장 중요한 것은 백업된 GitLab 인스턴스와 새 GitLab 인스턴스의 버전이 동일해야 한다는 점입니다.
  2. 설치 방법에 따른 지침을 따라 GitLab 복원을 수행합니다.
  3. 시크릿 및 구성 파일도 복원되었는지 확인합니다.

스냅샷에서 복원하는 경우 이미 방법을 알고 있어야 합니다. 이 프로세스는 GitLab 지원 범위를 벗어납니다.

사전 업그레이드 단계 수행#

업그레이드를 수행하기 직전에:

  1. 업그레이드 상태 점검을 재실행합니다.
  2. 사용하는 선택적 기능에 대한 업그레이드를 수행합니다.

업그레이드 상태 점검 실행#

업그레이드 직전 및 직후에 업그레이드 상태 점검을 실행하여 GitLab의 주요 구성 요소가 작동하는지 확인합니다:

  1. 일반 구성 확인:

    sudo gitlab-rake gitlab:check

  2. 모든 백그라운드 데이터베이스 마이그레이션 상태를 확인합니다. 모든 마이그레이션이 각 업그레이드 전에 완료되어야 합니다. 백그라운드 마이그레이션이 완료될 시간을 확보하기 위해 주요 및 부 릴리스 사이의 업그레이드를 분산해야 합니다.

  3. 암호화된 데이터베이스 값이 복호화 가능한지 확인:

    sudo gitlab-rake gitlab:doctor:secrets

  4. GitLab UI에서 다음을 확인합니다:

    • 사용자가 로그인할 수 있는지.
    • 프로젝트 목록이 표시되는지.
    • 프로젝트 이슈 및 머지 리퀘스트에 접근 가능한지.
    • 사용자가 GitLab에서 저장소를 클론할 수 있는지.
    • 사용자가 GitLab에 커밋을 푸시할 수 있는지.

  5. GitLab CI/CD의 경우 다음을 확인합니다:

    • 러너가 잡을 받는지.
    • Docker 이미지를 레지스트리에서 푸시 및 풀할 수 있는지.

  6. Geo를 사용하는 경우 기본 사이트와 각 보조 사이트에서 관련 점검을 실행합니다:

    sudo gitlab-rake gitlab:geo:check

  7. Elasticsearch를 사용하는 경우 검색이 성공하는지 확인합니다.

문제가 발생하면 지원 받기를 참조하세요.

선택적 기능 업그레이드#

GitLab 인스턴스 구성에 따라 GitLab 업그레이드 전에 다음 추가 단계를 수행해야 할 수 있습니다:

  1. 외부 Gitaly 서버를 사용하는 경우 GitLab 자체를 업그레이드하기 전에 Gitaly 서버를 최신 버전으로 업그레이드합니다. 이를 통해 애플리케이션 서버의 gRPC 클라이언트가 이전 Gitaly 버전에서 지원하지 않는 RPC를 전송하는 것을 방지합니다.

  2. GitLab에 연결된 Kubernetes 클러스터가 있는 경우 새 GitLab 버전에 맞게 Kubernetes용 GitLab 에이전트를 업그레이드합니다.

  3. 고급 검색(Elasticsearch)을 사용하는 경우 보류 중인 마이그레이션 확인으로 고급 검색 마이그레이션이 완료되었는지 확인합니다.

    GitLab을 업그레이드한 후 새 버전이 호환성을 깨는 경우 Elasticsearch를 업그레이드해야 할 수 있습니다. Elasticsearch 업데이트는 GitLab 지원 범위를 벗어납니다.

CI/CD 파이프라인 및 잡 일시 중지#

대부분의 GitLab 인스턴스 유형의 업그레이드 중에는 CI/CD 파이프라인 및 잡을 일시 중지해야 합니다.

GitLab Runner가 잡을 처리하는 동안 GitLab 인스턴스를 업그레이드하면 트레이스 업데이트가 실패합니다. GitLab이 다시 온라인 상태가 되면 트레이스 업데이트가 자동으로 복구됩니다. 트레이스 업데이트가 자동으로 복구되지 않으면 오류에 따라 GitLab Runner가 잡 처리를 재시도하거나 종료합니다.

GitLab Runner는 잡 아티팩트를 세 번 업로드하려고 시도하며, 그 이후에 잡은 실패합니다.

CI/CD 파이프라인 및 잡을 일시 중지하려면:

  1. 러너를 일시 중지합니다.

  2. /etc/gitlab/gitlab.rb 파일에 다음을 추가하여 새 잡 시작을 차단합니다:

    nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n deny all;\n return 503;\n}\n"

  3. GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

  4. 모든 잡이 완료될 때까지 기다립니다.

GitLab 업그레이드가 완료되면:

  1. 러너의 일시 중지를 해제합니다.
  2. 이전 /etc/gitlab/gitlab.rb 변경 사항을 되돌려 새 잡 시작 차단을 해제합니다.

지원팀과 협력#

업그레이드 계획을 검토하기 위해 지원팀과 협력하는 경우 다음 질문에 대한 답변을 문서화하고 공유합니다:

  • GitLab이 어떻게 설치되어 있나요?
  • 노드의 운영 체제는 무엇인가요? 지원되는 플랫폼을 확인하여 이후 업데이트가 가능한지 확인합니다.
  • 단일 노드 또는 다중 노드 설정인가요? 다중 노드인 경우 각 노드에 대한 아키텍처 세부 정보를 문서화하고 공유합니다. 어떤 외부 구성 요소가 사용되나요? 예: Gitaly, PostgreSQL, Redis?
  • Geo를 사용하나요? 사용한다면 각 보조 사이트에 대한 아키텍처 세부 정보를 문서화하고 공유합니다.
  • 중요할 수 있는 설정에서 고유하거나 흥미로운 다른 사항이 있나요?
  • 현재 GitLab 버전에서 알려진 문제가 있나요?

지원 받기#

업그레이드 중 문제가 발생하면:

  1. 나중에 분석하기 위해 오류를 복사하고 로그를 수집합니다. 데이터를 수집하는 데 도움이 되는 다음 도구를 사용하세요:
    • Linux 패키지 또는 Docker로 GitLab을 설치한 경우 gitlabsos.
    • Helm 차트를 사용하여 GitLab을 설치한 경우 kubesos.
  2. 마지막으로 작동한 버전으로 롤백합니다.

지원을 받으려면:

업그레이드 전 준비 사항

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

GitLab 인스턴스를 업그레이드하기 전에 다음 작업을 수행해야 합니다: 모든 사전 업그레이드 정보를 수집한 후 사전 업그레이드 단계를 진행할 수 있습니다. 업그레이드 중 문제가 발생할 수 있으므로 롤백 계획을 갖추는 것이 중요합니다.

GitLab 인스턴스를 업그레이드하기 전에 다음 작업을 수행해야 합니다:

  1. 업그레이드 준비를 위한 사전 업그레이드 정보를 수집합니다.
  2. GitLab 자체를 업그레이드하기 전에 사전 업그레이드 단계를 수행합니다.

사전 업그레이드 정보 수집#

업그레이드 계획 시:

  1. GitLab 릴리스 및 유지 관리 정책을 검토합니다.
  2. 호환성을 확인하기 위해 다양한 GitLab 버전의 GitLab 업그레이드 노트를 참조합니다.
  3. 해당하는 경우, 대상 GitLab 버전과 OS 호환성을 확인합니다.
  4. Geo를 사용하는 경우:
  5. 필요한 업그레이드 중지 지점을 포함하여 인스턴스에 적합한 업그레이드 경로를 결정합니다. 업그레이드 중지 지점은 여러 번의 업그레이드를 수행해야 할 수도 있습니다.
  6. 업그레이드 상태 점검을 실행하여 잠재적인 문제를 사전에 발견하고 해결합니다.
  7. 다음을 문서화하는 업그레이드 계획을 수립합니다:
    • 가능하고 필요한 경우 무중단 업그레이드를 포함하여 인스턴스 업그레이드 단계.
    • 업그레이드가 원활하지 않은 경우 취할 단계, 필요한 경우 GitLab 롤백 방법 포함.
  8. 프로덕션 환경의 복제본에서 업그레이드 계획을 테스트합니다. 이를 통해 계획되지 않은 중단의 위험을 줄이고 잠재적으로 오래 실행되는 마이그레이션의 소요 시간을 측정하는 데 도움이 됩니다.

모든 사전 업그레이드 정보를 수집한 후 사전 업그레이드 단계를 진행할 수 있습니다.

롤백 계획 및 백업 생성#

업그레이드 중 문제가 발생할 수 있으므로 롤백 계획을 갖추는 것이 중요합니다. 적절한 롤백 계획은 GitLab 인스턴스를 마지막 정상 상태로 되돌리는 명확한 경로를 만들며 다음을 포함합니다:

  • 인스턴스 백업 프로세스.
  • 인스턴스 복원 프로세스.

롤백 계획이 필요하기 전에 테스트해야 합니다. 롤백에 필요한 단계 개요는 이전 GitLab 버전으로 롤백을 참조하세요.

GitLab 백업 생성#

업그레이드에 문제가 있는 경우 GitLab을 롤백할 수 있도록 하려면 다음 중 하나를 수행하세요:

  • GitLab 백업을 생성합니다. 설치 방법에 따른 지침을 따르고 시크릿 및 구성 파일도 백업해야 합니다.
  • 인스턴스의 스냅샷을 생성합니다. 인스턴스가 다중 노드 설치인 경우 모든 노드의 스냅샷을 생성해야 합니다. 이 프로세스는 GitLab 지원 범위를 벗어납니다.

GitLab 롤백#

프로덕션 환경을 모방하는 테스트 환경이 있는 경우 복원을 테스트하여 모든 것이 예상대로 작동하는지 확인하세요.

GitLab 백업을 복원하려면:

  1. 복원 전제 조건을 참조하세요. 가장 중요한 것은 백업된 GitLab 인스턴스와 새 GitLab 인스턴스의 버전이 동일해야 한다는 점입니다.
  2. 설치 방법에 따른 지침을 따라 GitLab 복원을 수행합니다.
  3. 시크릿 및 구성 파일도 복원되었는지 확인합니다.

스냅샷에서 복원하는 경우 이미 방법을 알고 있어야 합니다. 이 프로세스는 GitLab 지원 범위를 벗어납니다.

사전 업그레이드 단계 수행#

업그레이드를 수행하기 직전에:

  1. 업그레이드 상태 점검을 재실행합니다.
  2. 사용하는 선택적 기능에 대한 업그레이드를 수행합니다.

업그레이드 상태 점검 실행#

업그레이드 직전 및 직후에 업그레이드 상태 점검을 실행하여 GitLab의 주요 구성 요소가 작동하는지 확인합니다:

  1. 일반 구성 확인:

    sudo gitlab-rake gitlab:check

  2. 모든 백그라운드 데이터베이스 마이그레이션 상태를 확인합니다. 모든 마이그레이션이 각 업그레이드 전에 완료되어야 합니다. 백그라운드 마이그레이션이 완료될 시간을 확보하기 위해 주요 및 부 릴리스 사이의 업그레이드를 분산해야 합니다.

  3. 암호화된 데이터베이스 값이 복호화 가능한지 확인:

    sudo gitlab-rake gitlab:doctor:secrets

  4. GitLab UI에서 다음을 확인합니다:

    • 사용자가 로그인할 수 있는지.
    • 프로젝트 목록이 표시되는지.
    • 프로젝트 이슈 및 머지 리퀘스트에 접근 가능한지.
    • 사용자가 GitLab에서 저장소를 클론할 수 있는지.
    • 사용자가 GitLab에 커밋을 푸시할 수 있는지.

  5. GitLab CI/CD의 경우 다음을 확인합니다:

    • 러너가 잡을 받는지.
    • Docker 이미지를 레지스트리에서 푸시 및 풀할 수 있는지.

  6. Geo를 사용하는 경우 기본 사이트와 각 보조 사이트에서 관련 점검을 실행합니다:

    sudo gitlab-rake gitlab:geo:check

  7. Elasticsearch를 사용하는 경우 검색이 성공하는지 확인합니다.

문제가 발생하면 지원 받기를 참조하세요.

선택적 기능 업그레이드#

GitLab 인스턴스 구성에 따라 GitLab 업그레이드 전에 다음 추가 단계를 수행해야 할 수 있습니다:

  1. 외부 Gitaly 서버를 사용하는 경우 GitLab 자체를 업그레이드하기 전에 Gitaly 서버를 최신 버전으로 업그레이드합니다. 이를 통해 애플리케이션 서버의 gRPC 클라이언트가 이전 Gitaly 버전에서 지원하지 않는 RPC를 전송하는 것을 방지합니다.

  2. GitLab에 연결된 Kubernetes 클러스터가 있는 경우 새 GitLab 버전에 맞게 Kubernetes용 GitLab 에이전트를 업그레이드합니다.

  3. 고급 검색(Elasticsearch)을 사용하는 경우 보류 중인 마이그레이션 확인으로 고급 검색 마이그레이션이 완료되었는지 확인합니다.

    GitLab을 업그레이드한 후 새 버전이 호환성을 깨는 경우 Elasticsearch를 업그레이드해야 할 수 있습니다. Elasticsearch 업데이트는 GitLab 지원 범위를 벗어납니다.

CI/CD 파이프라인 및 잡 일시 중지#

대부분의 GitLab 인스턴스 유형의 업그레이드 중에는 CI/CD 파이프라인 및 잡을 일시 중지해야 합니다.

GitLab Runner가 잡을 처리하는 동안 GitLab 인스턴스를 업그레이드하면 트레이스 업데이트가 실패합니다. GitLab이 다시 온라인 상태가 되면 트레이스 업데이트가 자동으로 복구됩니다. 트레이스 업데이트가 자동으로 복구되지 않으면 오류에 따라 GitLab Runner가 잡 처리를 재시도하거나 종료합니다.

GitLab Runner는 잡 아티팩트를 세 번 업로드하려고 시도하며, 그 이후에 잡은 실패합니다.

CI/CD 파이프라인 및 잡을 일시 중지하려면:

  1. 러너를 일시 중지합니다.

  2. /etc/gitlab/gitlab.rb 파일에 다음을 추가하여 새 잡 시작을 차단합니다:

    nginx['custom_gitlab_server_config'] = "location = /api/v4/jobs/request {\n deny all;\n return 503;\n}\n"

  3. GitLab을 재구성합니다:

    sudo gitlab-ctl reconfigure

  4. 모든 잡이 완료될 때까지 기다립니다.

GitLab 업그레이드가 완료되면:

  1. 러너의 일시 중지를 해제합니다.
  2. 이전 /etc/gitlab/gitlab.rb 변경 사항을 되돌려 새 잡 시작 차단을 해제합니다.

지원팀과 협력#

업그레이드 계획을 검토하기 위해 지원팀과 협력하는 경우 다음 질문에 대한 답변을 문서화하고 공유합니다:

  • GitLab이 어떻게 설치되어 있나요?
  • 노드의 운영 체제는 무엇인가요? 지원되는 플랫폼을 확인하여 이후 업데이트가 가능한지 확인합니다.
  • 단일 노드 또는 다중 노드 설정인가요? 다중 노드인 경우 각 노드에 대한 아키텍처 세부 정보를 문서화하고 공유합니다. 어떤 외부 구성 요소가 사용되나요? 예: Gitaly, PostgreSQL, Redis?
  • Geo를 사용하나요? 사용한다면 각 보조 사이트에 대한 아키텍처 세부 정보를 문서화하고 공유합니다.
  • 중요할 수 있는 설정에서 고유하거나 흥미로운 다른 사항이 있나요?
  • 현재 GitLab 버전에서 알려진 문제가 있나요?

지원 받기#

업그레이드 중 문제가 발생하면:

  1. 나중에 분석하기 위해 오류를 복사하고 로그를 수집합니다. 데이터를 수집하는 데 도움이 되는 다음 도구를 사용하세요:
    • Linux 패키지 또는 Docker로 GitLab을 설치한 경우 gitlabsos.
    • Helm 차트를 사용하여 GitLab을 설치한 경우 kubesos.
  2. 마지막으로 작동한 버전으로 롤백합니다.

지원을 받으려면: