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

ここには以下の内容があります:

• 推奨される対応
• 要件

推奨される対応

• アップグレードのプロセスに含めるアップグレードは、できるだけ少なくしてください。 たとえば GitHub Enterprise 2.17 から 2.18 を経て 2.19 にアップグレードする代わりに、GitHub Enterprise 2.17 から 2.19 にアップグレードできます。

• バージョンが数バージョン古いのであれば、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 2.19 にアップグレードするためには、GitHub Enterprise 2.18 あるいは 2.17 でなければなりません。

• GitHub Enterprise Serverは、ホットパッチを利用して最新のパッチリリースへアップグレードできます。ホットパッチにはメンテナンスウィンドウが不要で、通常は再起動も必要ありません。 ホットパッチは新しいパッチリリースへのアップグレードに利用できますが、新しいフィーチャリリースへのアップグレードには利用できません。 たとえば2.10.1から2.10.5へのアップグレードは同じフィーチャリリースなので可能ですが、2.10.9から2.11.0へは異なるフィーチャリリースなので行えません。

• ホットパッチは、影響するサービス（カーネル、MySQL、Elasticsearchなど）がVMの再起動やサービスの再起動を必要とするなら、ダウンタイムが必要になります。 リブートや再起動が必要になったときには通知されます。 リブートや再起動は後で完了させることができます。

• ホットパッチでアップグレードをする場合、アップグレードの完了までに特定のサービスの複数バージョンがインストールされることから、追加のルートストレージが利用できなければなりません。 十分なルートディスクストレージがなければ、事前チェックで通知されます。

• ホットパッチでアップグレードする場合、インスタンスの負荷は高すぎてはなりません。もし負荷が高すぎると、ホットパッチのプロセスに影響するかもしれません。 Pre-flight checks will consider the load average and the upgrade will fail if the load average is too high.

• If you're upgrading a GitHub Enterprise Server cluster to version 2.16, ensure that you define both a primary datacenter and a Consul configuration in the cluster configuration file before you upgrade. For more information, see "Initializing the cluster."

• Upgrading to GitHub Enterprise Server 2.17 migrates your audit logs from Elasticsearch to 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 をアップグレードする」を参照してください。