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](https://github.com/github/backup-utils#readme) を使用してデータをバックアップします。 -
任意のノードの管理シェルから、
ghe-cluster-hotpatchコマンドを使用して最新のホットパッチをインストールします。 ホットパッチの URL を指定するか、手動でホットパッチをダウンロードしてローカルのファイル名を指定することができます。ghe-cluster-hotpatch https://HOTPATCH-URL/FILENAME.hpkg
アップグレードパッケージでのアップグレード
アップグレードパッケージを使用して、GitHub Enterprise Server クラスタを最新のフィーチャリリースにアップグレードします。 たとえば、2.11 から 2.13 にアップグレードできます。
アップグレードの準備
-
アップグレードするバージョンの クラスタのネットワーク設定を確認し、必要に応じて構成を更新します。
-
[GitHub Enterprise Server Backup Utilities](https://github.com/github/backup-utils#readme) を使用してデータをバックアップします。 -
アップグレード中は通常どおりに使用できないため、GitHub Enterprise Serverクラスタのエンドユーザーに対してメンテナンス期間をスケジュールします。 メンテナンスモードは、クラスタのアップグレードの進行中、ユーザーのアクセスをブロックし、データが変更されないようにします。
-
[GitHub Enterprise Server のダウンロード ページ](https://enterprise.github.com/download)で、アップグレード _.pkg_ ファイルの URL をクリップボードにコピーします。 -
任意のノードの管理シェルから、
ghe-cluster-eachコマンドをcurlと組み合わせて使用して、1 つの手順でリリース パッケージを各ノードにダウンロードします。 先ほどのステップでコピーした 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 -
`mysql-master = <hostname>` で `cluster.conf` として定義されているプライマリ MySQL ノードを特定します。 このノードは最後にアップグレードされます。
クラスタノードのアップグレード
-
任意のクラスター ノードの管理シェルに接続して
ghe-cluster-maintenance -sを実行して、スケジュールされた期間に従ってメンテナンス モードを有効にします。 -
**プライマリ MySQL ノードを除き**、GitHub Enterprise Server の各ノードの管理シェルに接続します。 `ghe-upgrade` コマンドを実行し、[準備手順](#preparing-to-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できることを確認します。重要
次の手順に進む前に、アップグレード後の構成が完了するまで待つことが必要です。 構成実行の進行状況を監視するには、
/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` を実行して、任意のノードの管理シェルからメンテナンス モードを終了します。