Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

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

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 にアップグレードできます。 Upgrade assistant を使用して、現在のリリース バージョンからのアップグレード パスを見つけます。
  • 数バージョン古いものを使用している場合、アップグレード プロセスの各ステップで可能な限り新しいバージョンまで 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 は異なる機能シリーズに含まれているためアップグレードできません。

ホットパッチでは通常、再起動は必要ありません。 ホットパッチで再起動が必要になる場合、GitHub Enterprise Server リリース ノートに要件が示されます。

ホットパッチには構成実行が必要です。構成実行すると、your GitHub Enterprise Server instance の一部または全部のサービスで短い時間、エラーが発生したり、応答しなかったりすることがあります。 ホットパッチのインストール中はメンテナンス モードを有効にする必要はありませんが、有効にすると、エラーまたはタイムアウトではなくメンテナンス ページがユーザーに表示されます。 詳細については、「メンテナンスモードの有効化とスケジューリング」を参照してください。

  • ホットパッチは、影響するサービス(カーネル、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 をアップグレードする」を参照してください。