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

アップグレード パッケージを使用して、GitHub Enterprise Server を新しい機能リリースにアップグレードする方法について説明します。

この記事の内容

管理シェルを使用して、ghe-upgrade ユーティリティでアップグレード パッケージをインストールできます。

バックツーバック機能バージョン アップグレードを実行している場合は、機能リリースへの次のアップグレードに進む前に、バックグラウンド ジョブが完了していることを確認する必要があります。 GitHub では、2 回目にアップグレードする前にバックグラウンド アップグレード タスクを完了できるように、アップグレードの間に 24 時間待機することが推奨されます。 「アップグレード プロセスの概要」および「アップグレードの要求事項」を参照してください。

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

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

Note

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

  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 インスタンス上のすべてのアクティブなプロセスが完了するのを待ってください。 「メンテナンスモードの有効化とスケジューリング」を参照してください。

    Note

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

  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-migrations ユーティリティを使用してデータベース移行の状態を監視できます。 「コマンド ライン ユーティリティ」を参照してください。

  8. インスタンスの再起動後、アップグレードはバックグラウンドで続行されます。 プロセスが完了するまで、メンテナンス モードの設定を解除することはできません。

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

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

tail -f /data/user/common/ghe-config.log

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

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

    Note

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

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

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

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

Warning

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

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

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

    ssh -p 122 admin@REPLICA_HOST

  3. すべてのノードでレプリケーションを停止するには、各ノードで ghe-repl-stop を実行します。 または、複数のレプリカがある場合は、代わりにプライマリ ノードで ghe-repl-stop-all を実行します。この場合、1 回の実行でレプリケーションが停止されます。

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

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

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

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

    ssh -p 122 admin@REPLICA_HOST

  3. 以下を実行して、アップグレードを検証してください。

    ghe-version

  4. レプリカ ノードでレプリケーションを開始するには、ghe-repl-start を実行します。 または、レプリカが複数ある場合は、代わりにプライマリ ノードで ghe-repl-start-all を実行します。この場合、レプリケーションは 1 回の実行で始まります。 1. レプリカ ノードで、レプリケーション サービスが正しく動作していることを確認するには、ghe-repl-status を実行します。 このコマンドは、レプリケーションが問題なく進行しており、レプリカがアップグレードされていれば、すべてのサービスに対して OK を返します。 コマンドが Replication is not running を返した場合でも、レプリケーションはまだ開始されている可能性があります。 約 1 分待ってから、もう一度 ghe-repl-status を実行してください。

Note

  • 再同期の進行中は、ghe-repl-status でレプリケーションが遅れていることが示される可能性があります。 たとえば、次のようなメッセージが表示されることがあります。

    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-status が OK を返さず、上記のノートに説明が記載されていない場合は、GitHub Enterprise サポート にお問い合わせください。 詳しくは、「GitHub Support へのお問い合わせ」を参照してください。

  1. 追加ノードごとに上記の手順を繰り返します。
  2. 最後のレプリカ ノードをアップグレードし、再同期が完了した後、メンテナンス モードを無効にして、ユーザーが お使いの GitHub Enterprise Server インスタンスを使用できるようにします。