GitHub Enterprise 서버 업그레이드

GitHub Enterprise Server로의 업그레이드 정보

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

instance 업그레이드하려면 업그레이드를 계획하고 전달하고, 적절한 패키지를 선택하고, 데이터를 백업한 다음, 업그레이드를 수행해야 합니다.

사전 요구 사항

GitHub Enterprise Server 인스턴스을(를) 성공적으로 업그레이드하려면 instance 데이터 디스크가 15% 이상 무료여야 합니다. GitHub은(는) 디스크에 더 많은 여유 스토리지가 있는지 확인하는 것이 좋습니다. 드문 경우지만 데이터 볼륨이 큰 고객의 경우 이 임계값이 다를 수 있습니다.

업그레이드 준비

업그레이드를 준비하려면 업그레이드 경로를 계획하고 필요에 따라 GitHub Actions 실행기를 업그레이드하고 유지 관리 기간을 예약합니다.

1. 업그레이드 전략을 결정하고 업그레이드할 대상 버전을 선택합니다. 자세한 내용은 "업그레이드 요구 사항"을 참조하고 업그레이드 도우미를 참조하여 현재 릴리스 버전에서 업그레이드 경로를 찾습니다.

2. GitHub Enterprise Server Backup Utilities을(를) 사용하여 instance 주 노드의 새 백업을 만듭니다. 자세한 내용은 GitHub Enterprise Server Backup Utilities 프로젝트 설명서의 추가 정보를 참조하세요.

   참고: GitHub Enterprise Server Backup Utilities 버전은 GitHub Enterprise Server 인스턴스와 동일한 버전이어야 합니다. 자세한 내용은 "어플라이언스에 백업 구성"을 참조하세요.

3. GitHub Enterprise Server 인스턴스에서 GitHub Actions에 임시 자체 호스팅 실행기를 사용하고 자동 업데이트를 사용하지 않도록 설정한 경우 실행기를 업그레이드한 instance 실행할 실행기 애플리케이션 버전으로 업그레이드합니다.

4. 업그레이드 패키지를 사용하여 업그레이드하는 경우 GitHub Enterprise Server 최종 사용자를 위한 유지 관리 기간을 예약합니다. 핫패치를 사용하는 경우에는 유지 관리 모드가 필요하지 않습니다.

   참고: 유지 관리 기간은 수행하는 업그레이드 유형에 따라 다릅니다. 핫패치를 사용한 업그레이드에는 일반적으로 유지 관리 기간이 필요하지 않습니다. 다시 부팅이 필요한 경우도 있으며, 나중에 수행할 수 있습니다. MAJOR.FEATURE.PATCH의 버전 관리 체계에 따라, 업그레이드 패키지를 사용한 패치 릴리스에는 일반적으로 5분 미만의 가동 중지 시간이 필요합니다. 데이터 마이그레이션을 포함하는 기능 릴리스는 스토리지 성능과 마이그레이션되는 데이터 양에 따라 더 오래 걸립니다. 자세한 내용은 "유지 관리 모드 사용 설정 및 예약"을 참조하세요.

스냅샷 만들기

스냅샷 특정 시점에 VM(가상 머신)의 상태를 저장합니다. GitHub는 업그레이드가 실패할 경우 VM을 스냅샷 다시 되돌리기 수 있도록 VM을 업그레이드하기 전에 스냅샷 사용하는 것이 좋습니다. GitHub은 instance VM의 전원이 켜지거나 instance 유지 관리 모드에 있고 모든 백그라운드 작업이 완료된 경우에만 VM 스냅샷 사용하는 것이 좋습니다.

새 기능 릴리스로 업그레이드하는 경우 VM 스냅샷을 만들어야 합니다. 패치 릴리스로 업그레이드하는 경우 기존 데이터 디스크를 연결할 수 있습니다.

다음 두 가지 유형의 스냅샷이 있습니다.

• VM 스냅샷은 사용자 데이터와 구성 데이터를 포함하여 전체 VM 상태를 저장합니다. 이 스냅샷 방법은 많은 양의 디스크 공간이 필요하며 시간이 오래 걸립니다.

• 데이터 디스크 스냅샷은 사용자 데이터만 저장합니다.

  참고:

  • 일부 플랫폼에서는 데이터 디스크만으로 스냅샷을 만들 수 없습니다. 해당 플랫폼의 경우 전체 VM 스냅샷을 만들어야 합니다.
  • 하이퍼바이저에서 전체 VM 스냅샷을 지원하지 않는 경우 루트 디스크와 데이터 디스크의 스냅샷을 빠르게 연속해서 만들어야 합니다.

플랫폼	스냅숏 메서드	설명서
Amazon AWS	디스크	AWS 설명서에서 Amazon EBS 스냅샷 만들기
Azure	VM	Microsoft Learn의 VM 설정에서 Azure VM 백업
Hyper-V	VM	Microsoft Learn의 Hyper-V에서 검사점 사용 또는 사용 안 함
Google Compute Engine	디스크	Google Cloud 설명서에서 디스크 스냅샷 만들기 및 관리
VMware	VM	VMware Docs에서 Virtual Machine의 스냅샷 만들기

업그레이드 패키지 선택

GitHub Enterprise Server instance 새 패치 릴리스 또는 새 기능 릴리스로 업그레이드할 수 있습니다. 패치 릴리스로 업그레이드하려면 핫패치 또는 업그레이드 패키지를 사용할 수 있습니다. 기능 릴리스로 업그레이드하려면 업그레이드 패키지를 사용해야 합니다.

GitHub Enterprise Server instance 하나 이상의 노드로 구성됩니다. 따라야 하는 업그레이드 프로세스는 instance 있는 노드 수에 따라 달라집니다. 자세한 내용은 "GitHub Enterprise Server 정보"을 참조하세요.

• 핫패치를 사용하여 업그레이드
  • 핫패치를 사용하여 독립 실행형 instance 업그레이드
  • 핫패치를 사용하여 여러 노드가 있는 instance 업그레이드
• 업그레이드 패키지를 사용하여 업그레이드
  • 업그레이드 패키지를 사용하여 독립 실행형 instance 업그레이드
  • 업그레이드 패키지를 사용하여 여러 노드가 있는 instance 업그레이드

핫패치를 사용하여 업그레이드

핫패치를 사용하여 GitHub Enterprise Server을(를) 최신 패치 릴리스로 업그레이드할 수 있습니다.

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

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

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

관리 콘솔을 사용하여 핫패치를 즉시 설치하거나 나중에 설치되도록 예약할 수 있습니다. 관리 셸을 사용하여 ghe-upgrade 유틸리티로 핫패치를 설치할 수 있습니다. 자세한 내용은 "업그레이드 요구 사항"을 참조하세요.

• 핫패치를 사용하여 독립 실행형 instance 업그레이드
• 핫패치를 사용하여 여러 노드가 있는 instance 업그레이드

핫패치를 사용하여 독립 실행형 instance 업그레이드

핫패치를 사용하여 하나의 노드로 instance 업그레이드하고 대상이 패치 릴리스인 경우 관리 콘솔를 사용하여 업그레이드할 수 있습니다. 기능 릴리스로 업그레이드하려면 관리 셸을 사용해야 합니다.

• 관리 콘솔을 사용하여 핫패치 설치
• 관리 셸을 사용하여 핫패치 설치

관리 콘솔을 사용하여 핫패치 설치

관리 콘솔에서 자동 업데이트를 사용하도록 설정하면 핫패치를 사용하여 업그레이드할 수 있습니다. 업그레이드할 수 있는 GitHub Enterprise Server의 사용 가능한 최신 버전이 표시됩니다.

표시되는 업그레이드 대상이 패치 릴리스가 아닌 기능 릴리스인 경우에는 관리 콘솔을 사용하여 핫패치를 설치할 수 없습니다. 대신, 관리 셸을 사용하여 핫패치를 설치해야 합니다. 자세한 내용은 “관리 셸을 사용하여 핫패치 설치”를 참조하세요.

1. 자동 업데이트를 사용하도록 설정합니다. 자세한 내용은 "자동 업데이트 검사 사용"을 참조하세요.

2. GitHub Enterprise Server의 관리 계정에서 페이지의 오른쪽 위 모서리에서 을 클릭합니다.

3. “Site admin”(사이트 관리자) 페이지에 아직 없는 경우 왼쪽 상단에서 Site admin(사이트 관리자)을 클릭합니다. 1. " 사이트 관리자" 사이드바에서 관리 콘솔를 클릭합니다. 1. 위쪽 탐색 모음에서 업데이트 클릭합니다.

   

4. 새 핫패치가 다운로드되면 패키지 설치 드롭다운 메뉴를 선택합니다.

   • 즉시 설치하려면 지금을 클릭합니다.
   • 나중에 설치하려면 이후 날짜를 선택합니다.

5. Install을 클릭합니다.

관리 셸을 사용하여 핫패치 설치

1. GitHub Enterprise Server 인스턴스에 SSH합니다. 인스턴스가 여러 노드로 구성된 경우(예: 고가용성 또는 지역 복제가 구성된 경우) 주 노드에 대한 SSH를 수행합니다. 클러스터를 사용하는 경우 임의 노드에 대해 SSH를 수행할 수 있습니다. SSH 액세스에 대한 자세한 내용은 "AUTOTITLE"을 참조하세요.

   $ ssh -p 122 admin@HOSTNAME

2. GitHub Enterprise Server 릴리스 페이지로 이동합니다. 업그레이드할 릴리스 옆에 있는 다운로드를 클릭한 다음 업그레이드 탭을 클릭합니다. 업그레이드 핫패키지( .hpkg 파일)의 URL을 복사합니다.

3. 를 사용하여 curl GitHub Enterprise Server 인스턴스로 업그레이드 패키지를 다운로드합니다.

   admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL

4. 패키지 파일 이름을 사용하여 ghe-upgrade 명령을 실행합니다.

   admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg
   *** verifying upgrade package signature...

5. 하나 이상의 서비스 또는 시스템 구성 요소에 다시 부팅이 필요한 경우 핫패치 업그레이드 스크립트가 사용자에게 알립니다. 예를 들어 커널, MySQL 또는 Elasticsearch에 대한 업데이트에는 다시 부팅이 필요할 수 있습니다.

핫패치를 사용하여 여러 노드가 있는 instance 업그레이드

핫패치를 설치하는 경우 유지 관리 모드로 전환하거나 복제를 중지할 필요가 없습니다.

• 핫패치를 사용하여 주 노드 업그레이드
• 핫패치를 사용하여 추가 노드 업그레이드

핫패치를 사용하여 주 노드 업그레이드

주 노드를 업그레이드하는 지침은 "관리 셸을 사용하여 핫패치 설치"를 참조하세요.

핫패치를 사용하여 추가 노드 업그레이드

고가용성 또는 지역 복제 구성과 같은 여러 노드로 구성된 인스턴스를 업그레이드하려면 각 복제본 노드에서 한 번에 하나씩 다음 절차를 반복해야 합니다.

1. 노드를 업그레이드하려면 "관리 셸을 사용하여 핫패치 설치"의 지침을 따릅니다.
2. 각 추가 노드에 대해 위의 단계를 반복합니다.

업그레이드 패키지를 사용하여 업그레이드

핫패치를 사용하여 기능 시리즈 내의 최신 패치 릴리스로 업그레이드할 수 있는 반면, 최신 기능 릴리스로 업그레이드하려면 업그레이드 패키지를 사용해야 합니다. 예를 들어 2.11.10에서 2.12.4로 업그레이드하려면 다른 기능 시리즈에 있으므로 업그레이드 패키지를 사용해야 합니다. 자세한 내용은 "업그레이드 요구 사항"을 참조하세요.

• 업그레이드 패키지를 사용하여 독립 실행형 instance 업그레이드
• 업그레이드 패키지를 사용하여 여러 노드가 있는 instance 업그레이드

업그레이드 패키지를 사용하여 독립 실행형 instance 업그레이드

1. GitHub Enterprise Server 인스턴스에 SSH합니다. 인스턴스가 여러 노드로 구성된 경우(예: 고가용성 또는 지역 복제가 구성된 경우) 주 노드에 대한 SSH를 수행합니다. 클러스터를 사용하는 경우 임의 노드에 대해 SSH를 수행할 수 있습니다. SSH 액세스에 대한 자세한 내용은 "AUTOTITLE"을 참조하세요.

   $ ssh -p 122 admin@HOSTNAME

2. GitHub Enterprise Server 릴리스 페이지로 이동합니다. 업그레이드할 릴리스 옆에 있는 다운로드를 클릭한 다음 업그레이드 탭을 클릭합니다. 적절한 플랫폼을 선택하고 업그레이드 패키지( .pkg 파일)의 URL을 복사합니다.

3. 를 사용하여 curl GitHub Enterprise Server 인스턴스로 업그레이드 패키지를 다운로드합니다.

   admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL

4. 유지 관리 모드를 사용하도록 설정하고 GitHub Enterprise Server 인스턴스에서 모든 활성 프로세스가 완료되기를 기다립니다. 자세한 내용은 "유지 관리 모드 사용 설정 및 예약"을 참조하세요.

   참고: 고가용성 구성에서 주 노드를 업그레이드할 때 "주 노드 업그레이드"의 지침을 따르는 경우 instance 이미 유지 관리 모드에 있어야 합니다.

5. 패키지 파일 이름을 사용하여 ghe-upgrade 명령을 실행합니다.

   admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
   *** verifying upgrade package signature...

6. 업그레이드를 계속하고 패키지 서명이 확인된 후 다시 시작하도록 확인합니다. 새 루트 파일 시스템이 보조 파티션에 쓰고, 인스턴스가 유지 관리 모드에서 자동으로 다시 시작됩니다.

   *** applying update...
   This package will upgrade your installation to version VERSION-NUMBER
   Current root partition: /dev/xvda1 [VERSION-NUMBER]
   Target root partition:  /dev/xvda2
   Proceed with installation? [y/N]

7. instance 다시 시작되면 백그라운드에서 업그레이드가 계속됩니다. 프로세스가 완료될 때까지 유지 관리 모드를 설정 해제할 수 없습니다. 진행률을 모니터링하려면 의 출력을 읽어 /data/user/common/ghe-config.log보십시오. 예를 들어 다음 명령을 실행하여 로그를 확인할 수 있습니다.

   tail -f /data/user/common/ghe-config.log

8. 필요에 따라 업그레이드의 유효성을 검사하려면 지정된 IP 주소 목록에 액세스할 수 있도록 IP 예외 목록을 구성합니다. 자세한 내용은 "유지 관리 모드 사용 설정 및 예약"을 참조하세요.

9. 단일 노드 업그레이드의 경우 사용자가 GitHub Enterprise Server 인스턴스을(를) 사용할 수 있도록 유지 관리 모드를 사용하지 않도록 설정합니다.

   참고: 고가용성 구성에서 instance 업그레이드한 후에는 모든 복제본(replica) 노드를 업그레이드하고 복제가 최신 상태일 때까지 유지 관리 모드를 유지해야 합니다. 자세한 내용은 "업그레이드 패키지를 사용하여 추가 노드 업그레이드"를 참조하세요.

업그레이드 패키지를 사용하여 여러 노드가 있는 instance 업그레이드

업그레이드 패키지를 사용하여 여러 노드로 구성된 instance 업그레이드하려면 주 노드를 업그레이드한 다음 추가 노드를 업그레이드해야 합니다.

• 업그레이드 패키지를 사용하여 주 노드 업그레이드
• 업그레이드 패키지를 사용하여 추가 노드 업그레이드

업그레이드 패키지를 사용하여 주 노드 업그레이드

1. 주 노드에서 유지 관리 모드를 사용하도록 설정하고 모든 활성 프로세스가 완료되기를 기다립니다. 자세한 내용은 "유지 관리 모드 사용 설정 및 예약"을 참조하세요.
2. 포트 122에서 사용자로 SSH를 admin 통해 복제본 노드에 연결합니다.

   $ ssh -p 122 admin@REPLICA_HOST

3. 모든 노드에서 복제를 중지하려면 각 노드에서 를 실행 ghe-repl-stop 합니다.
4. 주 노드를 업그레이드하려면 "업그레이드 패키지를 사용하여 독립 실행형 instance 업그레이드"의 지침을 따릅니다.

업그레이드 패키지를 사용하여 추가 노드 업그레이드

고가용성 또는 지역 복제 구성과 같은 여러 노드로 구성된 인스턴스를 업그레이드하려면 각 복제본 노드에서 한 번에 하나씩 다음 절차를 반복해야 합니다.

1. "업그레이드 패키지를 사용하여 독립 실행형 instance 업그레이드"의 지침에 따라 노드를 업그레이드합니다.

2. 복제본 노드에서 복제를 시작하려면 를 실행합니다 ghe-repl-start. 명령이 를 반환Replication is not running하는 경우 복제가 계속 시작될 수 있습니다. ghe-repl-status를 다시 실행하기 전에 1분 정도 기다립니다.

   참고: 재동기화가 진행 중인 ghe-repl-status 동안 복제가 뒤에 있음을 나타낼 수 있습니다. 예를 들어 다음 메시지가 표시 될 수 있습니다.

   CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists
   

• 각 노드를 GitHub Enterprise Server 3.6.0 이상으로 업그레이드하고 복제를 시작했지만 git replication is behind the primary 45분 후에도 계속 표시되는 경우 GitHub Enterprise 지원에 문의하세요. 자세한 내용은 "GitHub 지원에 문의"을 참조하세요.

• 그렇지 않으면 ghe-repl-status 이(가) 반환 OK되지 않으면 GitHub Enterprise 지원에 문의하세요. 자세한 내용은 "GitHub 지원에 문의"을 참조하세요.

1. 각 추가 노드에 대해 위의 단계를 반복합니다.
2. 마지막 복제본(replica) 노드를 업그레이드하고 다시 동기화가 완료되면 사용자가 GitHub Enterprise Server 인스턴스을(를) 사용할 수 있도록 유지 관리 모드를 사용하지 않도록 설정합니다.

실패한 업그레이드에서 복원

업그레이드가 실패하거나 중단된 경우 인스턴스를 이전 상태로 다시 되돌려야 합니다. 이 작업을 수행하는 프로세스는 업그레이드 유형에 따라 다릅니다.

패치 릴리스 롤백

패치 릴리스를 롤백하려면 ghe-upgrade 명령에 --allow-patch-rollback 스위치를 사용합니다. 롤백하기 전에 모든 복제본(replica) 노드에서 실행 ghe-repl-stop 하여 복제를 일시적으로 중지해야 합니다. 업그레이드를 롤백할 때 확장명이 .pkg인 업그레이드 패키지 파일을 사용해야 합니다. 확장명이 .hpkg인 핫패치 패키지 파일은 지원되지 않습니다.

ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg

명령을 실행한 후 다시 부팅해야 합니다. 마이그레이션은 패치 릴리스에서 실행되지 않으므로 롤백은 데이터 파티션에 영향을 주지 않습니다.

롤백이 완료되면 모든 노드에서 를 실행 ghe-repl-start 하여 복제를 다시 시작합니다.

자세한 내용은 "명령줄 유틸리티"을 참조하세요.

기능 릴리스 롤백

기능 릴리스에서 롤백하려면 VM 스냅샷에서 복원하여 루트 및 데이터 파티션을 일관된 상태로 유지합니다. 자세한 내용은 “스냅샷 만들기”를 참조하세요.

추가 참고 자료

• "새 릴리스로 업그레이드 정보"