Skip to main content
ドキュメントへの更新が� �繁に発行されており、このページの翻訳はま� 行われている� �合があります。最新情� �については、英語版のドキュメントをご覧く� さい。
� 

� 

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい。

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

この記事では、次の� �目が扱われます。

GitHub Enterprise Server をアップグレードする前に、アップグレードの方針を計画するために以下の推奨事� �と要求事� �をレビューしてく� さい。

注:

  • サポートされているバージョンのアップグレード パッケージは、enterprise.github.com で入手できます。 アップグレードを完了するには、必要なアップグレードパッケージが利用できることを確認してく� さい。 パッケージが利用できない� �合はGitHub Enterprise Supportに連絡して支援を求めてく� さい。
  • GitHub Enterprise Server クラスタリングを使用している� �合、クラスタリングに固有の具体的な手� �については、GitHub Enterprise Server クラスタリング ガイドの「クラスターのアップグレード」を参照してく� さい。
  • GitHub Enterprise Server のリリースノートには、GitHub Enterprise Server のすべてのバージョンの新機能の包括的なリストがあります。 詳細については、リリース ページを参照してく� さい。

推奨事� �

  • アップグレードのプロセスに含めるアップグレードは、できる� け少なくしてく� さい。 たとえば GitHub Enterprise 3.5 から 3.6 を経て 3.7 にアップグレードする代わりに、GitHub Enterprise 3.5 から 3.7 にアップグレードできます。 アップグレード アシスタント を使用して、現在のリリース バージョンからのアップグレード パスを見つけます。
  • 数バージョン古いものを使用している� �合、アップグレード プロセスの各ステップで可能な限り新しいバージョンまで your GitHub Enterprise Server instance をアップグレードします。 各アップグレードで可能な限りの最新バージョンを使うことで、パフォーマンスの改善やバグフィックスのメリットが得られます。 たとえばGitHub Enterprise2.7から2.8を経て2.10へアップグレードすることができますが、GitHub Enterprise2.7から2.9を経て2.10へのアップグレードすれば、2番目のステップでより新しいバージョンを利用できます。
  • アップグレードの際には、最新のパッチリリースを使ってく� さい。 GitHub Enterprise Server リリース ページを参照します。 アップグレード先対象リリースの横にある [ダウンロード] をクリックし、 [アップグレード] タブをクリックします。
  • アップグレードのステップのテストには、ステージングインスタンスを使ってく� さい。 詳細については、「ステージング インスタンスの設定」を参照してく� さい。
  • 複数のアップグレードを実行する� �合は、機能のアップグレードの間に少なくとも 24 時間待って、データ移行とバックグラウンドで実行されているアップグレードタスクが完全に完了するようにします。
  • 仮想マシンをアップグレードする前にスナップショットを作成します。 詳細については、「スナップショットの作成」を参照してく� さい。
  • インスタンスの最新の正常なバックアップがあることを確認します。 詳細については、GitHub Enterprise Server Backup Utilities の README.md ファイルを参照してく� さい。

要件

  • アップグレードは、最大でも 2 リリース前の機能リリースから行わなければなりません。 たとえば GitHub Enterprise 3.7 にアップグレードするためには、GitHub Enterprise 3.6 あるいは 3.5 となっていなければなりません。
  • アップグレード パッケージを使ってアップグレードをする� �合は、GitHub Enterprise Server のエンド ユーザーのためにメンテナンス期間をスケジューリングします。
  • GitHub Enterprise Serverは、ホットパッチを利用して最新のパッチリリースへアップグレードできます。ホットパッチにはメンテナンスウィンドウが不要で、通常は再起動も必要ありません。

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

  • ホットパッチは、影響するサービス（カーネル、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の監査ログで必要なディスク容量の概算には、この数字を使用します。 スクリプトは、インポートの進行中に空きディスク容量も監視します。 この数字を監視しておくと、空きディスク容量が、移行に必要なディスク容量に近い� �合に特に便利です。

次の手� �

これらの推奨および要求事� �をレビューした後で、GitHub Enterprise Server をアップグレードできます。 詳細については、「GitHub Enterprise Server をアップグレードする」を参照してく� さい。