Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-03-26. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

GitHub Enterprise Server をアップグレードする

最新の機能とセキュリティ更新プログラムを入手するために、GitHub Enterprise Server をアップグレードしてください。

この機能を使用できるユーザーについて

Site administrators can upgrade a GitHub Enterprise Server instance.

GitHub Enterprise Server へのアップグレードについて

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

インスタンスをアップグレードするには、アップグレードの計画と通知、適切なパッケージの選択、データのバックアップ、アップグレードの実行が必要になります。

前提条件

お使いの GitHub Enterprise Server インスタンス を正常にアップグレードするには、インスタンスのデータ ディスクの空き容量が 15% 以上である必要があります。 GitHub では、ディスク上により多くの空き記憶域があることを確認することが推奨されます。 まれに、データ量が多いお客様の場合、このしきい値が異なることがあります。

アップグレードの準備

アップグレードを準備するには、アップグレード パスを計画し、必要に応じて GitHub Actions ランナーをアップグレードし、メンテナンス期間をスケジュールします。

  1. アップグレードの戦略を決定し、アップグレード先のバージョンを選択してください。 詳しくは、「アップグレードの要求事項」をご覧ください。また、「Upgrade Assistant」を参照し、現在のリリース バージョンからのアップグレード パスを見つけてください。

  2. GitHub Enterprise Server Backup Utilities で、インスタンスのプライマリ ノードの新しいバックアップを作成します。 詳しくは、GitHub Enterprise Server Backup Utilities プロジェクト ドキュメントの README を参照してください。

    注: GitHub Enterprise Server Backup Utilities バージョンは、お使いの GitHub Enterprise Server インスタンスと同じバージョンであるか、最大で 2 つ前のバージョンである必要があります。 詳しくは、「インスタンスでのバックアップの構成」を参照してください。

  3. お使いの GitHub Enterprise Server インスタンスが GitHub Actions にエフェメラル セルフホステッド ランナーを使っていて、自動更新を無効にしている場合、アップグレードされたインスタンスが実行するランナー アプリケーションのバージョンにランナーをアップグレードしてください。

  4. アップグレードパッケージを使ってアップグレードをする場合は、GitHub Enterprise Server のエンドユーザのためにメンテナンス時間枠をスケジューリングしてください。 ホットパッチを利用している場合、メンテナンスモードは必要ありません。

    注: メンテナンス期間は、実行するアップグレードの種類によって変わります。 ホットパッチを利用するアップグレードは、通常メンテナンスウィンドウを必要としません。 リブートが必要になることもあります。そのリブートは後で行うことができます。 MAJOR.FEATURE.PATCH というバージョン付けのスキームに従い、アップグレードパッケージを使ったパッチのリリースで生じるダウンタイムは、通常 5 分未満です。 データの移行を含むフィーチャリリースは、ストレージの性能および移行するデータの量に応じた時間がかかります。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

スナップショットの取得

スナップショットには、ある時点での仮想マシン (VM) の状態が格納されます。 GitHub では、アップグレードに失敗した場合に VM をスナップショットに戻せるように、VM をアップグレードする前にスナップショットを作成しておくことが強く推奨されます。 GitHub では、インスタンスの VM の電源が切れているか、インスタンスがメンテナンス モードであり、すべてのバックグラウンド ジョブが完了している場合にのみ、VM スナップショットを作成することが推奨されます。

新しいフィーチャリリースにアップグレードするなら、VM のスナップショットを取らなければなりません。 パッチリリースへのアップグレードをするなら、既存のデータディスクをアタッチできます。

スナップショットには2種類あります。

  • VM スナップショットは、ユーザー データと構成データを含む VM の状態全体を保存します。 このスナップショットの手法には大量のディスク領域が必要になり、時間がかかります。

  • データ ディスク スナップショットは、ユーザー データのみを保存します。

    注:

    • プラットフォームによっては、ユーザのデータディスクだけのスナップショットを取ることができません。 それらのプラットフォームでは、VM 全体のスナップショットを取る必要があります。
    • ハイパーバイザーが完全なVMスナップショットをサポートしていないなら、ルートディスクとデータディスクのスナップショットを時間をおかずに取らなければなりません。
プラットフォームSnapshot メソッドドキュメント
Amazon AWSディスクAWS ドキュメントの「Amazon EBS スナップショットの作成
AzureVMMicrosoft Learn の「仮想ハード ディスクのスナップショットを作成する
Hyper-VVMMicrosoft Learn の「Hyper-V でチェックポイントを有効または無効にする
Google Compute EngineディスクGoogle Cloud ドキュメントの「ディスク スナップショットを作成して管理する
VMwareVMVMware Docs の「Taking Snapshots of a Virtual Machine (仮想マシンのスナップショットの作成)

アップグレード パッケージの選択

GitHub Enterprise Server インスタンスを新しいパッチ リリースまたは新しい機能リリースにアップグレードできます。 パッチ リリースにアップグレードするために、ホットパッチまたはアップグレード パッケージを使用できます。 機能リリースにアップグレードするには、アップグレード パッケージを使用する必要があります。

GitHub Enterprise Server インスタンスは、1 つまたは複数のノードで構成されます。 従う必要があるアップグレード プロセスは、インスタンスに含まれるノードの数によって異なります。 詳しくは、「GitHub Enterprise Server について」を参照してください。

ホットパッチでのアップグレード

ホットパッチを使って GitHub Enterprise Server を最新のパッチ リリースにアップグレードできます。

ホットパッチは新しいパッチリリースへのアップグレードに利用できますが、新しいフィーチャリリースへのアップグレードには利用できません。 たとえば、2.10.1 から 2.10.5 は同じ機能シリーズに含まれているためアップグレードできますが、2.10.9 から 2.11.0 は異なる機能シリーズに含まれているためアップグレードできません。

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

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

[Management Console] を使うと、ホットパッチをすぐにインストールすることや、後でインストールするようにスケジュールすることができます。 管理シェルで、ghe-upgrade ユーティリティを使ってホットパッチをインストールすることもできます。 詳しくは、「アップグレードの要求事項」を参照してください。

:

  • お使いの GitHub Enterprise Server インスタンスによってリリース候補ビルドが実行されている場合、ホットパッチを使ったアップグレードはできません。

  • クラスターでは、[Management Console]を使ってホットパッチをインストールすることはできません。 クラスターのホットパッチをインストールする場合は、「クラスタのアップグレード」を参照してください。

ホットパッチを使用したスタンドアロン インスタンスのアップグレード

ホットパッチを使用して 1 つのノードを持つインスタンスをアップグレードしており、ターゲットがパッチ リリースである場合は、[Management Console]を使ってアップグレードできます。 機能のリリースにアップグレードするには、管理シェルを使用する必要があります。

[Management Console] を使ってホットパッチをインストールする

[Management Console] を使って自動更新を有効にすることで、ホットパッチを使ってアップグレードできます。 そうすると、アップグレード可能な GitHub Enterprise Server の最新バージョンが表示されます。

表示されたアップグレード ターゲットがパッチ リリースではなく、機能リリースであった場合は、[Management Console] を使ってホットパッチをインストールすることはできません。 代わりに管理シェルを使ってホットパッチをインストールする必要があります。 詳細については、「管理シェルを使ったホットパッチのインストール」を参照してください。

  1. 自動更新を有効にする。 詳しくは、「自動アップデートチェックの有効化」を参照してください。

  2. GitHub Enterprise Server の管理アカウントから、任意のページの右上隅で をクリックします。

  3. [サイト管理者] ページにまだ表示されていない場合は、左上隅の [サイト管理者] をクリックします。

  4. [ サイト管理者] サイドバーで [Management Console] をクリックします。

  5. 上部のナビゲーション バーで [更新プログラム] をクリックします。

    [Management Console] のヘッダーのスクリーンショット。 [更新プログラム] というラベルが付いたタブがオレンジ色の枠線で強調表示されています。

  6. 新しいホットパッチがダウンロードされている場合、 [パッケージのインストール] ドロップダウン メニューを選択します。

    • すぐにインストールするには、 [今すぐ] をクリックします。
    • 後でインストールするなら、後の日付を選択してください。
  7. [インストール] をクリックします。

管理シェルを使ったホットパッチのインストール

注: 自動更新チェックを有効にすると、アップグレード パッケージをダウンロードする必要はなく、自動的にダウンロードされたファイルを利用できます。 詳しくは、「自動アップデートチェックの有効化」を参照してください。

  1. お使いの GitHub Enterprise Server インスタンス に SSH で接続します。 インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    Shell
    ssh -p 122 admin@HOSTNAME
    
  2. GitHub Enterprise Server リリース ページを参照します。 アップグレード先対象リリースの横にある [ダウンロード] をクリックし、 [アップグレード] タブをクリックします。アップグレードのホットパッケージ ( .hpkg ファイル) の URL をコピーします。

  3. curl を使って、アップグレード パッケージを お使いの GitHub Enterprise Server インスタンス にダウンロードします。

    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
    
  4. このパッケージ ファイル名を使って ghe-upgrade コマンドを実行します。

    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.hpkg
    *** verifying upgrade package signature...
    
  5. 少なくとも 1 つのサービスまたはシステム コンポーネントで再起動が必要な場合は、ホットパッチ アップグレード スクリプトによって通知されます。 たとえば、カーネル、MySQL、Elasticsearch の更新には再起動が必要な場合があります。

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

ホットパッチをインストールする場合、メンテナンス モードに切り替えたり、レプリケーションを停止したりする必要はありません。

ホットパッチを使用したプライマリ ノードのアップグレード

プライマリ ノードをアップグレードする手順については、「管理シェルを使ったホットパッチのインストール」を参照してください。

ホットパッチを使用した追加ノードのアップグレード

高可用性や geo レプリケーション構成など、複数のノードから構成されるインスタンスをアップグレードするには、レプリカ ノードごとに、一度に 1 つずつ、次の手順を繰り返す必要があります。

  1. ノードをアップグレードするには、「管理シェルを使ったホットパッチのインストール」の手順に従います。

  2. ポート 122 の SSH 経由でレプリカ ノードに admin ユーザーとして接続します。

    ssh -p 122 admin@REPLICA_HOST
    
  3. 以下を実行して、アップグレードを検証してください。

    ghe-version
    
  4. 追加ノードごとに上記の手順を繰り返します。

アップグレードパッケージでのアップグレード

フィーチャシリーズ内の最新のパッチリリースへのアップグレードにはホットパッチが利用できますが、新しいフィーチャリリースへのアップグレードにはアップグレードパッケージを使わなければなりません。 たとえば 2.11.10 から 2.12.4 へのアップグレードの場合、これらは異なる機能シリーズなので、アップグレード パッケージを使う必要があります。 詳しくは、「アップグレードの要求事項」を参照してください。

アップグレード パッケージを使用したスタンドアロン インスタンスのアップグレード

注: 自動更新チェックを有効にすると、アップグレード パッケージをダウンロードする必要はなく、自動的にダウンロードされたファイルを利用できます。 詳しくは、「自動アップデートチェックの有効化」を参照してください。

  1. お使いの GitHub Enterprise Server インスタンス に SSH で接続します。 インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。

    Shell
    ssh -p 122 admin@HOSTNAME
    
  2. GitHub Enterprise Server リリース ページを参照します。 アップグレード先対象リリースの横にある [ダウンロード] をクリックし、 [アップグレード] タブをクリックします。適切なプラットフォームを選び、アップグレード パッケージ ( .pkg fファイル) の URL をコピーします。

  3. curl を使って、アップグレード パッケージを お使いの GitHub Enterprise Server インスタンス にダウンロードします。

    admin@HOSTNAME:~$ curl -L -O UPGRADE-PKG-URL
    
  4. メンテナンスモードを有効にし、GitHub Enterprise Server インスタンス上のすべてのアクティブなプロセスが完了するのを待ってください。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

    : 「プライマリ ノードのアップグレード」の手順に従っている場合、高可用性構成のプライマリ ノードをアップグレードするときにインスタンスは既にメンテナンス モードになっているはずです。

  5. このパッケージ ファイル名を使って ghe-upgrade コマンドを実行します。

    admin@HOSTNAME:~$ ghe-upgrade GITHUB-UPGRADE.pkg
    *** verifying upgrade package signature...
    
  6. アップグレードを続けてパッケージ署名検証後に再起動することを承諾します。 新しいルートファイルシステムがセカンダリパーティションに書かれ、インスタンスは自動的にメンテナンスモードで再起動します。

    *** applying update...
    This package will upgrade your installation to version VERSION-NUMBER
    Current root partition: /dev/xvda1 [VERSION-NUMBER]
    Target root partition:  /dev/xvda2
    Proceed with installation? [y/N]
    
  7. インスタンスの再起動後、アップグレードはバックグラウンドで続行されます。 プロセスが完了するまで、メンテナンス モードの設定を解除することはできません。

バックグラウンド ジョブの状態をチェックするには、ghe-check-background-upgrade-jobs ユーティリティを使用します。 バックツーバック アップグレードを実行している場合は、機能リリースへの次のアップグレードに進む前に、バックグラウンド ジョブが完了していることを確認する必要があります。 このユーティリティを GitHub Enterprise Server 3.8 と共に使用するには、インスタンスでバージョン 3.8 を実行する必要があります。12 以降。ユーティリティの詳細 については、「コマンド ライン ユーティリティ」を参照してください

構成実行の進行状況を監視するには、/data/user/common/ghe-config.log の出力を読み取ります。 たとえば、次のコマンドを実行してログを追跡できます。

tail -f /data/user/common/ghe-config.log
  1. 必要に応じて、アップグレード後に指定された IP アドレスのリストへのアクセスを許可するように IP 例外リストを構成して、アップグレードを検証します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

  2. 単一ノードのアップグレードの場合は、メンテナンス モードを無効にして、ユーザーが お使いの GitHub Enterprise Server インスタンスを使用できるようにします。

    : 高可用性構成のインスタンスをアップグレードした後、すべてのレプリカ ノードをアップグレードし、レプリケーションが最新の状態になるまでは、メンテナンス モードのままにしておいてください。 詳しくは、「アップグレード パッケージを使用した追加ノードのアップグレード」を参照してください。

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

アップグレード パッケージを使用して複数のノードで構成されるインスタンスをアップグレードするには、プライマリ ノードをアップグレードしてから、追加のノードをアップグレードする必要があります。

アップグレード パッケージでのプライマリ ノードのアップグレード

警告: レプリケーションを停止したときにプライマリに障害が発生した場合、レプリカをアップグレードしてレプリケーションを再開する前に行った作業内容は失われます。

  1. プライマリ ノードでメンテナンス モードを有効にし、すべてのアクティブなプロセスが完了するのを待ちます。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。

  2. ポート 122 の SSH 経由でレプリカ ノードに admin ユーザーとして接続します。

    ssh -p 122 admin@REPLICA_HOST
    
  3. すべてのノードでレプリケーションを停止するには、各ノードで ghe-repl-stop を実行します。

  4. プライマリ ノードをアップグレードするには、「アップグレード パッケージを使用したスタンドアロン インスタンスのアップグレード」の手順に従います。

アップグレード パッケージでの追加ノードのアップグレード

高可用性や geo レプリケーション構成など、複数のノードから構成されるインスタンスをアップグレードするには、レプリカ ノードごとに、一度に 1 つずつ、次の手順を繰り返す必要があります。

  1. アップグレード パッケージを使用したスタンドアロン インスタンスのアップグレード」の手順に従って、プライマリ ノードをアップグレードします。

  2. ポート 122 の SSH 経由でレプリカ ノードに admin ユーザーとして接続します。

    ssh -p 122 admin@REPLICA_HOST
    ```1. 以下を実行して、アップグレードを検証してください。
    
    ```shell
    ghe-version
    ```1. レプリカ ノードでレプリケーションを開始するには、`ghe-repl-start` を実行します。1. レプリカ ノードで、レプリケーション サービスが正しく動作していることを確認するには、`ghe-repl-status` を実行します。 このコマンドは、レプリケーションが問題なく進行しており、レプリカがアップグレードされていれば、すべてのサービスに対して `OK` を返します。コマンドから `Replication is not running` が返された場合でも、レプリケーションが開始されている可能性があります。 約 1 分待ってから、もう一度 `ghe-repl-status` を実行してください。
    
    <div class="ghd-alert ghd-alert-accent ghd-spotlight-accent">
    
    **注:**
    
    - 再同期の進行中は、`ghe-repl-status` でレプリケーションが遅れていることが示される可能性があります。 たとえば、次のようなメッセージが表示されることがあります。
    
      ```text
      CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists
    
    • GitHub Actions が お使いの GitHub Enterprise Server インスタンス で有効になっている場合は、次のようなメッセージが表示されることがあります。 このメッセージは、プライマリ アプライアンスでメンテナンス モードが設定されているため、レプリケーションが一時停止されている場合に表示されます。 メンテナンス モードが設定解除されると、このメッセージは解消されるはずです。

      CRITICAL: mssql replication is down, didn't find Token_Configuration!
      

    ghe-repl-statusOK を返さず、上記のノートに説明が記載されていない場合は、GitHub Enterprise サポート にお問い合わせください。 詳しくは、「GitHub Support へのお問い合わせ」を参照してください。

  3. 追加ノードごとに上記の手順を繰り返します。

  4. 最後のレプリカ ノードをアップグレードし、再同期が完了した後、メンテナンス モードを無効にして、ユーザーが お使いの GitHub Enterprise Server インスタンスを使用できるようにします。

失敗したアップグレードからのリストア

アップグレードが失敗もしくは中断したなら、インスタンスを以前の状態に復帰させなければなりません。 この処理を完了させるプロセスは、アップグレードの種類によります。

パッチリリースのロールバック

パッチ リリースをロールバックするには、--allow-patch-rollback スイッチを指定して ghe-upgrade コマンドを使用します。 ロールバックする前に、すべてのレプリカ ノード上で ghe-repl-stop を実行してレプリケーションを一時的に停止する必要があります。 アップグレードをロールバックする場合は、拡張子が .pkg のアップグレード パッケージ ファイルを使用する必要があります。 拡張子が .hpkg のホットパッチ パッケージ ファイルはサポートされていません。

ghe-upgrade --allow-patch-rollback EARLIER-RELEASE-UPGRADE-PACKAGE.pkg

このコマンドの実行後には再起動が必要です。 パッチリリースでは移行は行われないので、ロールバックはデータパーティションには影響しません。

ロールバックが完了した後、すべてのノード上で ghe-repl-start を実行してレプリケーションを再開します。

詳しくは、「コマンド ライン ユーティリティ」を参照してください。

フィーチャリリースのロールバック

フィーチャリリースからロールバックするには、ルートおよびデータパーティションが整合した状態になることを保証するため、VM スナップショットからリストアしてください。 詳細については、「スナップショットの作成」を参照してください。

参考資料