업그레이드 요구 사항

권장 사항

• 업그레이드 프로세스에 가능한 한 적은 수의 업그레이드를 포함합니다. 예를 들어 GitHub Enterprise 3.12에서 3.13로, 다시 3.14로 업그레이드하는 대신, GitHub Enterprise 3.12에서 3.14로 업그레이드할 수 있습니다. 업그레이드 도우미를 사용하여 현재 릴리스 버전에서 업그레이드 경로를 찾습니다.
• 여러 버전이 뒤처진 경우 업그레이드 프로세스의 각 단계에서 GitHub Enterprise Server 인스턴스를 최대한 최신으로 업그레이드합니다. 각 업그레이드에서 가능한 최신 버전을 사용하면 성능 향상 및 버그 수정을 활용할 수 있습니다. 예를 들어 GitHub Enterprise 2.7에서 2.8로, 다시 2.10으로 업그레이드할 수 있지만 GitHub Enterprise 2.7에서 2.9로, 다시 2.10으로 업그레이드하면 두 번째 단계에서 이후 버전이 사용됩니다.
• 업그레이드할 때 최신 패치 릴리스를 사용합니다. GitHub Enterprise Server 릴리스 페이지로 이동합니다. 업그레이드할 릴리스 옆에 있는 다운로드를 클릭한 다음 업그레이드 탭을 클릭합니다.
• 스테이징 인스턴스를 사용하여 업그레이드 단계를 테스트합니다. 자세한 내용은 "스테이징 인스턴스 설정"을(를) 참조하세요.
• 여러 업그레이드를 실행할 때 은(는) 다음 기능 업그레이드를 진행하기 전에 백그라운드에서 실행 중인 데이터 마이그레이션 및 업그레이드 작업이 완전히 완료되었는지 확인합니다. 이러한 프로세스의 상태를 확인하기 위해 ghe-migrations 및 ghe-check-background-upgrade-jobs 명령줄 유틸리티를 사용할 수 있습니다. GitHub Enterprise Server 3.11에서 ghe-check-background-upgrade-jobs을(를) 사용하려면 인스턴스가 3.11.1 이상 버전을 실행해야 합니다. 자세한 내용은 "명령줄 유틸리티"을 참조하세요.
• 가상 머신을 업그레이드하기 전에 스냅샷을 만듭니다. 자세한 내용은 "스냅샷 만들기"을(를) 참조하세요.
• 최근 인스턴스의 성공적인 백업이 있었는지 확인합니다. 자세한 내용은 GitHub Enterprise Server Backup Utilities README.md 파일을 참조하세요.

요구 사항

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

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

핫패치는 반드시 다시 부팅할 필요는 없습니다. 핫패치를 설치하면 업데이트를 완료하기 위해 패키지를 다시 부팅해야 하는 경우 터미널에 메시지가 표시됩니다. 이 재부팅은 편리한 시간에 예약할 수 있지만, 특히 보안 수정 사항이 있는 경우 최대한 빨리 다시 부팅하는 것이 좋습니다.

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

• 영향을 받는 서비스(예: 커널, 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 감사 로그에 필요한 디스크 공간을 예측합니다. 또한 이 스크립트는 가져오기가 진행되는 동안 사용 가능한 디스크 공간을 모니터링합니다. 이 수를 모니터링하는 것은 사용 가능한 디스크 공간이 마이그레이션에 필요한 디스크 공간의 양에 가까운 경우에 특히 유용합니다.

업그레이드 시에는 메모리, CPU 코어, 사용자 및 루트 디스크 스토리지 등 시스템 하드웨어 리소스에 대한 최소 요구 사항을 인스턴스에서 사용할 수 있는지 사전 검사를 통해 평가합니다. 사전 검사에서 리소스가 부족하다고 판단되거나 기타 이유로 실패하면 알림이 제공되고 업그레이드가 중단됩니다.

다음 단계

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