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

製品で調べる

Enterprise Administrators
日本語 (Japanese)

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2020-11-12. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてください。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してください。

記事のバージョン： Enterprise Server 2.19
Enterprise Server 2.22 Enterprise Server 2.21 Enterprise Server 2.20 Enterprise Server 2.19
記事のバージョン： Enterprise Server 2.19
Enterprise Server 2.22 Enterprise Server 2.21 Enterprise Server 2.20 Enterprise Server 2.19

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/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
AzureVMhttps://docs.microsoft.com/azure/backup/backup-azure-vms-first-look-arm
Hyper-VVMhttps://docs.microsoft.com/windows-server/virtualization/hyper-v/manage/enable-or-disable-checkpoints-in-hyper-v
Google Compute Engineディスクhttps://cloud.google.com/compute/docs/disks/create-snapshots
VMwareVMhttps://pubs.vmware.com/vsphere-50/topic/com.vmware.wssdk.pg.doc_50/PG_Ch11_VM_Manage.13.3.html
XenServerVMhttps://support.citrix.com/article/CTX122978

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

GitHub Enterprise Serverは、ホットパッチを利用して最新のパッチリリースへアップグレードできます。ホットパッチにはメンテナンスウィンドウが不要で、通常は再起動も必要ありません。 ホットパッチは新しいパッチリリースへのアップグレードに利用できますが、新しいフィーチャリリースへのアップグレードには利用できません。 たとえば2.10.1から2.10.5へのアップグレードは同じフィーチャリリースなので可能ですが、2.10.9から2.11.0へは異なるフィーチャリリースなので行えません。Management Console を使うと、ホットパッチを即座にインストールすることや、後にインストールするようにスケジュールすることができます。 管理シェルを使って ghe-upgrade ユーティリティでホットパッチをインストールすることもできます。 詳細は「アップグレードの要求事項」を参照してください。

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

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

Management Console を使ってホットパッチをインストールする
  1. 自動アップデートを有効化してください。 詳しい情報については「自動アップデートの有効化」を参照してください。
  2. From an administrative account on GitHub Enterprise Server, click in the upper-right corner of any page.
    サイトアドミン設定にアクセスするための宇宙船のアイコン
  3. 左のサイドバーでManagement Consoleをクリックしてください。
    左のサイドバーのManagement Consoleタブ
  4. Management Consoleの上部でUpdates（アップデート）をクリックしてください。
    アップデートメニューアイテム
  5. 新しいホットパッチがダウンロードされたなら、Install package（パッケージのインストール）ドロップダウンメニューを使ってください。
    • すぐにインストールするならNow（即時）を選択してください。
    • 後でインストールするなら、後の日付を選択してください。
      ホットパッチインストール日のドロップダウン
  6. Click Install.
    ホットパッチインストールボタン
管理シェルを使ったホットパッチのインストール

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

  1. your GitHub Enterprise Server instanceにSSHでアクセスしてください。
    $ ssh -p 122 admin@HOSTNAME
  2. GitHub Enterprise Serverのリリースページにアクセスしてください。 アップグレードしたいリリースの隣の Download（ダウンロード）をクリックし、続いて Upgrading（アップグレード）タブをクリックしてください。アップグレードのホットパッケージ（.hpkgファイル）のURLをコピーしてください。
  3. cURLを使ってyour GitHub Enterprise Server instanceにアップグレードパッケージをダウンロードしてください。
    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. Upgrade the replica instance by following the instructions in "Installing a hotpatch using the administrative shell." If you are using multiple replicas for Geo-replication, you must repeat this procedure to upgrade each replica one at a time.

  2. ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してください。

    $ ssh -p 122 admin@replica-host

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

    $ ghe-version

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

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

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

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

  1. your GitHub Enterprise Server instanceにSSHでアクセスしてください。

    $ ssh -p 122 admin@HOSTNAME

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

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

    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-number
Current root partition: /dev/xvda1 [version-number]
Target root partition:  /dev/xvda2
Proceed with installation? [y/N]

  7. 単一アプライアンスのアップグレードであれば、メンテナンスモードを無効化してユーザが your GitHub Enterprise Server instance を利用できるようにしてください。

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

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

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

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

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

  1. プライマリインスタンスでメンテナンスモードを有効化し、すべてのアクティブなプロセスが完了するのを待ちます。 詳しい情報については、「メンテナンスモードの有効化」を参照してください。
  2. ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してください。
    $ ssh -p 122 admin@replica-host
  3. レプリカインスタンス、あるいは Geo-replication の一部として複数のレプリカインスタンスを動作させている場合は、すべてのレプリカインスタンスで ghe-repl-stop を実行してレプリケーションを停止させます。
  4. 「アップグレードパッケージで単一アプライアンスをアップグレードする」の指示に従い、プライマリインスタンスをアップグレードしてください。
レプリカインスタンスのアップグレード

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

  1. Upgrade the replica instance by following the instructions in "Upgrading a single appliance with an upgrade package." If you are using multiple replicas for Geo-replication, you must repeat this procedure to upgrade each replica one at a time.

  2. ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してください。

    $ ssh -p 122 admin@replica-host

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

    $ ghe-version

  4. レプリカインスタンス上でレプリケーションを開始するには、ghe-repl-startを実行してください。

  5. レプリカインスタンスで、レプリケーションサービスが正しく動作していることを確認するには、ghe-repl-statusを実行してください。 このコマンドは、レプリケーションが問題なく進行しており、レプリカがアップグレードされていれば、すべてのサービスに対してOKを返します。 コマンドが 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-status が OK を返さない場合は、以下の手順に従って手動でレプリケーションを開始してください。

    1. レプリカインスタンスで再度 ghe-repl-setup <primary-instance-ip> を実行してください。
    2. レプリカインスタンス上でレプリケーションを開始するには、ghe-repl-startを実行してください。
    3. レプリカインスタンスで、レプリケーションサービスが正しく動作していることを確認するには、ghe-repl-statusを実行してください。 このコマンドは、レプリケーションが問題なく進行しており、レプリカがアップグレードされていれば、すべてのサービスに対してOKを返します。

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

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

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

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

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

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

A reboot is required after running the command. パッチリリースでは移行は行われないので、ロールバックはデータパーティションには影響しません。

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

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

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

Still need help?

Ask the GitHub community サポートへの連絡