GitHub Enterprise Server 클러스터로의 업그레이드 정보
GitHub Enterprise Server는 기능 및 패치 릴리스를 통해 도입된 새로운 기능과 버그 수정을 통해 지속적으로 개선되고 있습니다. 인스턴스로 업그레이드하는 것은 사용자의 책임입니다. 자세한 내용은 "새 릴리스로 업그레이드 정보"을(를) 참조하세요.
인스턴스를 업그레이드하려면 업그레이드를 계획하고 전달하고, 적절한 패키지를 선택하고, 데이터를 백업한 다음 업그레이드를 수행해야 합니다.
핫패치를 사용하여 업그레이드
핫패치를 사용하여 GitHub Enterprise Server을(를) 최신 패치 릴리스로 업그레이드할 수 있습니다.
핫패칭을 사용하여 최신 패치 릴리스로 업그레이드할 수 있지만 기능 릴리스는 업그레이드할 수 없습니다. 예를 들어 2.10.1에서 2.10.5로 업그레이드하는 것은 동일한 기능 시리즈에 속하므로 가능하지만, 2.10.9에서 2.11.0으로 업그레이드하는 것은 다른 기능 시리즈에 속하므로 불가능합니다.
핫패치는 반드시 다시 부팅할 필요는 없습니다. 핫패치를 설치하면 업데이트를 완료하기 위해 패키지를 다시 부팅해야 하는 경우 터미널에 메시지가 표시됩니다. 이 재부팅은 편리한 시간에 예약할 수 있지만, 특히 보안 수정 사항이 있는 경우 최대한 빨리 다시 부팅하는 것이 좋습니다.
핫패치는 구성을 실행해야 하므로, 이로 인해 GitHub Enterprise Server 인스턴스의 일부 또는 모든 서비스가 잠시 동안 오류를 일으키거나 응답이 없을 수 있습니다. 핫패치를 설치하는 동안 유지 관리 모드를 사용하도록 설정할 필요는 없지만, 이렇게 하면 사용자에게 오류나 시간 제한 대신 유지 관리 페이지가 표시되도록 할 수 있습니다. "유지 관리 모드 사용 설정 및 예약" 항목을 참조하세요. 핫패치 설치 스크립트는 클러스터의 모든 노드에 핫패치를 설치하고, 가동 중지 시간을 방지하기 위해 적절한 순서로 서비스를 다시 시작합니다.
-
GitHub Enterprise Server Backup Utilities를 사용하여 데이터를 백업합니다.
-
임의 노드의 관리 셸에서
ghe-cluster-hotpatch
명령을 사용하여 최신 핫패치를 설치합니다. 핫패치에 URL을 제공하거나, 수동으로 핫패치를 다운로드하고 로컬 파일 이름을 지정할 수 있습니다.ghe-cluster-hotpatch https://HOTPATCH-URL/FILENAME.hpkg
업그레이드 패키지를 사용하여 업그레이드
업그레이드 패키지를 사용하여 GitHub Enterprise Server 클러스터를 최신 기능 릴리스로 업그레이드합니다. 예를 들어 2.11
에서 2.13
으로 업그레이드할 수 있습니다.
업그레이드 준비
-
업그레이드할 대상 버전의 클러스터 네트워크 구성을 검토하고 필요에 따라 사용 중인 구성을 업데이트합니다.
-
GitHub Enterprise Server Backup Utilities를 사용하여 데이터를 백업합니다.
-
업그레이드하는 동안 정상적으로 사용할 수 없으므로 GitHub Enterprise Server 클러스터의 최종 사용자를 위해 유지 관리 기간을 예약합니다. 유지 관리 모드는 클러스터 업그레이드가 진행되는 동안 사용자 액세스를 차단하고 데이터 변경을 방지합니다.
-
GitHub Enterprise Server 다운로드 페이지에서 업그레이드 .pkg 파일의 URL을 클립보드에 복사합니다.
-
임의 노드의 관리 셸에서
curl
과 결합된ghe-cluster-each
명령을 사용하여 단일 단계로 각 노드에 릴리스 패키지를 다운로드합니다. 이전 단계에서 복사한 URL을 인수로 사용합니다.$ ghe-cluster-each -- "cd /home/admin && curl -L -O https://PACKAGE-URL.pkg" > ghe-app-node-1: % Total % Received % Xferd Average Speed Time Time Time Current > ghe-app-node-1: Dload Upload Total Spent Left Speed > 100 496M 100 496M 0 0 24.2M 0 0:00:20 0:00:20 --:--:-- 27.4M > ghe-data-node-2: % Total % Received % Xferd Average Speed Time Time Time Current > ghe-data-node-2: Dload Upload Total Spent Left Speed > 100 496M 100 496M 0 0 21.3M 0 0:00:23 0:00:23 --:--:-- 25.8M > ghe-data-node-1: % Total % Received % Xferd Average Speed Time Time Time Current > ghe-data-node-1: Dload Upload Total Spent Left Speed > 100 496M 100 496M 0 0 19.7M 0 0:00:25 0:00:25 --:--:-- 25.6M > ghe-app-node-2: % Total % Received % Xferd Average Speed Time Time Time Current > ghe-app-node-2: Dload Upload Total Spent Left Speed > 100 496M 100 496M 0 0 19.8M 0 0:00:25 0:00:25 --:--:-- 17.6M > ghe-data-node-3: % Total % Received % Xferd Average Speed Time Time Time Current > ghe-data-node-3: Dload Upload Total Spent Left Speed > 100 496M 100 496M 0 0 19.7M 0 0:00:25 0:00:25 --:--:-- 25.5M
-
cluster.conf
에서mysql-master = <hostname>
으로 정의된 주 MySQL 노드를 식별합니다. 이 노드가 마지막으로 업그레이드됩니다.
클러스터 노드 업그레이드
-
임의 클러스터 노드의 관리 셸에 연결하고
ghe-cluster-maintenance -s
를 실행하여 예약된 기간에 따라 유지 관리 모드를 사용하도록 설정합니다. -
버전 3.11 또는 3.12에서 버전 3.13 이상으로 업그레이드하는 경우 Elasticsearch는 클러스터 업그레이드의 일부로 업그레이드됩니다. 자세한 내용은 "GitHub Enterprise Server 3.13에서 Elasticsearch 업그레이드 준비"을(를) 참조하세요.
업그레이드하기 전에 스크립트를 실행하여 3.13 또는 3.14로 업그레이드할 클러스터를 준비해야 합니다.
- 현재 버전에 필요한 패치 릴리스인 3.11.9 이상(3.11의 경우) 또는 3.12.3 이상(3.12의 경우)을 실행하고 있는지 확인합니다.
- 모든
elasticsearch-server
노드에서/usr/local/share/enterprise/ghe-es-auditlog-cluster-rebalance
를 실행합니다.
-
주 MySQL 노드를 제외하고 각 GitHub Enterprise Server 노드의 관리 셸에 연결합니다.
ghe-upgrade
업그레이드 준비의 4단계에서 다운로드한 패키지 파일 이름을 제공하여 명령을 실행합니다.$ ghe-upgrade PACKAGE-FILENAME.pkg > *** verifying upgrade package signature... > 497MB 0:00:04 [ 117MB/s] [==========================================>] 100% > gpg: Signature made Fri 19 Feb 2016 02:33:50 PM UTC using RSA key ID 0D65D57A > gpg: checking the trustdb > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u > gpg: Good signature from "GitHub Enterprise (Upgrade Package Key) > <enterprise@github.com>"
-
업그레이드 프로세스가 완료되면 노드가 다시 부팅됩니다. 다시 부팅된 후 각 노드에
ping
을 사용할 수 있는지 확인합니다. -
주 MySQL 노드의 관리 셸에 연결합니다.
ghe-upgrade
업그레이드 준비의 4단계에서 다운로드한 패키지 파일 이름을 제공하여 명령을 실행합니다.$ ghe-upgrade PACKAGE-FILENAME.pkg > *** verifying upgrade package signature... > 497MB 0:00:04 [ 117MB/s] [==========================================>] 100% > gpg: Signature made Fri 19 Feb 2016 02:33:50 PM UTC using RSA key ID 0D65D57A > gpg: checking the trustdb > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u > gpg: Good signature from "GitHub Enterprise (Upgrade Package Key) > <enterprise@github.com>"
-
업그레이드 프로세스가 완료되면 주 MySQL 노드가 다시 부팅됩니다. 다시 부팅된 후 각 노드에
ping
을 사용할 수 있는지 확인Important
다음 단계를 진행하기 전에 업그레이드 후 구성이 완료되기를 기다려야 합니다. 구성 실행의 진행률을 모니터링하려면
/data/user/common/ghe-config.log
에서 출력을 읽습니다. 예를 들어 다음 명령을 실행하여 로그 파일의 끝부분을 확인할 수 있습니다.tail -f /data/user/common/ghe-config.log
-
주 MySQL 노드의 관리 셸에 연결하고
ghe-cluster-config-apply
명령을 실행합니다. -
ghe-cluster-config-apply
가 완료되면ghe-cluster-status
를 실행하여 서비스가 정상 상태인지 확인합니다. -
임의 노드의 관리 셸에서
ghe-cluster-maintenance -u
를 실행하여 유지 관리 모드를 종료합니다.