新しいシステム リソースを割り当てるプロセスは、仮想化プラットフォームとリソースの種類によって異なります。 重要なシステムリソースのモニタリングとアラートは、必ず設定しておいてください。 詳しくは、「インスタンスを監視する」を参照してください。
お使いの 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
を使用して各レプリカ ノードでレプリケーションを開始してください。