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

製品で調べる

Enterprise administrators
  • Get started
  • Account and profile
  • Authentication
  • Repositories
  • GitHub
  • Enterprise administrators
  • Billing and payments
  • Organizations
  • Code security
  • GitHub Issues
  • GitHub Actions
  • GitHub Codespaces
  • GitHub Packages
  • Search on GitHub
  • Developers
  • REST API
  • GraphQL API
  • GitHub CLI
  • GitHub Discussions
  • GitHub Sponsors
  • Building communities
  • GitHub Pages
  • Education
  • GitHub Desktop
  • Atom
  • Electron
  • CodeQL
  • npm
    • 日本語
  • English
  • 简体中文 (Simplified Chinese)
  • 日本語 (Japanese)
  • Español (Spanish)
  • Português do Brasil (Portuguese)

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

    Article version

    ここには以下の内容があります:

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

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

    アップグレードの準備

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

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

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

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

    GitHub Enterprise Server 3.0 以降の最小要件について

    GitHub Enterprise Server 3.0 以降にアップグレードする前に、インスタンスにプロビジョニングしたハードウェアリソースを確認してください。 GitHub Enterprise Server 3.0 は、GitHub Actions や GitHub Packages などの新機能を導入しているため、バージョン 2.22 以前よりも多くのリソースが必要となります。 詳しい情報については、GitHub Enterprise Server 3.0 のリリースノートを参照してください。

    次の表では、GitHub Enterprise Server 3.0 以降の要件の増加を太字で示しています。

    ユーザライセンスvCPUsメモリアタッチされたストレージルートストレージ
    トライアル、デモ、あるいは10人の軽量ユーザ4
    2 から増加    		32 GB
    16 GB から増加    		150 GB
    100 GB から増加    		200 GB
    10-30008
    4 から増加    		48 GB
    32 GB から増加    		300 GB
    250 GB から増加    		200 GB
    3000-500012
    8 から増加    		64 GB500 GB200 GB
    5000-800016
    12 から増加    		96 GB750 GB200 GB
    8000-10000+20
    16 から増加    		160 GB
    128 GB から増加    		1000 GB200 GB

    GitHub Actionsのハードウェアの要件に関する詳しい情報については「GitHub Enterprise ServerでGitHub Actionsを利用しはじめる」を参照してください。

    既存のインスタンスのリソース調整に関する詳しい情報については「ストレージ容量の増加」及び「CPUあるいはメモリリソースの増加」を参照してください。

    スナップショットの取得

    スナップショットは、ある時点での仮想マシン（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://docs.citrix.com/en-us/xencenter/current-release/vms-snapshots.html

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

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

    Note:

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

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

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

    1. 自動アップデートを有効化してください。 詳しい情報については「自動アップデートの有効化」を参照してください。
    2. GitHub Enterprise Serverの管理アカウントから、任意のページの右上にあるをクリックしてください。 サイトアドミン設定にアクセスするための宇宙船のアイコン
    3. 左のサイドバーでManagement Consoleをクリックしてください。 左のサイドバーのManagement Consoleタブ
    4. Management Consoleの上部でUpdates（アップデート）をクリックしてください。 アップデートメニューアイテム
    5. 新しいホットパッチがダウンロードされたなら、Install package（パッケージのインストール）ドロップダウンメニューを使ってください。
      • すぐにインストールするならNow（即時）を選択してください。
      • 後でインストールするなら、後の日付を選択してください。 ホットパッチインストール日のドロップダウン
    6. [Install] をクリックします。 ホットパッチインストールボタン

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

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

    1. GitHub Enterprise ServerのインスタンスにSSHでアクセスしてください。 詳しい情報については「管理シェル（SSH）にアクセスする」を参照してください。 
      $ 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. ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してください。

      $ ssh -p 122 admin@replica-host

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

      $ ghe-version

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

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

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

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

    1. GitHub Enterprise ServerのインスタンスにSSHでアクセスしてください。 詳しい情報については「管理シェル（SSH）にアクセスする」を参照してください。

      $ 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-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. ポート122のSSH経由でレプリカインスタンスに"admin"ユーザとして接続してください。 
      $ ssh -p 122 admin@replica-host
    3. レプリカインスタンス、あるいは Geo-replication の一部として複数のレプリカインスタンスを動作させている場合は、すべてのレプリカインスタンスで ghe-repl-stop を実行してレプリケーションを停止させます。
    4. 「アップグレードパッケージで単一アプライアンスをアップグレードする」の指示に従い、プライマリインスタンスをアップグレードしてください。

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

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

    1. 「アップグレードパッケージで単一アプライアンスをアップグレードする」の指示に従い、レプリカインスタンスをアップグレードします。 Geo-replication に複数のレプリカを使用している場合は、この手順を繰り返して、各レプリカを一度に 1 つずつアップグレードする必要があります。

    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 も完了したなら、ユーザが GitHub Enterprise Serverのインスタンス を使えるようにメンテナンスモードを無効化してください。

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

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

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

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

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

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

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

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

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

    問題がまだ解決していませんか？

    GitHubコミュニティで質問する