アップグレードの要求事項

GitHub Enterprise Server クラスタリングを使用している場合は、クラスタリングに固有の具体的な手順については、 クラスタリング ガイドの GitHub Enterprise Server を参照してください。

* GitHub Enterprise Serverのリリース ノートには、GitHub Enterprise Serverのすべてのバージョンの新機能の包括的な一覧が記載されています。 詳細については、リリース ページを参照してください。

推奨事項

• アップグレードのプロセスに含めるアップグレードは、できるだけ少なくしてください。 たとえば、 GitHub Enterprise3.19 から 3.20 から 3.21 にアップグレードする代わりに、 GitHub Enterprise3.19 から 3.21 にアップグレードできます。 アップグレードアシスタント を使用して、現在のリリース バージョンからのアップグレード パスを見つけます。
• 複数のバージョンが遅れている場合は、アップグレード プロセスの各手順でできるだけ早く お使いの GitHub Enterprise Server インスタンス アップグレードしてください。 各アップグレードで可能な限りの最新バージョンを使うことで、パフォーマンスの改善やバグフィックスのメリットが得られます。 たとえば、 GitHub Enterprise 2.7 から 2.8 から 2.10 にアップグレードできますが、 GitHub Enterprise 2.7 から 2.9 から 2.10 にアップグレードすると、2 番目の手順で新しいバージョンが使用されます。
• アップグレードの際には、最新のパッチリリースを使ってください。 GitHub Enterprise Server リリース ページを参照します。 アップグレード先対象リリースの横にある [ダウンロード] をクリックし、 [アップグレード] タブをクリックします。
• アップグレードのステップのテストには、ステージングインスタンスを使ってください。 詳しくは、「ステージングインスタンスのセットアップ」をご覧ください。
• 複数のアップグレードを実行するときは、次の機能アップグレードに進む前に、バックグラウンドで実行されているデータ移行とアップグレード タスクが完全に完了していることを確認します。 これらのプロセスの状態をチェックするには、ghe-migrations と ghe-check-background-upgrade-jobs のコマンド ライン ユーティリティを使用します。 詳しくは、「コマンド ライン ユーティリティ」をご覧ください。
• 仮想マシンをアップグレードする前にスナップショットを作成します。 詳しくは、「スナップショットの取得」をご覧ください。 スナップショットを撮ったら、アップグレード中のパフォーマンスへの影響を避けるために、自動スナップショットをオフにします。
• インスタンスの最新の正常なバックアップがあることを確認します。 詳細については、 GitHub Enterprise Server Backup Utilities README.md ファイルを参照してください。

要件

• 容量チェックを実行する必要があります。 詳しくは、「アップグレードする前にシステムの容量を確認する」をご覧ください。
• アップグレードは、最大でも 2 リリース前の機能リリースから行わなければなりません。 たとえば、 GitHub Enterprise3.21にアップグレードするには、 GitHub Enterprise3.20 または 3.19している必要があります。
• アップグレード パッケージを使用してアップグレードする場合は、エンド ユーザー GitHub Enterprise Server メンテナンス期間をスケジュールします。
• ホットパッチを使用して、 GitHub Enterprise Server を最新のパッチ リリースにアップグレードできます。

ホットパッチは新しいパッチリリースへのアップグレードに利用できますが、新しいフィーチャリリースへのアップグレードには利用できません。 たとえば、2.10.1 から 2.10.5 は同じ機能シリーズに含まれているためアップグレードできますが、2.10.9 から 2.11.0 は異なる機能シリーズに含まれているためアップグレードできません。

ホットパッチでは常に再起動が必要とは限りません。 ホットパッチをインストールすると、更新プログラムを完了するためにいずれかのパッケージで再起動が必要な場合に、ターミナルにメッセージが表示されます。 この再起動は便利なタイミングでスケジュールできますが、特にセキュリティ修正プログラムがある場合は、できるだけ早く再起動することをお勧めします。

ホットパッチには構成の適用が必要であり、その結果、お使いの GitHub Enterprise Server インスタンス 上の一部またはすべてのサービスで、短時間エラーが発生したり応答しなくなったりする場合があります。 ホットパッチのインストール中はメンテナンス モードを有効にする必要はありませんが、有効にすると、エラーまたはタイムアウトではなくメンテナンス ページがユーザーに表示されます。 「メンテナンスモードの有効化とスケジューリング」をご覧ください。

• ホットパッチは、影響するサービス（カーネル、MySQL、Elasticsearchなど）がVMの再起動やサービスの再起動を必要とするなら、ダウンタイムが必要になります。 リブートや再起動が必要になったときには通知されます。 リブートや再起動は後で完了させることができます。
• ホットパッチでアップグレードをする場合、アップグレードの完了までに特定のサービスの複数バージョンがインストールされることから、追加のルートストレージが利用できなければなりません。 十分なルートディスクストレージがなければ、プレフライトチェックで通知されます。
• ホットパッチでアップグレードする場合、インスタンスの負荷は高すぎてはなりません。もし負荷が高すぎると、ホットパッチのプロセスに影響するかもしれません。
• GitHub Enterprise Server 2.17 にアップグレードすると、監査ログが Elasticsearch から MySQL に移行されます。 この移行により、スナップショットの復元に必要な時間とディスク容量も増加します。 移行の前に、次のコマンドでElasticsearch監査ログのインデックスでバイト数を確認してください。

curl -s http://localhost:9201/audit_log/_stats/store | jq ._all.primaries.store.size_in_bytes

MySQLの監査ログで必要なディスク容量の概算には、この数字を使用します。 スクリプトは、インポートの進行中に空きディスク容量も監視します。 この数字を監視しておくと、空きディスク容量が、移行に必要なディスク容量に近い場合に特に便利です。

アップグレード時に、メモリ、CPU コア、ユーザーとルート ディスク ストレージなどのシステム ハードウェア リソースの最小要件がインスタンスで使用できるかどうかを事前チェックで評価します。 事前チェックでリソース不足やその他の失敗があると判断された場合は、通知が送信され、アップグレードが中止されます。

次のステップ

これらの推奨事項と要件を確認したら、 GitHub Enterprise Serverアップグレードできます。 詳しくは、「アップグレード プロセスの概要」をご覧ください。