클러스터 업그레이드

GitHub Enterprise Server 클러스터를 최신 릴리스로 업그레이드하려면 관리 셸(SSH)을 사용합니다.

누가 이 기능을 사용할 수 있나요?

GitHub은(는) 클러스터링 자격을 결정하며 인스턴스의 라이선스 구성을 사용하도록 설정해야 합니다. 클러스터링은 신중하게 계획해야 하며 관리 오버헤드가 추가로 필요합니다. 자세한 내용은 "클러스터링 정보"을(를) 참조하세요.

이 문서의 내용

GitHub Enterprise Server 클러스터로의 업그레이드 정보

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

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

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

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

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

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

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

  1. GitHub Enterprise Server Backup Utilities를 사용하여 데이터를 백업합니다.

  2. 임의 노드의 관리 셸에서 ghe-cluster-hotpatch 명령을 사용하여 최신 핫패치를 설치합니다. 핫패치에 URL을 제공하거나, 수동으로 핫패치를 다운로드하고 로컬 파일 이름을 지정할 수 있습니다.

    ghe-cluster-hotpatch https://HOTPATCH-URL/FILENAME.hpkg

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

업그레이드 패키지를 사용하여 GitHub Enterprise Server 클러스터를 최신 기능 릴리스로 업그레이드합니다. 예를 들어 2.11에서 2.13으로 업그레이드할 수 있습니다.

업그레이드 준비

  1. 업그레이드할 대상 버전의 클러스터 네트워크 구성을 검토하고 필요에 따라 사용 중인 구성을 업데이트합니다.

  2. GitHub Enterprise Server Backup Utilities를 사용하여 데이터를 백업합니다.

  3. 업그레이드하는 동안 정상적으로 사용할 수 없으므로 GitHub Enterprise Server 클러스터의 최종 사용자를 위해 유지 관리 기간을 예약합니다. 유지 관리 모드는 클러스터 업그레이드가 진행되는 동안 사용자 액세스를 차단하고 데이터 변경을 방지합니다.

  4. GitHub Enterprise Server 다운로드 페이지에서 업그레이드 .pkg 파일의 URL을 클립보드에 복사합니다.

  5. 임의 노드의 관리 셸에서 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

  6. cluster.conf에서 mysql-master = <hostname>으로 정의된 주 MySQL 노드를 식별합니다. 이 노드가 마지막으로 업그레이드됩니다.

클러스터 노드 업그레이드

  1. 임의 클러스터 노드의 관리 셸에 연결하고 ghe-cluster-maintenance -s를 실행하여 예약된 기간에 따라 유지 관리 모드를 사용하도록 설정합니다.

  2. 버전 3.11 또는 3.12에서 버전 3.13 이상으로 업그레이드하는 경우 Elasticsearch는 클러스터 업그레이드의 일부로 업그레이드됩니다. 자세한 내용은 GitHub Enterprise Server 3.13에서 Elasticsearch 업그레이드 준비을(를) 참조하세요.

    업그레이드하기 전에 스크립트를 실행하여 3.13 또는 3.14로 업그레이드할 클러스터를 준비해야 합니다.

    1. 현재 버전에 필요한 패치 릴리스인 3.11.9 이상(3.11의 경우) 또는 3.12.3 이상(3.12의 경우)을 실행하고 있는지 확인합니다.
    2. 모든 elasticsearch-server 노드에서 /usr/local/share/enterprise/ghe-es-auditlog-cluster-rebalance를 실행합니다.

  3. 주 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>"

  4. 업그레이드 프로세스가 완료되면 노드가 다시 부팅됩니다. 다시 부팅된 후 각 노드에 ping을 사용할 수 있는지 확인합니다.

  5. 주 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>"

  6. 업그레이드 프로세스가 완료되면 주 MySQL 노드가 다시 부팅됩니다. 다시 부팅된 후 각 노드에 ping을 사용할 수 있는지 확인

    Important

    다음 단계를 진행하기 전에 업그레이드 후 구성이 완료되기를 기다려야 합니다. 구성 실행의 진행률을 모니터링하려면 /data/user/common/ghe-config.log에서 출력을 읽습니다. 예를 들어 다음 명령을 실행하여 로그 파일의 끝부분을 확인할 수 있습니다.

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

  7. 주 MySQL 노드의 관리 셸에 연결하고 ghe-cluster-config-apply 명령을 실행합니다.

  8. ghe-cluster-config-apply가 완료되면 ghe-cluster-status를 실행하여 서비스가 정상 상태인지 확인합니다.

  9. 임의 노드의 관리 셸에서 ghe-cluster-maintenance -u를 실행하여 유지 관리 모드를 종료합니다.