アップグレードの準備
-
アップグレードの戦略を決定し、アップグレード先のバージョンを選択してく� さい。 詳細については、「アップグレード要件」を参照してく� さい。また、「アップグレード アシスタント」を参照し、現在のリリース バージョンからのアップグレード パスを確認してく� さい。
-
GitHub Enterprise Server Backup Utilitiesで、プライマリインスタンスの新しいバックアップを作成してく� さい。 詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの README.md ファイルを参照してく� さい。
注: GitHub Enterprise Server Backup Utilities バージョンは、your GitHub Enterprise Server instanceと同じバージョンであるか、最大で 2 つ前のバージョンである必要があります。 詳しくは、「GitHub Enterprise Server Backup Utilities のアップグレード」を参照してく� さい。
-
your GitHub Enterprise Server instanceが GitHub Actions にエフェメラル セルフホステッド ランナーを使っていて、自動更新を無効にしている� �合、アップグレードされたインスタンスが実行するランナー アプリケーションのバージョンにランナーをアップグレードしてく� さい。
-
アップグレードパッケージを使ってアップグレードをする� �合は、GitHub Enterprise Server のエンドユーザのためにメンテナンス時間� をスケジューリングしてく� さい。 ホットパッチを利用している� �合、メンテナンスモードは必要ありません。
注: メンテナンス期間は、実行するアップグレードの種類によって変わります。 ホットパッチを利用するアップグレードは、通常メンテナンスウィンドウを必要としません。 リブートが必要になることもあります。そのリブートは後で行うことができます。 MAJOR.FEATURE.PATCH というバージョン付けのスキー� に従い、アップグレードパッケージを使ったパッチのリリースで生じるダウンタイ� は、通常 5 分未満です。 データの移行を含むフィーチャリリースは、ストレージの性能および移行するデータの量に応じた時間がかかります。 詳細については、「メンテナンスモードの有効化とスケジューリング」を参照してく� さい。
スナップショットの取得
スナップショットは、ある時点での仮想マシン(VM)のチェックポイントです。 アップグレードに失敗した� �合にスナップショットから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
ユーティリティを使ってホットパッチをインストールすることもできます。 詳細については、「アップグレード要件」を参照してく� さい。
注 :
-
your GitHub Enterprise Server instanceによってリリース候補ビルドが実行されている� �合、ホットパッチを使ったアップグレードはできません。
-
クラスタ環境では、[Management Console] を使ったホットパッチのインストールはできません。 クラスター環境でホットパッチをインストールするには、「クラスターのアップグレード」を参照してく� さい。
ホットパッチでの単一のアプライアンスのアップグレード
[Management Console] を使ってホットパッチをインストールする
[Management Console] を使って自動更新を有効にすることで、ホットパッチを使ってアップグレードできます。 そうすると、アップグレード可能な GitHub Enterprise Server の最新バージョンが表示されます。
表示されたアップグレード ターゲットがパッチ リリースではなく、機能リリースであった� �合は、[Management Console] を使ってホットパッチをインストールすることはできません。 代わりに管理シェルを使ってホットパッチをインストールする必要があります。 詳細については、「管理シェルを使ったホットパッチのインストール」を参照してく� さい。
-
自動更新を有効にする。 詳細については、自動更新の有効化に関するページを参照してく� さい。
-
GitHub Enterprise Server の管理アカウントから、任意のページの右上隅の をクリックします。
-
[サイト管理者] ページにま� 表示されていない� �合は、左上隅の [サイト管理者] をクリックします。
1. 左側のサイドバーで、 [Management Console] をクリックします。 1. [Management Console] の上部にある [更新] をクリックします。
-
新しいホットパッチがダウンロードされたなら、Install package(パッケージのインストール)ドロップダウンメニューを使ってく� さい。
- すぐにインストールするには、 [Now](今すぐ) を選びます。
- 後でインストールするなら、後の日付を選択してく� さい。
-
[インストール] をクリックします。
管理シェルを使ったホットパッチのインストール
注: 自動更新チェックを有効にすると、アップグレード パッケージをダウンロードする必要はなく、自動的にダウンロードされたファイルを利用できます。 詳細については、「自動更新チェックの有効化」を参照してく� さい。
-
に SSH でアクセスします。 インスタンスが複数のノードで構成されている� �合は (高可用性や geo レプリケーションが構成されている� �合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する� �合は、任意のノードに SSH 接続できます。 SSH 接続について詳しくは、「管理シェル (SSH) にアクセスする」をご覧く� さい。
$ ssh -p 122 admin@HOSTNAME
-
GitHub Enterprise Server リリース ページを参照します。 アップグレード先対象リリースの横にある [ダウンロード] をクリックし、 [アップグレード] タブをクリックします。アップグレードのホットパッケージ ( .hpkg ファイル) の URL をコピーします。
-
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 レプリケーションの一部として複数のレプリカ インスタンスを実行している� �合は、各レプリカ インスタンスに対してこの手� �を 1 回ずつ繰り返します。
-
「管理シェルを使ったホットパッチのインストール」の手� �に従ってレプリカ インスタンスをアップグレードします。 Geo-replication に複数のレプリカを使用している� �合は、この手� �を繰り返して、各レプリカを一度に 1 つずつアップグレードする必要があります。
-
ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してく� さい。
1. 以下を実行して、アップグレードを検証してく� さい。$ ssh -p 122 admin@replica-host
$ ghe-version
アップグレードパッケージでのアップグレード
フィーチャシリーズ内の最新のパッチリリースへのアップグレードにはホットパッチが利用できますが、新しいフィーチャリリースへのアップグレードにはアップグレードパッケージを使わなければなりません。 たとえば 2.11.10
から 2.12.4
へのアップグレードの� �合、これらは異なるフィーチャ シリーズなので、アップグレード パッケージを使う必要があります。 詳細については、「アップグレード要件」を参照してく� さい。
アップグレードパッケージでの単一のアプライアンスのアップグレード
注: 自動更新チェックを有効にすると、アップグレード パッケージをダウンロードする必要はなく、自動的にダウンロードされたファイルを利用できます。 詳細については、「自動更新チェックの有効化」を参照してく� さい。
-
に SSH でアクセスします。 インスタンスが複数のノードで構成されている� �合は (高可用性や geo レプリケーションが構成されている� �合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する� �合は、任意のノードに SSH 接続できます。 SSH 接続について詳しくは、「管理シェル (SSH) にアクセスする」をご覧く� さい。
$ ssh -p 122 admin@HOSTNAME
-
GitHub Enterprise Server リリース ページを参照します。 アップグレード先対象リリースの横にある [ダウンロード] をクリックし、 [アップグレード] タブをクリックします。適切なプラットフォー� を選び、アップグレード パッケージ ( .pkg fファイル) の URL をコピーします。
-
curl
を使用して、アップグレード パッケージを にダウンロードします。admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
-
メンテナンスモードを有効にし、GitHub Enterprise Server インスタンス上のすべてのアクティブなプロセスが完了するのを待ってく� さい。 詳細については、「メンテナンスモードの有効化とスケジューリング」を参照してく� さい。
注: 「プライマリ インスタンスのアップグレード」の手� �に従っている� �合、高可用性構成のプライマリ アプライアンスをアップグレードするときにアプライアンスはメンテナンス モードになっているはずです。
-
このパッケージ ファイル名を使って
ghe-upgrade
コマンドを実行します。admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg *** verifying upgrade package signature...
-
アップグレードを続けてパッケージ署名検証後に再起動することを承諾します。 新しいルートファイルシステ� がセカンダリパーティションに書かれ、インスタンスは自動的にメンテナンスモードで再起動します。
*** 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]
-
単一アプライアンスのアップグレードの� �合は、メンテナンス モードを無効にして、ユーザーが your GitHub Enterprise Server instanceを使用できるようにします。
注: 高可用性構成のアプライアンスをアップグレードする� �合は、すべてのレプリカをアップグレードし、レプリケーションが最新の状態になるまでは、メンテナンス モードのままにしてく� さい。 詳細については、「レプリカ インスタンスのアップグレード」を参照してく� さい。
アップグレードパッケージを使ったレプリカインスタンスを持つアプライアンスのアップグレード
High Availability と Geo-replication が設定されたアプライアンスは、プライマリインスタンスに� えてレプリカインスタンスを使います。 これらのアプライアンスをアップグレードするには、プライマリインスタンスとすべてのレプリカインスタンスの両方を、1 つずつアップグレードしなければなりません。
プライマリインスタンスのアップグレード
警告: レプリケーションを停止したときにプライマリに障害が発生した� �合、レプリカをアップグレードしてレプリケーションを再開する前に行った作業内容は失われます。
- プライマリインスタンスでメンテナンスモードを有効化し、すべてのアクティブなプロセスが完了するのを待ちます。 詳細については、「メンテナンス モードの有効化」を参照してく� さい。
- ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してく� さい。
$ ssh -p 122 admin@replica-host
- そのレプリカ インスタンス上、またはすべてのレプリカ インスタンス上 (geo レプリケーション の一部として複数のレプリカ インスタンスを実行している� �合) で
ghe-repl-stop
を実行してレプリケーションを停止します。 - 「アップグレード パッケージを使った単一アプライアンスのアップグレード」の手� �に従って、プライマリ インスタンスをアップグレードします。
レプリカインスタンスのアップグレード
注: geo レプリケーションの一部として複数のレプリカ インスタンスを実行している� �合は、各レプリカ インスタンスに対してこの手� �を 1 回ずつ繰り返します。
-
「アップグレード パッケージを使った単一アプライアンスのアップグレード」の手� �に従って、レプリカ インスタンスをアップグレードします。 Geo-replication に複数のレプリカを使用している� �合は、この手� �を繰り返して、各レプリカを一度に 1 つずつアップグレードする必要があります。
-
ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してく� さい。
1. 以下を実行して、アップグレードを検証してく� さい。$ ssh -p 122 admin@replica-host
$ ghe-version
-
レプリカのインスタンス上で
ghe-repl-start
を実行してレプリケーションを開始します。 -
レプリカ インスタンスで、レプリケーション サービスが正しく動作していることを確認するには、
ghe-repl-status
を実行します。 このコマンドは、レプリケーションが問題なく進行しており、レプリカがアップグレードされていれば、すべてのサービスに対してOK
を返します。コマンドからReplication is not running
が返される� �合、レプリケーションはま� 起動中の可能性があります。 約 1 分待ってから、もう一度ghe-repl-status
を実行してく� さい。注: 再同期の進行中、
ghe-repl-status
は、レプリケーションが遅れていることを示す可能性があります。 たとえば、次のようなメッセージが表示されることがあります。CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists
ghe-repl-status
がOK
を返さなかった� �合は、GitHub Enterprise サポートにお問い合わせく� さい。 詳細については、「GitHub Support からのヘルプの受信」を参照してく� さい。
-
最後のレプリカのアップグレードが完了し、再同期が完了したら、メンテナンス モードを無効にして、ユーザーが your GitHub Enterprise Server instanceを使用できるようにします。
失敗したアップグレードからのリストア
アップグレードが失敗もしくは中断したなら、インスタンスを以前の状態に復帰させなければなりません。 この処理を完了させるプロセスは、アップグレードの種類によります。
パッチリリースのロールバック
パッチ リリースをロールバックするには、--allow-patch-rollback
スイッチを指定して ghe-upgrade
コマンドを使用します。 ロールバックする前に、すべてのレプリカ インスタンス上で ghe-repl-stop
を実行してレプリケーションを一時的に停止する必要があります。 アップグレードをロールバックする� �合は、拡張子が .pkg のアップグレード パッケージ ファイルを使用する必要があります。 拡張子が .hpkg のホットパッチ パッケージ ファイルはサポートされていません。
ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg
このコマンドの実行後には再起動が必要です。 パッチリリースでは移行は行われないので、ロールバックはデータパーティションには影響しません。
ロールバックが完了したら、すべてのレプリカ上で ghe-repl-start
を実行してレプリケーションを再起動します。
詳細については、「コマンド ライン ユーティリティ」を参照してく� さい。
フィーチャリリースのロールバック
フィーチャリリースからロールバックするには、ルートおよびデータパーティションが整合した状態になることを保証するため、VM スナップショットからリストアしてく� さい。 詳細については、「スナップショットの作成」を参照してく� さい。