Skip to main content
ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

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

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

ノート:

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

推奨される対応

  • アップグレードのプロセスに含めるアップグレードは、できるだけ少なくしてください。 たとえば GitHub Enterprise 3.3 から 3.4 を経て 3.5 にアップグレードする代わりに、GitHub Enterprise 3.3 から 3.5 にアップグレードできます。 Use the Upgrade assistant to find the upgrade path from your current release version.
  • バージョンが数バージョン古いのであれば、GitHub Enterprise Serverインスタンスをアップグレードのプロセスの各ステップでできる限り先までアップグレードしてください。 各アップグレードで可能な限りの最新バージョンを使うことで、パフォーマンスの改善やバグフィックスのメリットが得られます。 たとえばGitHub Enterprise2.7から2.8を経て2.10へアップグレードすることができますが、GitHub Enterprise2.7から2.9を経て2.10へのアップグレードすれば、2番目のステップでより新しいバージョンを利用できます。
  • アップグレードの際には、最新のパッチリリースを使ってください。 GitHub Enterprise Serverのリリースページにアクセスしてください。 アップグレードしたいリリースの隣の Download(ダウンロード)をクリックし、続いて Upgrading(アップグレード)タブをクリックしてください。
  • アップグレードのステップのテストには、ステージングインスタンスを使ってください。 詳しい情報については "ステージングインスタンスのセットアップ"を参照してください。
  • 複数のアップグレードを実行する場合は、機能のアップグレードの間に少なくとも 24 時間待って、データ移行とバックグラウンドで実行されているアップグレードタスクが完全に完了するようにします。
  • Take a snapshot before upgrading your virtual machine. 詳細は「スナップショットを取得する」を参照してください。
  • Ensure you have a recent, successful backup of your instance. 詳しい情報については、GitHub Enterprise ServerバックアップユーティリティREADME.md ファイルを参照してください。

要件

  • アップグレードは、最大でも2リリース前のフィーチャリリースから行わなければなりません。 たとえば GitHub Enterprise 3.5 にアップグレードするためには、GitHub Enterprise 3.4 あるいは 3.3 となっていなければなりません。
  • When upgrading using an upgrade package, schedule a maintenance window for GitHub Enterprise Server end users.
  • 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 をアップグレードする」を参照してください。