ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

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

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

このガイドの内容

アップグレードの準備

  1. アップグレードの戦略を決定し、アップグレード先のバージョンを選択してください。 詳しい情報については、「アップグレードの要求事項」を参照してください。

  2. GitHub Enterprise Serverバックアップユーティリティ で、プライマリインスタンスの新しいバックアップを作成してください。 詳しい情報については、GitHub Enterprise ServerバックアップユーティリティREADME.md ファイルを参照してください。

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

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

スナップショットの取得

スナップショットは、ある時点での仮想マシン(VM)のチェックポイントです。 アップグレードに失敗した場合にスナップショットからVMを回復できるよう、仮想マシンをアップグレードする前にスナップショットを取っておくことを強くおすすめします。 新しいフィーチャリリースにアップグレードするなら、VM のスナップショットを取らなければなりません。 パッチリリースへのアップグレードをするなら、既存のデータディスクをアタッチできます。

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

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

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

    注釈:

    • プラットフォームによっては、ユーザのデータディスクだけのスナップショットを取ることができません。 それらのプラットフォームでは、VM 全体のスナップショットを取る必要があります。
    • ハイパーバイザーが完全なVMスナップショットをサポートしていないなら、ルートディスクとデータディスクのスナップショットを時間をおかずに取らなければなりません。
プラットフォーム スナップショットの取得方法 スナップショットドキュメンテーションのURL
Amazon AWS ディスク https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
Azure VM https://docs.microsoft.com/ja-jp/azure/backup/backup-azure-vms-first-look-arm
Hyper-V VM https://technet.microsoft.com/en-us/library/dd851843.aspx
Google Compute Engine ディスク https://cloud.google.com/compute/docs/disks/create-snapshots
VMware VM https://pubs.vmware.com/vsphere-50/index.jsp#com.vmware.vsphere.vm_admin.doc_50/GUID-9720B104-9875-4C2C-A878-F1C351A4F3D8.html
XenServer VM https://support.citrix.com/article/CTX122978

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

You can upgrade GitHub Enterprise Server to the latest patch release using a hotpatch, which does not require a maintenance window and usually does not require a reboot. You can use hotpatching to upgrade to a newer patch release, but not a feature release. For example, you can upgrade from 2.10.1 to 2.10.5 because they are in the same feature series, but not from 2.10.9 to 2.11.0 because they are in a different feature series. Management Console を使うと、ホットパッチを即座にインストールすることや、後にインストールするようにスケジュールすることができます。 管理シェルを使って ghe-upgrade ユーティリティでホットパッチをインストールすることもできます。 詳細は「アップグレードの要求事項」を参照してください。

注釈: クラスタ環境では、Management Console を使ったホットパッチのインストールはできません。 クラスタ環境でホットパッチをインストールするには、「クラスタをアップグレードする」を参照してください。

ホットパッチでの単一のアプライアンスのアップグレード

Management Console を使ってホットパッチをインストールする
  1. 自動アップデートを有効化してください。 詳しい情報については「自動アップデートの有効化」を参照してください。

  2. In the upper-right corner of any page, click .

    サイトアドミン設定にアクセスするための宇宙船のアイコン

  3. 左サイドバーで [Management Console] をクリックします。

    左サイドバーの Management Console タブ

  4. At the top of the Management Console, click Updates.

    Updates menu item

  5. 新しいホットパッチがダウンロードされたなら、Install package(パッケージのインストール)ドロップダウンメニューを使ってください。

    • すぐにインストールするならNow(即時)を選択してください。
    • 後でインストールするなら、後の日付を選択してください。
      ホットパッチインストール日のドロップダウン
  6. [Install] をクリックします。

    ホットパッチインストールボタン

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

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

  1. SSH into GitHub Enterprise Server インスタンス.

    $ ssh -p 122 admin@HOSTNAME
  2. GitHub Enterprise Serverのリリースページにアクセスしてください。 アップグレードしたいリリースの隣の Download(ダウンロード)をクリックし、続いて Upgrading(アップグレード)タブをクリックしてください。 アップグレードのホットパッケージ(.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. カーネル、MySQL、Elasticsearch やその他のプログラムのアップグレードにリブートが必要なら、ホットパッチアップグレードスクリプトが通知してくれます。

ホットパッチを使ったレプリカインスタンスを持つアプライアンスのアップグレード

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

High Availability と Geo-replication が設定されたアプライアンスは、プライマリインスタンスに加えてレプリカインスタンスを使います。 これらのアプライアンスをアップグレードするには、プライマリインスタンスとすべてのレプリカインスタンスの両方を、1 つずつアップグレードしなければなりません。

プライマリインスタンスのアップグレード
  1. 管理シェルを使ってホットパッチをインストールする」の指示に従ってプライマリインスタンスをアップグレードしてください。
レプリカインスタンスのアップグレード

メモ: Geo-replication の一部として複数のレプリカインスタンスを動作させているなら、この手順は各レプリカインスタンス 1 つずつに繰り返してください。

  1. 管理シェルを使ってホットパッチをインストールする」の指示に従ってレプリカインスタンスをアップグレードしてください。Geo-replication のために複数のレプリカを使っているなら、この手順は各レプリカ 1 つずつに繰り返さなければなりません。

  2. Connect to the replica instance over SSH as the "admin" user on port 122:

    $ ssh -p 122 admin@replica-host
  3. Verify the upgrade by running:

    $ ghe-version

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

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

アップグレードパッケージでの単一のアプライアンスのアップグレード

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

  1. SSH into GitHub Enterprise Server インスタンス.

    $ ssh -p 122 admin@HOSTNAME
  2. GitHub Enterprise Serverのリリースページにアクセスしてください。 アップグレードしたいリリースの隣の Download(ダウンロード)をクリックし、続いて Upgrading(アップグレード)タブをクリックしてください。 適切なプラットフォームを選択し、アップグレードパッケージ (.pkgファイル) の URL をコピーしてください。

  3. cURLを使ってGitHub Enterprise Server インスタンスにアップグレードパッケージをダウンロードしてください。

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

    メモ: High Availability 構成のプライマリアプライアンスをアップグレードする場合には、「プライマリインスタンスをアップグレードする」の指示に従っているならアプライアンスはメンテナンスモードになっているはずです。

  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-numberCurrent root partition: /dev/xvda1 [version-number]
    Target root partition:  /dev/xvda2
    Proceed with installation? [y/N]
  7. 単一アプライアンスのアップグレードであれば、メンテナンスモードを無効化してユーザが GitHub Enterprise Server インスタンス を利用できるようにしてください。

    メモ: High Availability 設定のアプライアンスをアップグレードする場合、すべてのレプリカをアップグレードし、レプリケーションが最新の状態になるまではメンテナンスモードのままでなければなりません。 詳細は「レプリカインスタンスをアップグレードする」を参照してください。

アップグレードパッケージを使ったレプリカインスタンスを持つアプライアンスのアップグレード

High Availability と Geo-replication が設定されたアプライアンスは、プライマリインスタンスに加えてレプリカインスタンスを使います。 これらのアプライアンスをアップグレードするには、プライマリインスタンスとすべてのレプリカインスタンスの両方を、1 つずつアップグレードしなければなりません。

プライマリインスタンスのアップグレード

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

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

  2. Connect to the replica instance over SSH as the "admin" user on port 122:

    $ ssh -p 122 admin@replica-host
  3. レプリカインスタンス、あるいは Geo-replication の一部として複数のレプリカインスタンスを動作させている場合は、すべてのレプリカインスタンスで ghe-repl-stop を実行してレプリケーションを停止させます。

  4. アップグレードパッケージで単一アプライアンスをアップグレードする」の指示に従い、プライマリインスタンスをアップグレードしてください。

レプリカインスタンスのアップグレード

メモ: Geo-replication の一部として複数のレプリカインスタンスを動作させているなら、この手順は各レプリカインスタンス 1 つずつに繰り返してください。

  1. アップグレードパッケージで単一のアプライアンスをアップグレードする」の指示に従ってレプリカインスタンスをアップグレードしてください。Geo-replication 用に複数のレプリカを利用しているなら、この手順を各レプリカ 1 つずつに繰り返さなければなりません。

  2. Connect to the replica instance over SSH as the "admin" user on port 122:

    $ ssh -p 122 admin@replica-host
  3. Verify the upgrade by running:

    $ ghe-version
  4. On the replica instance, to start replication, run ghe-repl-start.

  5. On the replica instance, to make sure replication services are running correctly, run ghe-repl-status. This command will return OK for all services when a successful replication is in progress and the replica has upgraded. コマンドが Replication is not running を返すなら、レプリケーションはまだ開始中かもしれません。 ghe-repl-status をもう一度実行する前に 1 分間ほど待ってください。

    メモ: resync の処理が進んでいる間は、ghe-repl-status はレプリケーションが遅れていることを示す期待どおりのメッセージを返すかもしれません。 たとえば CRITICAL: git replication is behind the primary by more than 1007 repositories and/or gists のようなメッセージです。

    ghe-repl-statusOK を返さない場合は、以下の手順に従って手動でレプリケーションを開始してください。

    1. レプリカインスタンスで再度 ghe-repl-setup <primary-instance-ip> を実行してください。

    2. On the replica instance, to start replication, run ghe-repl-start.

    3. On the replica instance, to make sure replication services are running correctly, run ghe-repl-status. This command will return OK for all services when a successful replication is in progress and the replica has upgraded.

  6. 最後のレプリカのアップグレードが完了し、resync も完了したなら、ユーザが GitHub Enterprise Server インスタンス を使えるようにメンテナンスモードを無効化してください。

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

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

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

パッチリリースをロールバックするには、--allow-patch-rollback を付けて ghe-upgrade コマンドを使います。 アップグレードをロールバックする場合には、.pkg拡張子を持つアップグレードパッケージを使わなければなりません。 .hpkg拡張子を持つホットパッチのパッケージファイルはサポートされません。

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

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

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

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

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

担当者にお尋ねください

探しているものが見つからなかったでしょうか?

弊社にお問い合わせください