GitHub Enterprise Server をアップグレードする
最新の機能とセキュリティアップデートを入手するために、GitHub Enterprise Server をアップグレードしてください。
このガイドの内容
アップグレードの準備
-
アップグレードの戦略を決定し、アップグレード先のバージョンを選択してください。 詳しい情報については"アップグレードの要求事項"を参照してください。
-
GitHub Enterprise Server 2.14 または 2.15 に (2.12 または 2.13 から) アップグレードする場合は、検索あるいは webhook インデックスを Elasticsearch 5.6 へ移行するための移行スクリプトをダウンロードして実行してください。詳細は「Elasticsearch インデックスを GitHub Enterprise Server 2.14 以降に移行する」を参照してください。
-
GitHub Enterprise Serverバックアップユーティリティで、プライマリインスタンスの新しいバックアップを作成してください。 詳しい情報についてはGitHub Enterprise ServerバックアップユーティリティREADME.mdファイルを参照してください。
-
アップグレードパッケージを使ってアップグレードをする場合は、GitHub Enterprise Server のエンドユーザのためにメンテナンス時間枠をスケジューリングしてください。 ホットパッチを利用しているなら、メンテナンスモードは必要ありません。
メモ: メンテナンスウィンドウは、実行しようとしているアップグレードの種類によります。 ホットパッチを利用するアップグレードは、通常メンテナンスウィンドウを必要としません。 リブートが必要になることもあります。そのリブートは後で行うことができます。 MAJOR.FEATURE.PATCH というバージョン付けのスキームに従ったパッチリリースをアップグレードパッケージを行うには、通常 5 分未満のダウンタイムだけが必要です。 データの移行を含むフィーチャリリースは、ストレージのパフォーマンス及び移行するデータの量に応じて時間が長くかかります。 詳しい情報については"メンテナンスモードの有効化とスケジューリング"を参照してください。
スナップショットの取得
スナップショットは、ある時点での仮想マシン(VM)のチェックポイントです。 アップグレードに失敗した場合にスナップショットからVMを回復できるよう、仮想マシンをアップグレードする前にスナップショットを取っておくことを強くおすすめします。 新しいフィーチャリリースにアップグレードするなら、VM のスナップショットを取らなければなりません。 パッチリリースへのアップグレードをするなら、既存のデータディスクをアタッチできます。
スナップショットには2種類あります。
-
VM スナップショットは、ユーザデータおよび設定データを含む VM の状態全体を保存します。 このスナップショットの手法には大量のディスク領域が必要になり、時間がかかります。
-
データディスクスナップショットはユーザデータだけを保存します。
注釈:
- プラットフォームによっては、ユーザのデータディスクだけのスナップショットを取ることができません。 それらのプラットフォームでは、VM 全体のスナップショットを取る必要があります。
- ハイパーバイザーが完全なVMスナップショットをサポートしていないなら、ルートディスクとデータディスクのスナップショットを時間をおかずに取らなければなりません。
プラットフォーム | スナップショットの取得方法 | スナップショットドキュメンテーションのURL |
---|---|---|
Amazon AWS | ディスク | https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html |
Azure | VM | https://docs.microsoft.com/ja-jp/azure/backup/backup-azure-vms-first-look-arm |
Hyper-V | VM | https://technet.microsoft.com/en-us/library/dd851843.aspx |
Google Compute Engine | ディスク | https://cloud.google.com/compute/docs/disks/create-snapshots |
VMware | VM | https://pubs.vmware.com/vsphere-50/index.jsp#com.vmware.vsphere.vm_admin.doc_50/GUID-9720B104-9875-4C2C-A878-F1C351A4F3D8.html |
XenServer | VM | https://support.citrix.com/article/CTX122978 |
ホットパッチでのアップグレード
You can upgrade GitHub Enterprise Server to the latest patch release using a hotpatch, which does not require a maintenance window and usually does not require a reboot. You can use hotpatching to upgrade to a newer patch release, but not a feature release. For example, you can upgrade from 2.10.1
to 2.10.5
because they are in the same feature series, but not from 2.10.9
to 2.11.0
because they are in a different feature series.
Management Console を使うと、ホットパッチを即座にインストールすることや、後にインストールするようにスケジュールすることができます。 管理シェルを使って ghe-upgrade
ユーティリティでホットパッチをインストールすることもできます。 詳細は「アップグレードの要求事項」を参照してください。
ホットパッチでの単一のアプライアンスのアップグレード
Management Consoleを使ったホットパッチのインストール
クラスタ環境では、Management Console を使ったホットパッチのインストールはできません。 クラスタ環境でホットパッチをインストールするには、「管理シェルを使ってホットパッチをインストールする」を参照してください。
-
自動アップデートを有効化してください。 For more information, see "Enabling automatic updates."
-
In the upper-right corner of any page, click .
-
左サイドバーで [Management Console] をクリックします。
-
At the top of the Management Console, click Updates.
-
新しいホットパッチがダウンロードされたなら、Install package(パッケージのインストール)ドロップダウンメニューを使ってください。
- すぐにインストールするならNow(即時)を選択してください。
- 後でインストールするなら、後の日付を選択してください。
-
[Install] をクリックします。
管理シェルを使ったホットパッチのインストール
Note: If you've enabled automatic update checks, you don't need to download the upgrade package and can use the file that was automatically downloaded. For more information, see "Enabling automatic update checks."
-
SSH into GitHub Enterprise Server インスタンス.
$ ssh -p 122 admin@HOSTNAME
-
Browse to the GitHub Enterprise Server Releases page. Next to the release you are upgrading to, click Download, then click the Upgrading tab.アップグレードのホットパッケージ(.hpkgファイル)のURLをコピーしてください。
-
Download the upgrade package to GitHub Enterprise Server インスタンス using
curl
:admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
-
パッケージのファイル名を使って
ghe-upgrade
コマンドを実行してください。admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg*** verifying upgrade package signature...
-
カーネル、MySQL、Elasticsearch やその他のプログラムのアップグレードにリブートが必要なら、ホットパッチアップグレードスクリプトが通知してくれます。
ホットパッチを使ったレプリカインスタンスを持つアプライアンスのアップグレード
High Availability と Geo-replication が設定されたアプライアンスは、プライマリインスタンスに加えてレプリカインスタンスを使います。 これらのアプライアンスをアップグレードするには、プライマリインスタンスとすべてのレプリカインスタンスの両方を、1 つずつアップグレードしなければなりません。
プライマリインスタンスのアップグレード
- 「管理シェルを使ってホットパッチをインストールする」の指示に従ってプライマリインスタンスをアップグレードしてください。
レプリカインスタンスのアップグレード
メモ: Geo-replication の一部として複数のレプリカインスタンスを動作させているなら、この手順は各レプリカインスタンス 1 つずつに繰り返してください。
-
「管理シェルを使ってホットパッチをインストールする」の指示に従ってレプリカインスタンスをアップグレードしてください。Geo-replication のために複数のレプリカを使っているなら、この手順は各レプリカ 1 つずつに繰り返さなければなりません。
-
Connect to the replica instance over SSH as the "admin" user on port 122:
$ ssh -p 122 admin@replica-host
-
Verify the upgrade by running:
$ ghe-version
ホットパッチのインストールの取り消し
If a hotpatch installation introduces any problems or unexpected behavior, you can use the ghe-upgrade --allow-patch-rollback
command to install a regular upgrade package (.pkg) of the previous version.
アップグレードパッケージでのアップグレード
フィーチャシリーズ内の最新のパッチリリースへのアップグレードにはホットパッチが利用できますが、新しいフィーチャリリースへのアップグレードにはアップグレードパッケージを使わなければなりません。 たとえば 2.11.10
から 2.12.4
へのアップグレードの場合、これらは異なるフィーチャシリーズなので、アップグレードパッケージを使わなければなりません。 詳細は「アップグレードの要求事項」を参照してください。
アップグレードパッケージでの単一のアプライアンスのアップグレード
Note: If you've enabled automatic update checks, you don't need to download the upgrade package and can use the file that was automatically downloaded. For more information, see "Enabling automatic update checks."
-
SSH into GitHub Enterprise Server インスタンス.
$ ssh -p 122 admin@HOSTNAME
-
Browse to the GitHub Enterprise Server Releases page. Next to the release you are upgrading to, click Download, then click the Upgrading tab. 適切なプラットフォームを選択し、アップグレードパッケージ (.pkgファイル) の URL をコピーしてください。
-
Download the upgrade package to GitHub Enterprise Server インスタンス using
curl
:admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
-
メンテナンスモードを有効にし、GitHub Enterprise Server インスタンス上のすべてのアクティブなプロセスが完了するのを待ってください。 詳しい情報については"メンテナンスモードの有効化とスケジューリング"を参照してください。
メモ: High Availability 構成のプライマリアプライアンスをアップグレードする場合には、「プライマリインスタンスをアップグレードする」の指示に従っているならアプライアンスはメンテナンスモードになっているはずです。
-
パッケージのファイル名を使って
ghe-upgrade
コマンドを実行してください。admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg*** verifying upgrade package signature...
-
アップグレードを続けてパッケージ署名検証後に再起動することを承諾します。 新しいルートファイルシステムがセカンダリパーティションに書かれ、インスタンスは自動的にメンテナンスモードで再起動します。
*** applying update... This package will upgrade your installation to version version-numberCurrent root partition: /dev/xvda1 [version-number] Target root partition: /dev/xvda2 Proceed with installation? [y/N]
-
単一アプライアンスのアップグレードであれば、メンテナンスモードを無効化してユーザが GitHub Enterprise Server インスタンス を利用できるようにしてください。
メモ: High Availability 設定のアプライアンスをアップグレードする場合、すべてのレプリカをアップグレードし、レプリケーションが最新の状態になるまではメンテナンスモードのままでなければなりません。 詳細は「レプリカインスタンスをアップグレードする」を参照してください。
アップグレードパッケージを使ったレプリカインスタンスを持つアプライアンスのアップグレード
High Availability と Geo-replication が設定されたアプライアンスは、プライマリインスタンスに加えてレプリカインスタンスを使います。 これらのアプライアンスをアップグレードするには、プライマリインスタンスとすべてのレプリカインスタンスの両方を、1 つずつアップグレードしなければなりません。
プライマリインスタンスのアップグレード
警告: レプリケーションが停止されると、プライマリに障害があった場合には、レプリカがアップグレードされてレプリケーションが再開されるまでに行われた作業は失われます。
-
プライマリインスタンスでメンテナンスモードを有効化し、すべてのアクティブなプロセスが完了するのを待ちます。 For more information, see "Enabling maintenance mode."
-
Connect to the replica instance over SSH as the "admin" user on port 122:
$ ssh -p 122 admin@replica-host
-
レプリカインスタンス、あるいは Geo-replication の一部として複数のレプリカインスタンスを動作させている場合は、すべてのレプリカインスタンスで
ghe-repl-stop
を実行してレプリケーションを停止させます。 -
「アップグレードパッケージで単一アプライアンスをアップグレードする」の指示に従い、プライマリインスタンスをアップグレードしてください。
レプリカインスタンスのアップグレード
メモ: Geo-replication の一部として複数のレプリカインスタンスを動作させているなら、この手順は各レプリカインスタンス 1 つずつに繰り返してください。
-
「アップグレードパッケージで単一のアプライアンスをアップグレードする」の指示に従ってレプリカインスタンスをアップグレードしてください。Geo-replication 用に複数のレプリカを利用しているなら、この手順を各レプリカ 1 つずつに繰り返さなければなりません。
-
Connect to the replica instance over SSH as the "admin" user on port 122:
$ ssh -p 122 admin@replica-host
-
Verify the upgrade by running:
$ ghe-version
-
On the replica instance, to start replication, run
ghe-repl-start
. -
On the replica instance, to make sure replication services are running correctly, run
ghe-repl-status
. This command will returnOK
for all services when a successful replication is in progress and the replica has upgraded. コマンドがReplication is not running
を返すなら、レプリケーションはまだ開始中かもしれません。ghe-repl-status
をもう一度実行する前に 1 分間ほど待ってください。メモ: resync の処理が進んでいる間は、
ghe-repl-status
はレプリケーションが遅れていることを示す期待どおりのメッセージを返すかもしれません。 たとえばCRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists
のようなメッセージです。ghe-repl-status
がOK
を返さない場合は、以下の手順に従って手動でレプリケーションを開始してください。-
レプリカインスタンスで再度
ghe-repl-setup <primary-instance-ip>
を実行してください。 -
On the replica instance, to start replication, run
ghe-repl-start
. -
On the replica instance, to make sure replication services are running correctly, run
ghe-repl-status
. This command will returnOK
for all services when a successful replication is in progress and the replica has upgraded.
-
-
最後のレプリカのアップグレードが完了し、resync も完了したなら、ユーザが GitHub Enterprise Server インスタンス を使えるようにメンテナンスモードを無効化してください。
失敗したアップグレードからのリストア
アップグレードが失敗もしくは中断したなら、インスタンスを以前の状態に復帰させなければなりません。 この処理を完了させるプロセスは、アップグレードの種類によります。
パッチリリースのロールバック
パッチリリースをロールバックするには ghe-upgrade --allow-patch-rollback
コマンドを使ってください。パッチリリースでは移行の処理は実行されないので、ロールバックによってデータパーティションが影響を受けることはありません。 詳細は「コマンドラインユーティリティ」を参照してください。
フィーチャリリースのロールバック
フィーチャリリースからロールバックするには、ルートおよびデータパーティションが整合した状態になることを保証するため、VM スナップショットからリストアしてください。 詳細は「スナップショットを取得する」を参照してください。