Note: Features such as GitHub Actions, GitHub Packages, GitHub Mobile and GitHub Advanced Security are available on GitHub Enterprise Server 3.0 or higher. We highly recommend upgrading to 3.0 or later releases to take advantage of critical security updates, bug fixes and feature enhancements.
アップグレードの準備
-
アップグレードの戦略を決定し、アップグレード先のバージョンを選択してく� さい。 For more information, see "Upgrade requirements" and refer to the Upgrade assistant to find the upgrade path from your current release version.
-
GitHub Enterprise Serverバックアップユーティリティ で、プライマリインスタンスの新しいバックアップを作成してく� さい。 詳しい情� �については、GitHub Enterprise ServerバックアップユーティリティREADME.md ファイルを参照してく� さい。
-
If GitHub Enterprise Serverインスタンス uses ephemeral self-hosted runners for GitHub Actions and you've disabled automatic updates, upgrade your runners to the version of the runner application that your upgraded instance will run.
-
アップグレードパッケージを使ってアップグレードをする� �合は、GitHub Enterprise Server のエンドユーザのためにメンテナンス時間� をスケジューリングしてく� さい。 ホットパッチを利用しているなら、メンテナンスモードは必要ありません。
注釈: メンテナンスウィンドウは、実行しようとしているアップグレードの種類によります。 ホットパッチを利用するアップグレードは、通常メンテナンスウィンドウを必要としません。 リブートが必要になることもあります。そのリブートは後で行うことができます。 MAJOR.FEATURE.PATCH というバージョン付けのスキー� に従ったパッチリリースをアップグレードパッケージを行うには、通常 5 分未満のダウンタイ� � けが必要です。 データの移行を含むフィーチャリリースは、ストレージのパフォーマンス及び移行するデータの量に応じて時間が長くかかります。 詳しい情� �については"メンテナンスモードの有効化とスケジューリング"を参照してく� さい。
About minimum requirements for GitHub Enterprise Server 3.0 and later
Before upgrading to GitHub Enterprise Server 3.0 or later, review the hardware resources you've provisioned for your instance. GitHub Enterprise Server 3.0 introduces new features such as GitHub Actions and GitHub Packages, and requires more resources than versions 2.22 and earlier. For more information, see the GitHub Enterprise Server 3.0 release notes.
Increased requirements for GitHub Enterprise Server 3.0 and later are bold in the following table.
User licenses | vCPUs | Memory | Attached storage | Root storage |
---|---|---|---|---|
Trial, demo, or 10 light users | 4 Up from 2 | 32 GB Up from 16 GB | 150 GB Up from 100 GB | 200 GB |
10 to 3,000 | 8 Up from 4 | 48 GB Up from 32 GB | 300 GB Up from 250 GB | 200 GB |
3,000 to 5000 | 12 Up from 8 | 64 GB | 500 GB | 200 GB |
5,000 to 8000 | 16 Up from 12 | 96 GB | 750 GB | 200 GB |
8,000 to 10,000+ | 20 Up from 16 | 160 GB Up from 128 GB | 1000 GB | 200 GB |
For more information about hardware requirements for GitHub Actions, see "Getting started with GitHub Actions for GitHub Enterprise Server."
既存のインスタンスのリソース調整に関する詳しい情� �については「ストレージ容量の増� 」及び「CPUあるいはメモリリソースの増� 」を参照してく� さい。
スナップショットの取得
スナップショットは、ある時点での仮想マシン(VM)のチェックポイントです。 アップグレードに失敗した� �合にスナップショットからVMを回復できるよう、仮想マシンをアップグレードする前にスナップショットを取っておくことを強くおすすめします。 We only recommend taking a VM snapshot when the appliance is powered down or in maintenance mode and all background jobs have finished.
新しいフィーチャリリースにアップグレードするなら、VM のスナップショットを取らなければなりません。 パッチリリースへのアップグレードをするなら、既存のデータディスクをアタッチできます。
スナップショットには2種類あります。
-
VM スナップショットは、ユーザデータおよび設定データを含む VM の状態全体を保存します。 このスナップショットの手法には大量のディスク� �域が必要になり、時間がかかります。
-
データディスクスナップショットはユーザデータ� けを保存します。
ノート:
- プラットフォー� によっては、ユーザのデータディスク� けのスナップショットを取ることができません。 それらのプラットフォー� では、VM 全体のスナップショットを取る必要があります。
- ハイパーバイザーが完全なVMスナップショットをサポートしていないなら、ルートディスクとデータディスクのスナップショットを時間をおかずに取らなければなりません。
ホットパッチでのアップグレード
GitHub Enterprise Serverは、ホットパッチを利用して最新のパッチリリースへアップグレードできます。ホットパッチにはメンテナンスウィンドウが不要で、通常は再起動も必要ありません。
ホットパッチは新しいパッチリリースへのアップグレードに利用できますが、新しいフィーチャリリースへのアップグレードには利用できません。 たとえば2.10.1
から2.10.5
へのアップグレードは同じフィーチャリリースなので可能ですが、2.10.9
から2.11.0
へは異なるフィーチャリリースなので行えません。
Using the Management Console, you can install a hotpatch immediately or schedule it for later installation. 管理シェルを使って ghe-upgrade
ユーティリティでホットパッチをインストールすることもできます。 詳細は「アップグレードの要求事� �」を参照してく� さい。
注釈:
-
GitHub Enterprise Serverインスタンス がリリース候補ビルドを実行している� �合、ホットパッチでアップグレードすることはできません。
-
クラスタ環境では、Management Console を使ったホットパッチのインストールはできません。 クラスタ環境でホットパッチをインストールするには、「クラスタをアップグレードする」を参照してく� さい。
ホットパッチでの単一のアプライアンスのアップグレード
Management Console を使ってホットパッチをインストールする
You can use the Management Console to upgrade with a hotpatch by enabling automatic updates. You will then be presented with the latest available version of GitHub Enterprise Server that you can upgrade to.
If the upgrade target you're presented with is a feature release instead of a patch release, you cannot use the Management Console to install a hotpatch. You must install the hotpatch using the administrative shell instead. For more information, see "Installing a hotpatch using the administrative shell."
-
自動アップデートを有効化してく� さい。 詳しい情� �については「自動アップデートの有効化」を参照してく� さい。
-
From an administrative account on GitHub Enterprise Server, in the upper-right corner of any page, click .
-
If you're not already on the "Site admin" page, in the upper-left corner, click Site admin.
-
左のサイドバーでManagement Consoleをクリックしてく� さい。
-
Management Consoleの上部でUpdates(アップデート)をクリックしてく� さい。
-
新しいホットパッチがダウンロードされたなら、Install package(パッケージのインストール)ドロップダウンメニューを使ってく� さい。
- すぐにインストールするならNow(即時)を選択してく� さい。
- 後でインストールするなら、後の日付を選択してく� さい。
-
[Install] をクリックします。
管理シェルを使ったホットパッチのインストール
ノート: 自動アップデートチェックを有効にしたなら、アップグレードパッケージをダウンロードする必要はなく、自動的にダウンロードされたファイルを利用できます。 詳しい情� �については「自動アップデートチェックの有効化」を参照してく� さい。
- GitHub Enterprise ServerインスタンスにSSHでアクセスしてく� さい。 詳しい情� �については「管理シェル(SSH)にアクセスする」を参照してく� さい。
$ ssh -p 122 admin@HOSTNAME
- GitHub Enterprise Serverのリリースページにアクセスしてく� さい。 アップグレードしたいリリースの隣の Download(ダウンロード)をクリックし、続いて Upgrading(アップグレード)タブをクリックしてく� さい。アップグレードのホットパッケージ(.hpkgファイル)のURLをコピーしてく� さい。
cURL
を使ってGitHub Enterprise Serverインスタンスにアップグレードパッケージをダウンロードしてく� さい。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 つずつアップグレードする必要があります。
-
ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してく� さい。
$ ssh -p 122 admin@replica-host
-
以下を実行して、アップグレードを検証してく� さい。
$ ghe-version
アップグレードパッケージでのアップグレード
フィーチャシリーズ内の最新のパッチリリースへのアップグレードにはホットパッチが利用できますが、新しいフィーチャリリースへのアップグレードにはアップグレードパッケージを使わなければなりません。 たとえば 2.11.10
から 2.12.4
へのアップグレードの� �合、これらは異なるフィーチャシリーズなので、アップグレードパッケージを使わなければなりません。 詳細は「アップグレードの要求事� �」を参照してく� さい。
アップグレードパッケージでの単一のアプライアンスのアップグレード
ノート: 自動アップデートチェックを有効にしたなら、アップグレードパッケージをダウンロードする必要はなく、自動的にダウンロードされたファイルを利用できます。 詳しい情� �については「自動アップデートチェックの有効化」を参照してく� さい。
-
GitHub Enterprise ServerインスタンスにSSHでアクセスしてく� さい。 詳しい情� �については「管理シェル(SSH)にアクセスする」を参照してく� さい。
$ ssh -p 122 admin@HOSTNAME
-
GitHub Enterprise Serverのリリースページにアクセスしてく� さい。 アップグレードしたいリリースの隣の Download(ダウンロード)をクリックし、続いて Upgrading(アップグレード)タブをクリックしてく� さい。 適切なプラットフォー� を選択し、アップグレードパッケージ (.pkgファイル) の URL をコピーしてく� さい。
-
cURL
を使ってGitHub Enterprise Serverインスタンスにアップグレードパッケージをダウンロードしてく� さい。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-number Current 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 つずつアップグレードしなければなりません。
プライマリインスタンスのアップグレード
警告: レプリケーションが停止されると、プライマリに障害があった� �合には、レプリカがアップグレードされてレプリケーションが再開されるまでに行われた作業は失われます。
- プライマリインスタンスでメンテナンスモードを有効化し、すべてのアクティブなプロセスが完了するのを待ちます。 詳しい情� �については、「メンテナンスモードの有効化」を参照してく� さい。
- ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してく� さい。
$ ssh -p 122 admin@replica-host
- レプリカインスタンス、あるいは Geo-replication の一部として複数のレプリカインスタンスを動作させている� �合は、すべてのレプリカインスタンスで
ghe-repl-stop
を実行してレプリケーションを停止させます。 - 「アップグレードパッケージで単一アプライアンスをアップグレードする」の指示に従い、プライマリインスタンスをアップグレードしてく� さい。
レプリカインスタンスのアップグレード
メモ: Geo-replication の一部として複数のレプリカインスタンスを動作させているなら、この手� �は各レプリカインスタンス 1 つずつに繰り返してく� さい。
-
「アップグレードパッケージで単一アプライアンスをアップグレードする」の指示に従い、レプリカインスタンスをアップグレードします。 Geo-replication に複数のレプリカを使用している� �合は、この手� �を繰り返して、各レプリカを一度に 1 つずつアップグレードする必要があります。
-
ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してく� さい。
$ ssh -p 122 admin@replica-host
-
以下を実行して、アップグレードを検証してく� さい。
$ ghe-version
-
レプリカインスタンス上でレプリケーションを開始するには、
ghe-repl-start
を実行してく� さい。 -
レプリカインスタンスで、レプリケーションサービスが正しく動作していることを確認するには、
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 returnOK
, contact GitHub Enterprise Support. 詳しい情� �については、「GitHub Support からの支援を受ける」を参照してく� さい。 -
最後のレプリカのアップグレードが完了し、resync も完了したなら、ユーザが GitHub Enterprise Serverインスタンス を使えるようにメンテナンスモードを無効化してく� さい。
失敗したアップグレードからのリストア
アップグレードが失敗もしくは中断したなら、インスタンスを以前の状態に復帰させなければなりません。 この処理を完了させるプロセスは、アップグレードの種類によります。
パッチリリースのロールバック
パッチリリースをロールバックするには、--allow-patch-rollback
を付けて ghe-upgrade
コマンドを使います。 Before rolling back, replication must be temporarily stopped by running ghe-repl-stop
on all replica instances. アップグレードをロールバックする� �合には、.pkg拡張子を持つアップグレードパッケージを使わなければなりません。 .hpkg拡張子を持つホットパッチのパッケージファイルはサポートされません。
ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg
このコマンドの実行後には再起動が必要です。 パッチリリースでは移行は行われないので、ロールバックはデータパーティションには影響しません。
Once the rollback is complete, restart replication by running ghe-repl-start
on all replicas.
詳細は「コマンドラインユーティリティ」を参照してく� さい。
フィーチャリリースのロールバック
フィーチャリリースからロールバックするには、ルートおよびデータパーティションが整合した状態になることを保証するため、VM スナップショットからリストアしてく� さい。 詳細は「スナップショットを取得する」を参照してく� さい。