Skip to main content

업그레이드 요구 사항

GitHub Enterprise Server를 업그레이드하기 전에 이러한 권장 사항 및 요구 사항을 검토하여 업그레이드 전략을 계획합니다.

참고:

  • 업그레이드 패키지의 지원되는 버전은 enterprise.github.com에서 확인할 수 있습니다. 업그레이드를 완료하는 데 필요한 업그레이드 패키지의 가용성을 확인합니다. 패키지를 사용할 수 없는 경우 GitHub Enterprise Support에 문의하세요.
  • GitHub Enterprise Server 클러스터링을 사용하는 경우 클러스터링에 고유한 특정 지침은 GitHub Enterprise Server 클러스터링 가이드의 “클러스터 업그레이드”를 참조하세요.
  • GitHub Enterprise Server의 릴리스 정보는 모든 버전의 GitHub Enterprise Server에 대한 포괄적인 새 기능 목록을 제공합니다. 자세한 내용은 릴리스 페이지를 참조하세요.

권장 사항

  • 업그레이드 프로세스에 가능한 한 적은 수의 업그레이드를 포함합니다. 예를 들어 GitHub Enterprise 3.5에서 3.6로, 다시 3.7로 업그레이드하는 대신, GitHub Enterprise 3.5에서 3.7로 업그레이드할 수 있습니다. Upgrade assistant를 사용하여 현재 릴리스 버전에서 업그레이드 경로를 찾습니다.
  • 여러 버전이 뒤처진 경우 업그레이드 프로세스의 각 단계에서 your GitHub Enterprise Server instance을(를) 최대한 앞으로 업그레이드합니다. 각 업그레이드에서 가능한 최신 버전을 사용하면 성능 향상 및 버그 수정을 활용할 수 있습니다. 예를 들어 GitHub Enterprise 2.7에서 2.8로, 다시 2.10으로 업그레이드할 수 있지만 GitHub Enterprise 2.7에서 2.9로, 다시 2.10으로 업그레이드하면 두 번째 단계에서 이후 버전이 사용됩니다.
  • 업그레이드할 때 최신 패치 릴리스를 사용합니다. GitHub Enterprise Server 릴리스 페이지로 이동합니다. 업그레이드할 릴리스 옆에 있는 다운로드를 클릭한 다음 업그레이드 탭을 클릭합니다.
  • 스테이징 인스턴스를 사용하여 업그레이드 단계를 테스트합니다. 자세한 내용은 “스테이징 인스턴스 설정”을 참조하세요.
  • 여러 업그레이드를 실행하는 경우 백그라운드에서 실행되는 데이터 마이그레이션 및 업그레이드 작업이 완전히 완료되도록 기능 업그레이드 간에 24시간 이상 기다립니다.
  • 가상 머신을 업그레이드하기 전에 스냅샷을 만듭니다. 자세한 내용은 “스냅샷 만들기”를 참조하세요.
  • 최근 인스턴스의 성공적인 백업이 있었는지 확인합니다. 자세한 내용은 GitHub Enterprise Server Backup Utilities README.md 파일을 참조하세요.

요구 사항

  • 최대 두 개의 릴리스 뒤에 있는 기능 릴리스에서 업그레이드해야 합니다. 예를 들어 GitHub Enterprise 3.7로 업그레이드하려면 GitHub Enterprise 3.6 또는 3.5에 있어야 합니다.
  • 업그레이드 패키지를 사용하여 업그레이드할 때 GitHub Enterprise Server 최종 사용자를 위한 유지 관리 기간을 예약합니다.
  • 핫패치를 사용하여 GitHub Enterprise Server을(를) 최신 패치 릴리스로 업그레이드할 수 있습니다.

핫패칭을 사용하여 최신 패치 릴리스로 업그레이드할 수 있지만 기능 릴리스는 업그레이드할 수 없습니다. 예를 들어 2.10.1에서 2.10.5로 업그레이드는 동일한 기능 시리즈에 있으므로 가능하지만 2.10.9에서 2.11.0으로 업그레이드는 다른 기능 시리즈에 있으므로 불가능합니다.

핫패치는 일반적으로 다시 부팅할 필요가 없습니다. 핫패치에 다시 부팅이 필요한 경우 GitHub Enterprise Server 릴리스 정보는 요구 사항을 나타냅니다.

핫패치에는 구성 실행이 필요하므로 your GitHub Enterprise Server instance의 일부 또는 모든 서비스에 대해 짧은 기간 동안 오류가 발생하거나 응답하지 않습니다. 핫패치를 설치하는 동안 유지 관리 모드를 사용하도록 설정할 필요는 없지만 이렇게 하면 오류 또는 시간 초과 대신 유지 관리 페이지가 표시됩니다. 자세한 내용은 “유지 관리 모드 사용 및 예약”을 참조하세요.

  • 영향을 받는 서비스(예: 커널, MySQL 또는 Elasticsearch)에 VM 재부팅 또는 서비스를 다시 시작이 필요한 경우 핫패치에 가동 중지 시간이 필요할 수 있습니다. 다시 부팅하거나 다시 시작해야 하는 경우 알림이 표시됩니다. 다시 부팅을 완료하거나 나중에 다시 시작할 수 있습니다.
  • 업그레이드가 완료될 때까지 여러 버전의 특정 서비스를 설치하므로 핫패치를 통해 업그레이드할 때 추가 루트 스토리지를 사용할 수 있어야 합니다. 플라이트 전 검사는 루트 디스크 스토리지가 충분하지 않은 경우 사용자에게 알립니다.
  • 핫패치를 통해 업그레이드하는 경우 핫패칭 프로세스에 영향을 미칠 수 있으므로 인스턴스가 너무 많이 로드될 수 없습니다.
  • GitHub Enterprise Server 2.17로 업그레이드하면 감사 로그가 Elasticsearch에서 MySQL로 마이그레이션됩니다. 또한 이 마이그레이션을 통해 스냅샷을 복원하는 데 걸리는 시간과 디스크 공간도 늘어나게 됩니다. 마이그레이션하기 전에 다음 명령을 사용하여 Elasticsearch 감사 로그 인덱스의 바이트 수를 확인합니다.
    curl -s http://localhost:9201/audit_log/_stats/store | jq ._all.primaries.store.size_in_bytes
    이 숫자를 사용하여 MySQL 감사 로그에 필요한 디스크 공간을 예측합니다. 또한 이 스크립트는 가져오기가 진행되는 동안 사용 가능한 디스크 공간을 모니터링합니다. 이 수를 모니터링하는 것은 사용 가능한 디스크 공간이 마이그레이션에 필요한 디스크 공간의 양에 가까운 경우에 특히 유용합니다.

다음 단계

권장 사항 및 요구 사항을 검토한 후 GitHub Enterprise Server를 업그레이드할 수 있습니다. 자세한 내용은 “GitHub Enterprise Server 업그레이드”를 참조하세요.