ノート:
- GitHub Enterprise 11.10.348 から 11.10.354 までからアップグレードするためには、まず GitHub Enterprise 2.1.23 に移行しなければなりません。 詳細は「GitHub Enterprise 11.10.x から 2.1.23 へ移行する」を参照してください。
- サポートされているバージョンについては、アップグレードパッケージが enterprise.github.com から利用できます。 アップグレードを完了するには、必要なアップグレードパッケージが利用できることを確認してください。 パッケージが利用できない場合はGitHub Enterprise Support または GitHub Premium Supportに連絡して支援を求めてください。
- GitHub Enterprise Server クラスタリングを利用している場合は、クラスタリングに固有の手順については GitHub Enterprise Server クラスタリングガイド中の「クラスタをアップグレードする」を参照してください。
- GitHub Enterprise Server のリリースノートには、GitHub Enterprise Server のすべてのバージョンの新機能の包括的なリストがあります。 詳しい情報についてはリリースページを参照してください。
推奨される対応
- アップグレードのプロセスに含めるアップグレードは、できるだけ少なくしてください。 たとえば GitHub Enterprise 2.22 から 3.0 を経て 3.1 にアップグレードする代わりに、GitHub Enterprise 2.22 から 3.1 にアップグレードできます。
- バージョンが数バージョン古いのであれば、GitHub Enterprise Serverのインスタンスをアップグレードのプロセスの各ステップでできる限り先までアップグレードしてください。 各アップグレードで可能な限りの最新バージョンを使うことで、パフォーマンスの改善やバグフィックスのメリットが得られます。 たとえばGitHub Enterprise2.7から2.8を経て2.10へアップグレードすることができますが、GitHub Enterprise2.7から2.9を経て2.10へのアップグレードすれば、2番目のステップでより新しいバージョンを利用できます。
- アップグレードの際には、最新のパッチリリースを使ってください。 GitHub Enterprise Serverのリリースページにアクセスしてください。 アップグレードしたいリリースの隣の Download（ダウンロード）をクリックし、続いて Upgrading（アップグレード）タブをクリックしてください。
- アップグレードのステップのテストには、ステージングインスタンスを使ってください。 詳しい情報については "ステージングインスタンスのセットアップ"を参照してください。
- 複数のアップグレードを実行する場合は、機能のアップグレードの間に少なくとも 24 時間待って、データ移行とバックグラウンドで実行されているアップグレードタスクが完全に完了するようにします。
要件
- アップグレードは、最大でも2リリース前のフィーチャリリースから行わなければなりません。 たとえば GitHub Enterprise 3.1 にアップグレードするためには、GitHub Enterprise 3.0 あるいは 2.22 となっていなければなりません。
- GitHub Enterprise Serverは、ホットパッチを利用して最新のパッチリリースへアップグレードできます。ホットパッチにはメンテナンスウィンドウが不要で、通常は再起動も必要ありません。 ホットパッチは新しいパッチリリースへのアップグレードに利用できますが、新しいフィーチャリリースへのアップグレードには利用できません。 たとえば
2.10.1から2.10.5へのアップグレードは同じフィーチャリリースなので可能ですが、2.10.9から2.11.0へは異なるフィーチャリリースなので行えません。 - ホットパッチは、影響するサービス（カーネル、MySQL、Elasticsearchなど）がVMの再起動やサービスの再起動を必要とするなら、ダウンタイムが必要になります。 リブートや再起動が必要になったときには通知されます。 リブートや再起動は後で完了させることができます。
- ホットパッチでアップグレードをする場合、アップグレードの完了までに特定のサービスの複数バージョンがインストールされることから、追加のルートストレージが利用できなければなりません。 十分なルートディスクストレージがなければ、事前チェックで通知されます。
- ホットパッチでアップグレードする場合、インスタンスの負荷は高すぎてはなりません。もし負荷が高すぎると、ホットパッチのプロセスに影響するかもしれません。 事前チェックはロードアベレージを考慮し、ロードアベレージが高すぎればアップグレードは失敗します。- GitHub Enterprise Server 2.17へのアップグレードによって、Audit logがElasticsearchからMySQLへ移行されます。 この移行により、スナップショットの復元に必要な時間とディスク容量も増加します。 移行の前に、次のコマンドでElasticsearch監査ログのインデックスでバイト数を確認してください。
MySQLの監査ログで必要なディスク容量の概算には、この数字を使用します。 スクリプトは、インポートの進行中に空きディスク容量も監視します。 この数字を監視しておくと、空きディスク容量が、移行に必要なディスク容量に近い場合に特に便利です。curl -s http://localhost:9201/audit_log/_stats/store | jq ._all.primaries.store.size_in_bytes
GitHub Enterprise Server 3.0 以降の最小要件について
GitHub Enterprise Server 3.0 以降にアップグレードする前に、インスタンスにプロビジョニングしたハードウェアリソースを確認してください。 GitHub Enterprise Server 3.0 は、GitHub Actions や GitHub Packages などの新機能を導入しているため、バージョン 2.22 以前よりも多くのリソースが必要となります。 詳しい情報については、GitHub Enterprise Server 3.0 のリリースノートを参照してください。
次の表では、GitHub Enterprise Server 3.0 以降の要件の増加を太字で示しています。
| ユーザライセンス | vCPUs | メモリ | アタッチされたストレージ | ルートストレージ |
|---|---|---|---|---|
| トライアル、デモ、あるいは10人の軽量ユーザ | 4 2 から増加 | 32 GB 16 GB から増加 | 150 GB 100 GB から増加 | 200 GB |
| 10-3000 | 8 4 から増加 | 48 GB 32 GB から増加 | 300 GB 250 GB から増加 | 200 GB |
| 3000-5000 | 12 8 から増加 | 64 GB | 500 GB | 200 GB |
| 5000-8000 | 16 12 から増加 | 96 GB | 750 GB | 200 GB |
| 8000-10000+ | 20 16 から増加 | 160 GB 128 GB から増加 | 1000 GB | 200 GB |
既存のインスタンスのリソース調整に関する詳しい情報については「ストレージ容量の増加」及び「CPUあるいはメモリリソースの増加」を参照してください。
次のステップ
これらの推奨および要求事項をレビューした後で、GitHub Enterprise Server をアップグレードできます。 詳細は「GitHub Enterprise Server をアップグレードする」を参照してください。