업그레이드 프로세스 개요

업그레이드 전략을 계획하고 테스트할 수 있도록 GitHub Enterprise Server을(를) 업그레이드하기 위한 권장 사항 및 요구 사항을 알아봅니다.

이 문서의 내용

GitHub Enterprise Server는 기능 및 패치 릴리스를 통해 도입된 새로운 기능과 버그 수정을 통해 지속적으로 개선되고 있습니다. 인스턴스로 업그레이드하는 것은 사용자의 책임입니다. "새 릴리스로 업그레이드 정보" 항목을 참조하세요.

인스턴스를 업그레이드하려면 다음을 수행해야 합니다.

  1. 업그레이드 버전 및 적절한 업그레이드 패키지를 선택하고 유지 관리 기간을 예약하여 업그레이드 전략을 계획합니다.
  2. 업그레이드 프로세스 전후에 업그레이드에 대해 전달합니다.
  3. 백업을 만들고 가상 머신 스냅샷을 만들어 백업 전략을 준비합니다.
  4. 적절한 패키지 및 방법을 사용하여 업그레이드 패키지를 설치합니다.
  5. 업그레이드 후 작업을 완료합니다.

업그레이드 패키지를 적용하기 위해 수행해야 하는 프로세스는 배포 토폴로지에 있는 노드 수에 따라 달라집니다. 이 문서에서는 독립 실행형 또는 고가용성 구성에서만 인스턴스를 업그레이드하는 일반적인 정보를 제공합니다.

업그레이드 전략 계획

업그레이드 계획

  • 업그레이드를 수행하기 전에 릴리스 정보 및 문서화된 알려진 문제를 검토합니다. "릴리스 정보" 및 "인스턴스로의 업그레이드와 관련된 알려진 문제" 항목을 참조하세요.
  • 업그레이드에 대한 요구 사항 및 권장 사항을 이해하려면 "업그레이드 요구 사항"을(를) 검토하세요.
  • GitHub Enterprise Server 인스턴스의 데이터 디스크가 15% 이상 비어 있는지 확인합니다. GitHub은(는) 디스크에 추가적인 여유 스토리지가 있는지 확인하는 것이 좋습니다. 경우에 따라 데이터 볼륨이 큰 고객의 경우, 이 임계값이 다를 수 있습니다. "스토리지 용량 늘리기" 항목을 참조하세요.
  • GitHub Enterprise Server에 대한 하드웨어 리소스가 충분한지 확인합니다. 업그레이드 시에는 메모리, CPU 코어, 사용자 및 루트 디스크 스토리지 등 시스템 하드웨어 리소스에 대한 최소 요구 사항을 인스턴스에서 사용할 수 있는지 사전 검사를 통해 평가합니다. 사전 검사에서 리소스가 부족하다고 판단되거나 기타 이유로 실패하면 알림이 제공되고 업그레이드가 중단됩니다.
  • 업그레이드 후에는 사용자 지정 규칙이 유지되지 않으므로 GitHub Enterprise Server 인스턴스에 대한 모든 사용자 지정 방화벽 규칙의 복사본이 있는지 확인합니다. 업그레이드 후 사용자 지정 규칙을 다시 적용해야 합니다. "기본 제공 방화벽 규칙 구성" 항목을 참조하세요.
  • 고가용성 구성 인스턴스의 경우 업그레이드하기 전에 복제 보고서 OK의 상태를 확인합니다. "고가용성 구성 모니터링" 항목을 참조하세요.
  • 업그레이드 후 서버 상태의 유효성을 검사하기 위해 GitHub Enterprise Server 인스턴스에 대한 액세스를 일시적으로 제한할 수 있도록 유지 관리 모드에 대한 IP 예외 목록을 구성하는 것이 좋습니다. "유지 관리 모드 사용 설정 및 예약" 항목을 참조하세요.

업그레이드 버전 및 패키지 선택

  • 업그레이드 전략을 결정하고 업그레이드할 대상 버전을 선택합니다.
    • GitHub Enterprise Server 인스턴스를 새 패치 릴리스 또는 새 기능 릴리스로 업그레이드할 수 있습니다.
    • 업그레이드 도우미에서 현재 릴리스 버전에서 새로운 패치 또는 기능 릴리스 버전에 대한 업그레이드 경로를 찾습니다.
  • 업그레이드 패키지(핫패치 또는 업그레이드 패키지)를 선택합니다.
    • 패치 릴리스로 업그레이드하려면 핫패치 또는 업그레이드 패키지를 사용할 수 있습니다. 기능 릴리스로 업그레이드하려면 업그레이드 패키지를 사용해야 합니다.
    • 업그레이드 패키지를 사용하는 경우 GitHub Enterprise Server 최종 사용자를 위한 유지 관리 기간을 예약합니다. 핫패치를 사용하는 경우에는 유지 관리 모드가 필요하지 않습니다.
    • 자동 업데이트 검사를 사용하도록 설정한 경우 사이트 관리자에게 업그레이드 패키지가 다운로드되어 사용할 수 있다는 알림이 표시됩니다. "자동 업데이트 검사 사용" 항목을 참조하세요.
    • 릴리스 후보 빌드는 테스트 환경에서만 사용하기 위해 준비되었습니다. 프로덕션 환경에 릴리스 후보 빌드를 설치하지 마세요. 릴리스 후보에서 이후 버전으로 업그레이드하지 마세요(일반 사용 가능한 릴리스 포함).

다른 애플리케이션 업데이트가 필요한지 확인

다음 애플리케이션을 업그레이드해야 하는지 확인합니다.

  • GitHub Enterprise Server 인스턴스에서 GitHub Actions에 대해 임시 자체 호스팅 실행기를 사용하고 자동 업데이트를 사용하지 않도록 설정한 경우 GitHub Actions 실행기를 업데이트해야 합니다. 업그레이드를 수행하기 전에 실행기를 업그레이드된 인스턴스에 필요한 최소 버전의 애플리케이션으로 업그레이드합니다. 릴리스에 필요한 최소 버전을 찾으려면 "GitHub Enterprise 서버 릴리스"을(를) 참조하세요.

  • GitHub Enterprise Server Backup Utilities. GitHub Enterprise Server Backup Utilities 버전은 GitHub Enterprise Server 인스턴스 버전과 동일하거나 적어도 두 버전 앞서야 합니다.

    • 인스턴스를 업그레이드하기 전에 GitHub Enterprise Server Backup Utilities을(를) 최신 버전으로 업그레이드해야 할 수 있습니다.
    • 인스턴스를 업그레이드한 후에 GitHub Enterprise Server Backup Utilities을(를) 최신 버전으로 업그레이드하도록 계획할 수도 있습니다.

    자세한 내용은 GitHub Enterprise Server Backup Utilities 프로젝트 설명서의 "인스턴스에서 백업 구성" 및 README를 참조하세요.

유지 관리 기간 플랜

  • 업그레이드 전략에 따라 가동 중지 시간이 길게 필요할 수 있습니다.
  • 예상되는 가동 중지 시간을 결정하는 가장 좋은 방법은 먼저 스테이징 환경에서 업그레이드를 테스트하는 것입니다. "스테이징 인스턴스 설정" 항목을 참조하세요.
  • 업그레이드를 위한 유지 관리 기간은 수행하는 업그레이드 유형에 따라 다릅니다.

    • 핫패치를 사용한 업그레이드에는 일반적으로 유지 관리 기간이 필요하지 않습니다. 다시 부팅이 필요한 경우도 있으며, 나중에 수행할 수 있습니다.

      Note

      핫패치는 구성을 실행해야 하므로, 이로 인해 GitHub Enterprise Server 인스턴스의 일부 또는 모든 서비스가 잠시 동안 오류를 일으키거나 응답이 없을 수 있습니다. 핫패치를 설치하는 동안 유지 관리 모드를 사용하도록 설정할 필요는 없지만, 이렇게 하면 사용자에게 오류나 시간 제한 대신 유지 관리 페이지가 표시되도록 할 수 있습니다. "유지 관리 모드 사용 설정 및 예약" 항목을 참조하세요.

    • 업그레이드 패키지를 사용한 패치 릴리스는 일반적으로 5분 미만의 가동 중지 시간이 필요합니다.

    • 데이터 마이그레이션을 포함하는 새 기능 릴리스로 업그레이드하면 스토리지 성능 및 마이그레이션되는 데이터의 양에 따라 몇 시간의 가동 중지 시간이 발생할 수 있습니다. 이 시간 동안 어떤 사용자도 엔터프라이즈를 사용할 수 없습니다.

업그레이드 전달

  • 업그레이드하기 전에 전역 공지 배너를 게시하여 도입되는 변경 내용 또는 가동 중지 시간과 같은 중요한 정보를 사용자에게 강조 표시할 수 있습니다. "엔터프라이즈에 대한 사용자 메시지 사용자 지정" 항목을 참조하세요.
  • 업그레이드 시 유지 관리 모드를 사용하도록 설정하고 사용자에게 인스턴스를 일시적으로 사용할 수 없음을 알리는 사용자 지정 메시지를 설정할 수 있습니다. "유지 관리 모드 사용 설정 및 예약" 항목을 참조하세요.

백업 전략 준비

백업 스냅샷 만들기

업그레이드 프로세스를 시작하기 전에 인스턴스의 주 노드에 대한 성공적인 최근 백업 스냅샷이 있는지 확인합니다. 자세한 내용은 GitHub Enterprise Server Backup Utilities 프로젝트 설명서의 "인스턴스에서 백업 구성" 및 README를 참조하세요.

VM 스냅샷 만들기

새 기능 릴리스로 업그레이드하는 경우 가상 머신(VM) 스냅샷이 필요합니다. 패치 릴리스로 업그레이드하는 경우 기존 데이터 디스크를 연결할 수 있습니다.

업그레이드 직전에 인스턴스의 주 노드에 대한 가상 머신(VM) 스냅샷을 만들고 유지 관리 모드가 활성화되었거나 인스턴스의 전원이 다운된 경우에만 사용합니다. "스냅샷 만들기" 항목을 참조하세요.

업그레이드 패키지 설치

업그레이드 패키지 설치를 시작하기 전에 업그레이드에 대한 고려 사항을 검토하고 위에서 설명한 대로 모든 준비 단계를 완료합니다.

GitHub Enterprise Server 인스턴스를 업그레이드하는 지침은 수행 중인 업그레이드 유형과 인스턴스의 노드 수에 따라 다릅니다.

업그레이드 완료 후 작업

  • 백그라운드 작업의 상태를 확인하고 업그레이드 로그에서 오류를 검토합니다.
  • 기본 GitHub Enterprise Server 기능을 확인합니다. 예를 들어 사용자 인터페이스를 통해 로그인할 수 있는지 확인하고 여러 조직, 리포지토리 및 이슈에 예상대로 도달할 수 있는지 확인합니다. 또한 SSH 및/또는 HTTPS를 사용하여 여러 Git 페치, 클론 및 푸시를 수동으로 실행하고 API 요청 및 웹후크 배달이 성공적으로 완료되었는지 확인하는 것이 좋습니다.
  • 사용자 지정 방화벽 규칙을 다시 적용합니다. "기본 제공 방화벽 규칙 구성" 항목을 참조하세요.
  • 업그레이드하기 전에 수행한 모든 VM 스냅샷을 삭제합니다. "스냅샷 만들기" 항목을 참조하세요.
  • 유지 관리 모드를 사용하지 않도록 설정하고 알림 배너와 같은 업그레이드 전 전달 사항을 업데이트합니다. "엔터프라이즈에 대한 사용자 메시지 사용자 지정" 및 "유지 관리 모드 사용 설정 및 예약" 항목을 참조하세요.
  • 인스턴스에서 대기 중인 모든 백그라운드 작업을 모니터링하여 성공적으로 완료되었는지 확인합니다. "명령줄 유틸리티" 항목을 참조하세요.