GitHub Enterprise Server をアップグレードする

アップグレードの準備

1. アップグレードの戦略を決定し、アップグレード先のバージョンを選択してください。 詳細は「アップグレードの要求事項」を参照してください。

2. GitHub Enterprise Serverバックアップユーティリティ で、プライマリインスタンスの新しいバックアップを作成してください。 詳しい情報については、GitHub Enterprise ServerバックアップユーティリティREADME.md ファイルを参照してください。

3. アップグレードパッケージを使ってアップグレードをする場合は、GitHub Enterprise Server のエンドユーザのためにメンテナンス時間枠をスケジューリングしてください。 ホットパッチを利用している場合、メンテナンスモードは必要ありません。

   注釈: メンテナンスウィンドウは、実行しようとしているアップグレードの種類によります。 ホットパッチを利用するアップグレードは、通常メンテナンスウィンドウを必要としません。 リブートが必要になることもあります。そのリブートは後で行うことができます。 MAJOR.FEATURE.PATCH というバージョン付けのスキームに従い、アップグレードパッケージを使ったパッチのリリースで生じるダウンタイムは、通常 5 分未満です。 データの移行を含むフィーチャリリースは、ストレージの性能および移行するデータの量に応じた時間がかかります。 詳しい情報については"メンテナンスモードの有効化とスケジューリング"を参照してください。

スナップショットの取得

スナップショットは、ある時点での仮想マシン（VM）のチェックポイントです。 アップグレードに失敗した場合にスナップショットからVMを回復できるよう、仮想マシンをアップグレードする前にスナップショットを取っておくことを強くおすすめします。 新しいフィーチャリリースにアップグレードするなら、VM のスナップショットを取らなければなりません。 パッチリリースへのアップグレードをするなら、既存のデータディスクをアタッチできます。

スナップショットには2種類あります。

• VM スナップショットは、ユーザデータおよび設定データを含む VM の状態全体を保存します。 このスナップショットの手法には大量のディスク領域が必要になり、時間がかかります。

• データディスクスナップショットはユーザデータだけを保存します。

  ノート:

  • プラットフォームによっては、ユーザのデータディスクだけのスナップショットを取ることができません。 それらのプラットフォームでは、VM 全体のスナップショットを取る必要があります。
  • ハイパーバイザーが完全なVMスナップショットをサポートしていないなら、ルートディスクとデータディスクのスナップショットを時間をおかずに取らなければなりません。

ホットパッチでのアップグレード

GitHub Enterprise Serverは、ホットパッチを利用して最新のパッチリリースへアップグレードできます。ホットパッチにはメンテナンスウィンドウが不要で、通常は再起動も必要ありません。 ホットパッチは新しいパッチリリースへのアップグレードに利用できますが、新しいフィーチャリリースへのアップグレードには利用できません。 たとえば2.10.1から2.10.5へのアップグレードは同じフィーチャリリースなので可能ですが、2.10.9から2.11.0へは異なるフィーチャリリースなので行えません。Management Console を使うと、ホットパッチを即座にインストールすることや、後にインストールするようにスケジュールすることができます。 管理シェルを使って ghe-upgrade ユーティリティでホットパッチをインストールすることもできます。 詳細は「アップグレードの要求事項」を参照してください。

ホットパッチでの単一のアプライアンスのアップグレード

Management Console を使ってホットパッチをインストールする

1. 自動アップデートを有効化してください。 詳しい情報については「自動アップデートの有効化」を参照してください。
2. GitHub Enterprise Serverの管理アカウントから、任意のページの右上にあるをクリックしてください。
3. 左のサイドバーでManagement Consoleをクリックしてください。
4. Management Consoleの上部でUpdates（アップデート）をクリックしてください。
5. 新しいホットパッチがダウンロードされたなら、Install package（パッケージのインストール）ドロップダウンメニューを使ってください。
   • すぐにインストールするならNow（即時）を選択してください。
   • 後でインストールするなら、後の日付を選択してください。
6. [Install] をクリックします。

管理シェルを使ったホットパッチのインストール

1. your GitHub Enterprise Server instanceにSSHでアクセスしてください。 詳しい情報については「管理シェル（SSH）にアクセスする」を参照してください。

   $ ssh -p 122 admin@HOSTNAME

2. GitHub Enterprise Serverのリリースページにアクセスしてください。 アップグレードしたいリリースの隣の Download（ダウンロード）をクリックし、続いて Upgrading（アップグレード）タブをクリックしてください。アップグレードのホットパッケージ（.hpkgファイル）のURLをコピーしてください。
3. cURLを使ってyour GitHub Enterprise Server instanceにアップグレードパッケージをダウンロードしてください。

   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 やその他のプログラムのアップグレードにリブートが必要なら、ホットパッチアップグレードスクリプトが通知してくれます。

ホットパッチを使ったレプリカインスタンスを持つアプライアンスのアップグレード

High Availability と Geo-replication が設定されたアプライアンスは、プライマリインスタンスに加えてレプリカインスタンスを使います。 これらのアプライアンスをアップグレードするには、プライマリインスタンスとすべてのレプリカインスタンスの両方を、1 つずつアップグレードしなければなりません。

プライマリインスタンスのアップグレード

1. 「管理シェルを使ってホットパッチをインストールする」の指示に従ってプライマリインスタンスをアップグレードしてください。

レプリカインスタンスのアップグレード

1. 「管理シェルを使ってホットパッチをインストールする」の指示に従ってレプリカインスタンスをアップグレードします。 Geo-replication に複数のレプリカを使用している場合は、この手順を繰り返して、各レプリカを一度に 1 つずつアップグレードする必要があります。

2. ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してください。

   $ ssh -p 122 admin@replica-host

3. 以下を実行して、アップグレードを検証してください。

   $ ghe-version

アップグレードパッケージでのアップグレード

フィーチャシリーズ内の最新のパッチリリースへのアップグレードにはホットパッチが利用できますが、新しいフィーチャリリースへのアップグレードにはアップグレードパッケージを使わなければなりません。 たとえば 2.11.10 から 2.12.4 へのアップグレードの場合、これらは異なるフィーチャシリーズなので、アップグレードパッケージを使わなければなりません。 詳細は「アップグレードの要求事項」を参照してください。

アップグレードパッケージでの単一のアプライアンスのアップグレード

1. your GitHub Enterprise Server instanceにSSHでアクセスしてください。 詳しい情報については「管理シェル（SSH）にアクセスする」を参照してください。

   $ ssh -p 122 admin@HOSTNAME

2. GitHub Enterprise Serverのリリースページにアクセスしてください。 アップグレードしたいリリースの隣の Download（ダウンロード）をクリックし、続いて Upgrading（アップグレード）タブをクリックしてください。 適切なプラットフォームを選択し、アップグレードパッケージ (.pkgファイル) の URL をコピーしてください。

3. cURLを使ってyour GitHub Enterprise Server instanceにアップグレードパッケージをダウンロードしてください。

   admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL

4. メンテナンスモードを有効にし、GitHub Enterprise Server インスタンス上のすべてのアクティブなプロセスが完了するのを待ってください。 詳しい情報については"メンテナンスモードの有効化とスケジューリング"を参照してください。

   メモ: High Availability 構成のプライマリアプライアンスをアップグレードする場合には、「プライマリインスタンスをアップグレードする」の指示に従っているならアプライアンスはメンテナンスモードになっているはずです。

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. 単一アプライアンスのアップグレードであれば、メンテナンスモードを無効化してユーザが your GitHub Enterprise Server instance を利用できるようにしてください。

   メモ: High Availability 設定のアプライアンスをアップグレードする場合、すべてのレプリカをアップグレードし、レプリケーションが最新の状態になるまではメンテナンスモードのままでなければなりません。 詳細は「レプリカインスタンスをアップグレードする」を参照してください。

アップグレードパッケージを使ったレプリカインスタンスを持つアプライアンスのアップグレード

High Availability と Geo-replication が設定されたアプライアンスは、プライマリインスタンスに加えてレプリカインスタンスを使います。 これらのアプライアンスをアップグレードするには、プライマリインスタンスとすべてのレプリカインスタンスの両方を、1 つずつアップグレードしなければなりません。

プライマリインスタンスのアップグレード

1. プライマリインスタンスでメンテナンスモードを有効化し、すべてのアクティブなプロセスが完了するのを待ちます。 詳しい情報については、「メンテナンスモードの有効化」を参照してください。
2. ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してください。

   $ ssh -p 122 admin@replica-host

3. レプリカインスタンス、あるいは Geo-replication の一部として複数のレプリカインスタンスを動作させている場合は、すべてのレプリカインスタンスで ghe-repl-stop を実行してレプリケーションを停止させます。
4. 「アップグレードパッケージで単一アプライアンスをアップグレードする」の指示に従い、プライマリインスタンスをアップグレードしてください。

レプリカインスタンスのアップグレード

1. 「アップグレードパッケージで単一アプライアンスをアップグレードする」の指示に従い、レプリカインスタンスをアップグレードします。 Geo-replication に複数のレプリカを使用している場合は、この手順を繰り返して、各レプリカを一度に 1 つずつアップグレードする必要があります。

2. ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してください。

   $ ssh -p 122 admin@replica-host

3. 以下を実行して、アップグレードを検証してください。

   $ ghe-version

4. レプリカインスタンス上でレプリケーションを開始するには、ghe-repl-startを実行してください。

5. レプリカインスタンスで、レプリケーションサービスが正しく動作していることを確認するには、ghe-repl-statusを実行してください。 このコマンドは、レプリケーションが問題なく進行しており、レプリカがアップグレードされていれば、すべてのサービスに対してOKを返します。 コマンドが 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 のようなメッセージです。

   If ghe-repl-status did not return OK, contact GitHub Enterprise Support. 詳しい情報については、「GitHub Support からの支援を受ける」を参照してください。

6. 最後のレプリカのアップグレードが完了し、resync も完了したなら、ユーザが your GitHub Enterprise Server instance を使えるようにメンテナンスモードを無効化してください。

失敗したアップグレードからのリストア

アップグレードが失敗もしくは中断したなら、インスタンスを以前の状態に復帰させなければなりません。 この処理を完了させるプロセスは、アップグレードの種類によります。

パッチリリースのロールバック

パッチリリースをロールバックするには、--allow-patch-rollback を付けて ghe-upgrade コマンドを使います。 アップグレードをロールバックする場合には、.pkg拡張子を持つアップグレードパッケージを使わなければなりません。 .hpkg拡張子を持つホットパッチのパッケージファイルはサポートされません。

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

このコマンドの実行後には再起動が必要です。 パッチリリースでは移行は行われないので、ロールバックはデータパーティションには影響しません。

詳細は「コマンドラインユーティリティ」を参照してください。

フィーチャリリースのロールバック

フィーチャリリースからロールバックするには、ルートおよびデータパーティションが整合した状態になることを保証するため、VM スナップショットからリストアしてください。 詳細は「スナップショットを取得する」を参照してください。

参考リンク

• 「新しいリリースへのアップグレードについて」