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

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

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

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

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

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

アップグレードの計画

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

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

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

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

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

• お使いの GitHub Enterprise Server インスタンス が GitHub Actions に対してエフェメラル セルフホステッド ランナーを使用し、自動更新が無効になっている場合、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 の新しいバージョンへのアップグレードする場合もあります。

  「インスタンスでのバックアップの構成」と GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの README を参照してください。

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

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

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

    Note

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

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

  • データ移行を含む新しい機能リリースにアップグレードすると、ストレージのパフォーマンスと移行されるデータの量によっては、数時間のダウンタイムが発生する可能性があります。 この間、どのユーザーも Enterprise を使用できなくなります。

アップグレードの通知

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

バックアップ戦略の準備

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

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

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

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

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

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

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

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

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

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

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