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

Explore by product

Enterprise Server 2.14
日本語 (Japanese)
記事のバージョン： Enterprise Server 2.14
Enterprise Server 2.17 Enterprise Server 2.16 Enterprise Server 2.15 Enterprise Server 2.14

このバージョンの GitHub Enterprise はこの日付をもって終了となります: このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2019-07-12. 重大なセキュリティ上の問題があっても、パッチはリリースされなくなります。優れたパフォーマンス、改善されたセキュリティ、そして新しい機能のために、GitHub Enterprise の最新バージョンにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise Support に連絡してください。

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

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

このガイドの内容

アップグレードの準備

  1. アップグレードの戦略を決定し、アップグレード先のバージョンを選択してください。 For more information, see "Upgrade requirements."

  2. If you're upgrading to GitHub Enterprise Server 2.14 or 2.15 from 2.12 or 2.13, download and run a migration script to migrate your search or webhook indices to Elasticsearch 5.6. For more information, see "Migrating Elasticsearch indices to GitHub Enterprise Server 2.14 or later."

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

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

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

スナップショットの取得

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

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

プラットフォーム スナップショットの取得方法 スナップショットドキュメンテーションの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

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

ホットパッチを利用すれば、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. 任意のページの右上の隅で をクリックしてください。

    サイト管理設定にアクセスするための Rockership アイコン

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

    左サイドバーの Management Console タブ

Management Console の上部で、[Updates（更新）] をクリックしてください。 更新 メニューアイテム

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

    • すぐにインストールするならNow（即時）を選択してください。
    • 後でインストールするなら、後の日付を選択してください。
      ホットパッチインストール日のドロップダウン
  2. [Install] をクリックします。
    ホットパッチインストールボタン
管理シェルを使ったホットパッチのインストール

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

  1. GitHub Enterprise Server インスタンス に SSH します。

    $ ssh -p 122 admin@HOSTNAME

  2. GitHub Enterprise Server リリースページ にアクセスし、アップグレード先のリリースの右隣にある [Download] をクリックし、[Upgrading] タブをクリックします。アップグレードのホットパッケージ（.hpkgファイル）のURLをコピーしてください。

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

    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. レプリカのインスタンスに SSH 経由で "admin" ユーザとして 122 番ポートに接続します:

    $ ssh -p 122 admin@replica-host

  3. 以下を実行してアップグレードを検証します:

$ ghe-version

ホットパッチのインストールの取り消し

ホットパッチのインストールで何か問題や予想外の動作が生じた場合、以前のバージョンの通常のアップグレードパッケージ (.pkg) を ghe-upgrade コマンドを使ってインストールできます。

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

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

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

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

  1. GitHub Enterprise Server インスタンス に SSH します。

    $ ssh -p 122 admin@HOSTNAME

  2. GitHub Enterprise Server リリースページ にアクセスし、アップグレード先のリリースの右隣にある [Download] をクリックし、[Upgrading] タブをクリックします。 適切なプラットフォームを選択し、アップグレードパッケージ (.pkgファイル) の URL をコピーしてください。

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

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

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

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

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

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

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

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

  2. レプリカのインスタンスに SSH 経由で "admin" ユーザとして 122 番ポートに接続します:

    $ ssh -p 122 admin@replica-host

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

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

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

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

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

  2. レプリカのインスタンスに SSH 経由で "admin" ユーザとして 122 番ポートに接続します:

    $ ssh -p 122 admin@replica-host

  3. 以下を実行してアップグレードを検証します:

$ ghe-version

  1. レプリカのインスタンス上で ghe-repl-start を実行してレプリケーションを開始します。

  2. レプリカインスタンス上でアプリケーションサービスが正しく動作していることを確認するには 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 を返さない場合は、以下の手順に従って手動でレプリケーションを開始してください。

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

    1. レプリカのインスタンス上で ghe-repl-start を実行してレプリケーションを開始します。

    2. レプリカインスタンス上でアプリケーションサービスが正しく動作していることを確認するには ghe-repl-status を実行してください。このコマンドは、レプリケーションが正しく動作中であり、レプリカがアップグレードされていればすべてのサービスに対して OK を返します。

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

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

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

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

パッチリリースをロールバックするには ghe-upgrade --allow-patch-rollback コマンドを使ってください。パッチリリースでは移行の処理は実行されないので、ロールバックによってデータパーティションが影響を受けることはありません。 詳細は「コマンドラインユーティリティ」を参照してください。

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

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

担当者にお尋ねください

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

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

製品

プラットフォーム

サポート

会社