新しいシステム リソースを割り当てるプロセスは、仮想化プラットフォームとリソースの種類によって異なります。 重要なシステムリソースのモニタリングとアラートは、必ず設定しておいてください。 詳しくは、「インスタンスを監視する」を参照してください。
お使いの GitHub Enterprise Server インスタンス に参加するユーザーが増えるにつれて、ストレージ ボリュームのサイズを変更する必要があるかもしれません。 ストレージのリサイズに関する情報については、使用している仮想化プラットフォームのドキュメンテーションを参照してください。
要件と推奨事項
注: ストレージ ボリュームのサイズを変更する前に、インスタンスをメンテナンス モードにします。指定した IP アドレスからのアクセスを許可するように IP 例外リストを構成することで、変更を検証できます。 詳しくは、「メンテナンスモードの有効化とスケジューリング」をご覧ください。
最小要件
| ユーザー ライセンス | x86-64 vCPUs | メモリ | ルート ストレージ | アタッチされた (データ) ストレージ | 
|---|---|---|---|---|
| トライアル、デモ、あるいは10人の軽量ユーザ | 4 | 32 GB | 200 GB | 150 GB | 
| 10-3000 | 8 | 48 GB | 200 GB | 300 GB | 
| 3000-5000 | 12 | 64 GB | 200 GB | 500 GB | 
| 5000-8000 | 16 | 96 GB | 200 GB | 750 GB | 
| 8000-10000+ | 20 | 160 GB | 200 GB | 1000 GB | 
ルート ストレージとは、インスタンスのルート ディスクの合計サイズを指します。 ルート ファイルシステムで利用可能な領域は、ルート ディスクで利用可能なストレージの合計の 50% です。 詳しくは、「システムの概要」を参照してください。
データパーティションサイズの増加
- 
仮想化プラットフォームのツールを使用して、既存のユーザーボリュームのディスクのサイズを変更します。
 - 
お使いの GitHub Enterprise Server インスタンス に SSH で接続します。 インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。 詳しくは、「管理シェル (SSH) にアクセスする」を参照してください。
Shell ssh -p 122 admin@HOSTNAME
ssh -p 122 admin@HOSTNAME - 
アプライアンスをメンテナンスモードにしてください。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。
 - 
アプライアンスを再起動して、新しいストレージ割り当てを検出します。
sudo reboot - 
ghe-storage-extendコマンドを実行して、/data/userファイル システムを拡張します。ghe-storage-extend - 
システム サービスが正しく機能していることを確認してから、メンテナンス モードを終了します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。
 
新しいアプライアンスを使用したルートパーティションサイズの増加
- 
現在のアプライアンスと同じバージョンを使用して、より大きなルートディスクで新たな GitHub Enterprise Server をセットアップします。 詳しくは、「GitHub Enterprise Server インスタンスをセットアップする」を参照してください。
 - 
現在のアプライアンスをシャットダウンします。
sudo poweroff - 
使用している仮想化プラットフォームのツールを使い、現在のアプライアンスからデータディスクをデタッチします。
 - 
大きなルートディスクを持つ新しいアプライアンスにデータディスクをアタッチします。
 
既存のアプライアンスを使用したルートパーティションサイズの増加
警告: ルート パーティション サイズを拡張するには、インスタンスをメンテナンス モードにする必要があります。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。
- 
GitHub Enterprise Server アプライアンスに新しいディスクを取り付けます。
 - 
新しいディスクのデバイス名を確認するには、
lsblkコマンドを実行します。 - 
ディスクをフォーマットするには、
partedコマンドを実行します。/dev/xvdgを自分のデバイス名に置き換えます。sudo parted /dev/xvdg mklabel msdos sudo parted /dev/xvdg mkpart primary ext4 0% 50% sudo parted /dev/xvdg mkpart primary ext4 50% 100% - 
アプライアンスが高可用性または geo レプリケーション用に構成されている場合、レプリケーションを停止するには、各レプリカ ノード上で
ghe-repl-stopコマンドを実行します。ghe-repl-stop - 
新しくパーティション分割されたディスクに GitHub Enterprise Server ソフトウェアをインストールするには、
ghe-upgradeコマンドを実行します。 PACKAGE-NAME.pkg は、アプライアンスで既に実行されている GitHub Enterprise Server のバージョンと一致するプラットフォーム固有のアップグレード パッケージへのパスに置き換える必要があります。github-enterprise-2.11.9.hpkgなどのユニバーサル ホットパッチ アップグレード パッケージを使用することはできません。ghe-upgradeコマンドが完了すると、アプリケーション サービスは自動的に終了します。ghe-upgrade PACKAGE-NAME.pkg -s -t /dev/xvdg1 - 
アプライアンスをシャットダウンします。
sudo poweroff - 
ハイパーバイザーで、古いルートディスクを取り外し、古いルートディスクと同じ場所に新しいルートディスクを取り付けます。
 - 
アプライアンスを起動します。
 - 
システム サービスが正しく機能していることを確認してから、メンテナンス モードを終了します。 詳しくは、「メンテナンスモードの有効化とスケジューリング」を参照してください。
 
アプライアンスが高可用性または geo レプリケーション用に構成されている場合は、すべてのノードのストレージがアップグレードされた後で、ghe-repl-start を使用して各レプリカ ノードでレプリケーションを開始してください。