Skip to main content
설명서에 자주 업데이트를 게시하며 이 페이지의 번역이 계속 진행 중일 수 있습니다. 최신 정보는 영어 설명서를 참조하세요.

GitHub Enterprise 서버 업그레이드

GitHub Enterprise Server를 업그레이드하여 최신 기능 및 보안 업데이트를 가져옵니다.

업그레이드 준비

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

  2. GitHub Enterprise Server Backup Utilities를 사용하여 주 인스턴스의 새 백업을 만듭니다. 자세한 내용은 GitHub Enterprise Server Backup Utilities 프로젝트 설명서의 README.md 파일을 참조하세요.

    참고: GitHub Enterprise Server Backup Utilities 버전은 GitHub Enterprise Server 인스턴스와 동일한 버전이어야 합니다. 자세한 내용은 “GitHub Enterprise 서버 백업 유틸리티 업그레이드”를 참조하세요.

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

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

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

스냅샷 만들기

스냅샷은 특정 시점의 VM(가상 머신) 검사점입니다. 업그레이드에 실패할 경우 VM을 스냅샷으로 되돌릴 수 있도록 가상 머신을 업그레이드하기 전에 스냅샷을 만드는 것이 좋습니다. 어플라이언스의 전원이 꺼졌거나 유지 관리 모드에 있고 모든 백그라운드 작업이 완료된 경우에만 VM 스냅샷을 만드는 것이 좋습니다.

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

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

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

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

    참고:

    • 일부 플랫폼에서는 데이터 디스크만으로 스냅샷을 만들 수 없습니다. 해당 플랫폼의 경우 전체 VM 스냅샷을 만들어야 합니다.
    • 하이퍼바이저에서 전체 VM 스냅샷을 지원하지 않는 경우 루트 디스크와 데이터 디스크의 스냅샷을 빠르게 연속해서 만들어야 합니다.
플랫폼스냅숏 메서드스냅샷 설명서 URL
Amazon AWS디스크https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
AzureVMhttps://docs.microsoft.com/azure/backup/backup-azure-vms-first-look-arm
Hyper-VVMhttps://docs.microsoft.com/windows-server/virtualization/hyper-v/manage/enable-or-disable-checkpoints-in-hyper-v
Google Compute Engine디스크https://cloud.google.com/compute/docs/disks/create-snapshots
VMwareVMhttps://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.hostclient.doc/GUID-64B866EF-7636-401C-A8FF-2B4584D9CA72.html

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

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

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

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

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

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

참고 :

  • GitHub Enterprise Server 인스턴스이(가) 릴리스 후보 빌드를 실행하는 경우 핫패치로 업그레이드할 수 없습니다.

  • 클러스터형 환경에서는 관리 콘솔을 사용하여 핫패치를 설치할 수 없습니다. 클러스터형 환경에 핫패치를 설치하려면 “클러스터 업그레이드”를 참조하세요.

핫패치를 사용하여 단일 어플라이언스 업그레이드

핫패치를 사용하여 단일 어플라이언스 업그레이드 중이고 대상이 패치 릴리스인 경우 관리 콘솔을(를) 사용할 수 있습니다. 기능 릴리스로 업그레이드하려면 관리 셸을 사용해야 합니다.

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

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

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

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

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

    사이트 관리자 설정에 액세스하기 위한 우주선 아이콘 스크린샷

  3. “Site admin”(사이트 관리자) 페이지에 아직 없는 경우 왼쪽 상단에서 Site admin(사이트 관리자)을 클릭합니다.

    “Site admin”(사이트 관리자) 링크 스크린샷 1. 왼쪽 사이드바에서 관리 콘솔 을 클릭합니다. 왼쪽 사이드바의 관리 콘솔 탭 1. 관리 콘솔의 상단에서 업데이트를 클릭합니다. 업데이트 메뉴 항목

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

    • 즉시 설치하려면 지금을 선택합니다.
    • 나중에 설치하려면 이후 날짜를 선택합니다. 핫패치 설치 날짜 드롭다운
  5. 설치를 클릭합니다. 핫패치 설치 단추

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

참고: 자동 업데이트 검사를 사용하도록 설정한 경우 업그레이드 패키지를 다운로드할 필요가 없으며 자동으로 다운로드된 파일을 사용할 수 있습니다. 자세한 내용은 “자동 업데이트 검사 사용”을 참조하세요.

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

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

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

    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 또는 기타 프로그램의 업데이트에 다시 부팅이 필요한 경우 핫패치 업그레이드 스크립트에서 알려줍니다.

핫패치를 사용하여 복제본 인스턴스가 있는 어플라이언스 업그레이드

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

고가용성 및 지역 복제가 구성된 어플라이언스는 주 인스턴스뿐 아니라 복제본 인스턴스도 사용합니다. 해당 어플라이언스를 업그레이드하려면 주 인스턴스와 모든 복제본 인스턴스를 한 번에 하나씩 둘 다 업그레이드해야 합니다.

핫패치를 사용하여 주 인스턴스 업그레이드

  1. 관리 셸을 사용하여 핫패치 설치”의 지침에 따라 주 인스턴스를 업그레이드합니다.

핫패치를 사용하여 복제본 인스턴스 업그레이드

참고: 지역 복제의 일부로 여러 복제본 인스턴스를 실행하는 경우 각 복제본 인스턴스에 대해 이 절차를 한 번에 하나씩 반복합니다.

  1. 관리 셸을 사용하여 핫패치 설치”의 지침에 따라 복제본 인스턴스를 업그레이드합니다. 지역 복제에 여러 복제본을 사용하는 경우 이 절차를 반복하여 각 복제본을 한 번에 하나씩 업그레이드해야 합니다.

  2. 포트 122에서 “관리자” 사용자로 SSH를 통해 복제본 인스턴스에 연결합니다.

    $ ssh -p 122 admin@REPLICA_HOST
    1. 다음을 실행하여 업그레이드를 확인합니다.
    $ ghe-version

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

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

업그레이드 패키지를 사용하여 단일 어플라이언스 업그레이드

참고: 자동 업데이트 검사를 사용하도록 설정한 경우 업그레이드 패키지를 다운로드할 필요가 없으며 자동으로 다운로드된 파일을 사용할 수 있습니다. 자세한 내용은 “자동 업데이트 검사 사용”을 참조하세요.

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

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

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

    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
  4. 유지 관리 모드를 사용하도록 설정하고 GitHub Enterprise Server 인스턴스에서 모든 활성 프로세스가 완료되기를 기다립니다. 자세한 내용은 “유지 관리 모드 사용 및 예약”을 참조하세요.

    참고: 고가용성 구성의 주 어플라이언스를 업그레이드할 때 “주 인스턴스 업그레이드”의 지침을 따르는 경우 어플라이언스가 이미 유지 관리 모드에 있어야 합니다.

  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. 필요에 따라 업그레이드의 유효성을 검사하려면 지정된 IP 주소 목록에 액세스할 수 있도록 IP 예외 목록을 구성합니다. 자세한 내용은 “IP 예외 목록을 사용하여 유지 관리 모드의 변경 내용 유효성 검사”를 참조하세요.

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

    참고: 고가용성 구성의 어플라이언스를 업그레이드하는 경우 모든 복제본이 업그레이드되고 복제가 최신 상태가 될 때까지 유지 관리 모드를 유지해야 합니다. 자세한 내용은 “복제본 인스턴스 업그레이드”를 참조하세요.

업그레이드 패키지를 사용하여 복제본 인스턴스가 있는 어플라이언스 업그레이드

고가용성 및 지역 복제가 구성된 어플라이언스는 주 인스턴스뿐 아니라 복제본 인스턴스도 사용합니다. 해당 어플라이언스를 업그레이드하려면 주 인스턴스와 모든 복제본 인스턴스를 한 번에 하나씩 둘 다 업그레이드해야 합니다.

업그레이드 패키지를 사용하여 주 인스턴스 업그레이드

경고: 복제가 중지된 경우 주 인스턴스에서 오류가 발생하면 복제본이 업그레이드되고 복제가 다시 시작되기 전에 수행된 모든 작업이 손실됩니다.

  1. 주 인스턴스에서 유지 관리 모드를 사용하도록 설정하고 모든 활성 프로세스가 완료되기를 기다립니다. 자세한 내용은 “유지 관리 모드 사용”을 참조하세요.
  2. 포트 122에서 “관리자” 사용자로 SSH를 통해 복제본 인스턴스에 연결합니다.
    $ ssh -p 122 admin@REPLICA_HOST
  3. 복제본 인스턴스 또는 지역 복제의 일부로 여러 복제본 인스턴스를 실행하는 경우 모든 복제본 인스턴스에서 ghe-repl-stop을 실행하여 복제를 중지합니다.
  4. 업그레이드 패키지를 사용하여 단일 어플라이언스 업그레이드”의 지침에 따라 주 인스턴스를 업그레이드합니다.

업그레이드 패키지를 사용하여 복제본 인스턴스 업그레이드

참고: 지역 복제의 일부로 여러 복제본 인스턴스를 실행하는 경우 각 복제본 인스턴스에 대해 이 절차를 한 번에 하나씩 반복합니다.

  1. 업그레이드 패키지를 사용하여 단일 어플라이언스 업그레이드”의 지침에 따라 복제본 인스턴스를 업그레이드합니다. 지역 복제에 여러 복제본을 사용하는 경우 이 절차를 반복하여 각 복제본을 한 번에 하나씩 업그레이드해야 합니다.

  2. 포트 122에서 “관리자” 사용자로 SSH를 통해 복제본 인스턴스에 연결합니다.

    $ ssh -p 122 admin@REPLICA_HOST
    1. 다음을 실행하여 업그레이드를 확인합니다.
    $ ghe-version
  3. 복제본 인스턴스에서 복제를 시작하려면 ghe-repl-start를 실행합니다.

  4. 복제본 인스턴스에서 복제 서비스가 올바르게 실행되고 있는지 확인하려면 ghe-repl-status를 실행합니다. 성공적인 복제가 진행 중이고 복제본이 업그레이드된 경우 이 명령은 모든 서비스에 대해 OK를 반환합니다. 명령에서 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 지원에서 도움받기”를 참조하세요.

  5. 마지막 복제본 업그레이드를 완료하고 다시 동기화가 완료되면 사용자가 GitHub Enterprise Server 인스턴스을(를) 사용할 수 있도록 유지 관리 모드를 사용하지 않도록 설정합니다.

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

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

패치 릴리스 롤백

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

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

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

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

자세한 내용은 “명령줄 유틸리티”를 참조하세요.

기능 릴리스 롤백

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

추가 참고 자료