アップグレード プロセスの概要

GitHub Enterprise Server は常に改善されており、機能リリースとパッチ リリースを通じて新しい機能やバグ修正が導入されています。 インスタンスへのアップグレードは、お客様の責任で行います。 「新しいリリースへのアップグレードについて」を参照してください。

インスタンスをアップグレードするには、次の手順を実行する必要があります。

1. アップグレードのバージョンと適切なアップグレード パッケージを選択し、メンテナンス期間をスケジュールして、アップグレード戦略を計画します。
2. アップグレードプロセスの前後にアップグレードを通知します。
3. バックアップを作成し仮想マシン スナップショットを作成して、バックアップ戦略を準備します。
4. 適切なパッケージと方法を使用してアップグレード パッケージをインストールします。
5. アップグレード後のタスクを完了します。

アップグレード パッケージを適用するために従う必要があるプロセスは、展開トポロジ内のノードの数によって異なります。 この記事では、スタンドアロンまたは高可用性構成でのみインスタンスをアップグレードするための一般的な情報を提供します。

アップグレード戦略の計画

アップグレードの計画

• アップグレードを実行する前に、リリース ノートと文書化された既知の問題を確認してください。 「リリース ノート」と「インスタンスへのアップグレードに関する既知の問題」を参照してください。
• アップグレードの要件と推奨事項を理解するには、「アップグレードの要求事項」を参照してください。
• お使いの GitHub Enterprise Server インスタンスのデータ ディスクが少なくとも 15% 空きであることを確認します。 GitHub では、ディスクに追加の空き記憶域があることを確認することをお勧めします。 まれに、データ量が多いお客様の場合、このしきい値が異なることがあります。 「ストレージ容量の増加」を参照してください。
• GitHub Enterprise Serverに十分なハードウェア リソースがあることを確認します。 アップグレード時に、メモリ、CPU コア、ユーザーとルート ディスク ストレージなどのシステム ハードウェア リソースの最小要件がインスタンスで使用できるかどうかを事前チェックで評価します。 事前チェックでリソース不足やその他の失敗があると判断された場合は、通知が送信され、アップグレードが中止されます。
• カスタマイズされた規則はアップグレード後も保持されないため、 お使いの GitHub Enterprise Server インスタンスのすべてのカスタム ファイアウォール規則のコピーがあることを確認します。 アップグレード後にカスタム ルールを再適用する必要があります。 「組み込みファイアウォールのルール設定」を参照してください。
• 高可用性構成のインスタンスの場合は、アップグレードする前に、レプリケーションレポートの状態 OK を確認してください。 「高可用性構成の監視」を参照してください。
• アップグレード後にサーバーの正常性を検証するために、 お使いの GitHub Enterprise Server インスタンス へのアクセスを一時的に制限できるように、メンテナンス モード用に IP 例外リストを構成することを検討してください。 「メンテナンスモードの有効化とスケジューリング」を参照してください。

アップグレード バージョンとパッケージを選択する

• アップグレードの戦略を決定し、アップグレード先のバージョンを選択してください。
  • GitHub Enterprise Server インスタンスは、新しいパッチ リリースまたは新しい機能リリースにアップグレードできます。
  • アップグレードアシスタント を参照して、現在のリリース バージョンから新しいパッチまたは機能リリース バージョンへのアップグレード パスを見つけます。
• アップグレード パッケージ (ホットパッチまたはアップグレード パッケージ) を選択します。
  • パッチ リリースにアップグレードするために、ホットパッチまたはアップグレード パッケージを使用できます。 機能リリースにアップグレードするには、アップグレード パッケージを使用する必要があります。
  • アップグレード パッケージを使用する場合は、エンド ユーザー GitHub Enterprise Server メンテナンス期間をスケジュールします。 ホットパッチを利用している場合、メンテナンスモードは必要ありません。
  • 自動更新チェックを有効にした場合、アップグレード パッケージがダウンロードされ、利用可能であることがサイト管理者に通知されます。 「自動アップデートチェックの有効化」を参照してください。
  • リリース候補の構築は、テスト環境での使用のみを目的としています。 運用環境にリリース候補の構築をインストールしないでください。 リリース候補から後のバージョン（一般提供リリースを含む）にアップグレードしないでください。

他のアプリケーションの更新が必要かどうかを検討します

次のアプリケーションをアップグレードする必要があるかどうかを確認します。

• GitHub Actions お使いの GitHub Enterprise Server インスタンスがGitHub Actionsにエフェメラル セルフホステッド ランナーを使用し、自動更新が無効になっている場合は、ランナーを更新する必要があります。 アップグレードを実行する前に、ランナーをアップグレードしたインスタンスに必要なアプリケーションの最小バージョンにアップグレードします。 リリースに必要な最小バージョンについては、「GitHub Enterprise Server リリース」を参照してください。
• GitHub Enterprise Server Backup Utilities。 GitHub Enterprise Server Backup Utilitiesのバージョンは、お使いの GitHub Enterprise Server インスタンスより前のバージョンと同じか、最大 2 つのバージョンである必要があります。

  • インスタンスをアップグレードする前に、 GitHub Enterprise Server Backup Utilities を新しいバージョンにアップグレードすることが必要になる場合があります。

  • インスタンスをアップグレードした後、 GitHub Enterprise Server Backup Utilities を新しいバージョンにアップグレードすることもできます。

プロジェクトのドキュメントの AUTOTITLE と GitHub Enterprise Server Backup Utilities を参照してください。

メンテナンス期間を計画する

• アップグレード戦略によっては、大幅なダウンタイムが必要になる場合があります。
• 予想されるダウンタイム期間を決定する最善の方法は、まずステージング環境でアップグレードをテストすることです。 「ステージングインスタンスのセットアップ」を参照してください。
• アップグレードのためのメンテナンス期間は、実行するアップグレードの種類によって変わります。

  • ホットパッチを利用するアップグレードは、通常メンテナンスウィンドウを必要としません。 リブートが必要になることもあります。そのリブートは後で行うことができます。

    メモ

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

  • アップグレード パッケージを使用したパッチ リリースは、通常 5 分未満のダウンタイムが発生します。

  • データ移行を含む新しい機能リリースにアップグレードすると、ストレージのパフォーマンスと移行されるデータの量によっては、数時間のダウンタイムが発生する可能性があります。 この間、どのユーザーもエンタープライズを使用できなくなります。 新しい機能リリースへのアップグレードに要する時間が短い場合があります。 これは、選択的なデータベース遷移が同時に実行され、同時ワーカーの数が CPU コアの数 (最大 16 個) に既定で設定されるためです。

アップグレードの通知

• アップグレードの前に、グローバルお知らせバナーを発行して、受信した変更やダウンタイムの可能性など、ユーザーに重要な情報を強調表示することができます。 「Enterprise のユーザメッセージをカスタマイズする」を参照してください。
• アップグレード時に、メンテナンス モードを有効にし、インスタンスが一時的に使用できないことをユーザーに通知するカスタム メッセージを設定できます。 「メンテナンスモードの有効化とスケジューリング」を参照してください。

バックアップ戦略の準備

バックアップ スナップショットの作成

アップグレード プロセスを開始する前に、インスタンスのプライマリ ノードの最新の正常なバックアップ スナップショットがあることを確認します。 プロジェクトのドキュメントの AUTOTITLE と GitHub Enterprise Server Backup Utilities を参照してください。

VM スナップショットを作成する

新しい機能リリースにアップグレードする場合は、仮想マシン (VM) スナップショットが必要です。 パッチリリースへのアップグレードをするなら、既存のデータディスクをアタッチできます。

アップグレードの直前に、メンテナンス モードが有効になっているか、インスタンスの電源がオフになっている場合にのみ、インスタンスのプライマリ ノードの仮想マシン (VM) スナップショットを作成します。 「スナップショットの取得」を参照してください。

アップグレード パッケージのインストール

アップグレード パッケージのインストールを開始する前に、アップグレードに関する考慮事項を確認し、上記の準備手順を完了してください。

GitHub Enterprise Server インスタンスをアップグレードする手順は、実行しているアップグレードの種類とインスタンスに含まれるノードの数によって異なります。

• ホットパッチでのアップグレード
  • ホットパッチを使用したスタンドアロン インスタンスのアップグレード
  • ホットパッチを使用した複数のノードを持つインスタンスのアップグレード
• アップグレードパッケージでのアップグレード
  • アップグレード パッケージを使用したスタンドアロン インスタンスのアップグレード
  • アップグレード パッケージを使用した複数のノードを持つインスタンスのアップグレード

アップグレード後のタスクの完了

• バックグラウンド ジョブの状態を確認し、アップグレード ログでエラーを確認します。
• 基本的な GitHub Enterprise Server 機能を確認します。 たとえば、ユーザー インターフェイスを使用してサインインできることを確認し、組織、リポジトリ、問題のいくつかに期待どおりに到達できることを確認します。 また、SSH や HTTPS を使用して、いくつかの Git フェッチ、複製、プッシュを手動で実行し、API 要求と Webhook 配信が正常に完了したことを確認することが推奨されます。
• カスタム ファイアウォール規則を再適用します。 「組み込みファイアウォールのルール設定」を参照してください。
• アップグレードする前に作成されたすべての VM スナップショットを削除します。 「スナップショットの取得」を参照してください。
• メンテナンス モードを無効にし、お知らせバナーなどのアップグレード前の通知を更新します。 「Enterprise のユーザメッセージをカスタマイズする」と「メンテナンスモードの有効化とスケジューリング」を参照してください。
• インスタンス上のすべてのキューに置かれたバックグラウンド ジョブを監視して、正常に完了したことを確認します。 「コマンド ライン ユーティリティ」を参照してください。