🐙

Check! GitHub Enterprise Server on Azure でストレージ容量を拡張する

2022/11/05に公開約6,200字

Prologue

こんにちは、@dz_ こと、岩永かづみです。

検証の GitHub Enterprise Server のアップデートを行ったら、見慣れない「Preflight check」が実施され、残念ながらハードウェア(仮想マシン)の最小要件を満たしておらず、ストレージの拡張を要求されたままアップデートを完了できない事態になったので、対応しました。

おさらい: GitHub Enterprise Server(GHES) について

GitHub は、エンタープライズ向けに GitHub Enterprise を提供しています。GitHub Enterprise では、エンタープライズグレードのユーザー管理や監査に対応でき、複数の Organization を横断的で管理したり、Advanced Security によりプライベートリポジトリのセキュリティ機能を強化することができます。GitHub Enterprise は、クラウド版またはサーバーインストール版の形態で提供されており、クラウド版 GitHub Enterprise Cloud は普段利用している GitHub.com 上で利用できます。これに対し、GitHub Enterprise Server(GHES) は、サーバーにインストールして利用するもので、オンプレミスまたは Microsoft Azure や AWS、 GCP などのクラウド環境での構築が想定されています。

GHES アップグレード時の Preflight check

October 25, 2022 の 3.2 ~ 3.6 に対するパッチ対応で、アップグレードを正常に完了できるようにと preflight check が導入されたようです。利用している仮想マシンが最小ハードウェア要件を満たしているかチェックしてくれる機能です。安心ですね!

To ensure that site administrators can successfully complete an upgrade, the instance will now execute a preflight check to ensure that the virtual machine meets minimum hardware requirements. The check also verifies Elasticsearch's health. You can review the current requirements for CPU, memory, and storage for GitHub Enterprise Server in the "Minimum requirements" section within each article in "Setting up a GitHub Enterprise Server instance."

詳しくは、Release notes - GitHub Enterprise Server 3.4 DocsChanges をご確認ください。

今回の事象: Preflight check でストレージ要件が満たされていないことが発覚

さて今回は、Preflight check のおかげで基盤の仮想マシンのストレージ要件が満たされていないことがわかりました。

下記のように表示され、私の状況では少なくとも 145GB のストレージ領域が必要だそうです。

Block device capacity
145GB of block device capacity required. 127GB available.
Can be used as a node in a cluster (0.75GB of block device capacity required).

Block device capacity is not satisfied in Preflight checks

状況確認

まず、上記の画面の最中、バージョンはどういう状態になっていたかというと、アップデート対象の 3.4.10 になっていました。

ghe-version
GitHub Enterprise Server 3.4.10 azure 2022-10-20 cedc9c7d2c

次に、仮想マシンのストレージ状況を確認しています。この検証環境は、Installing GitHub Enterprise Server on Azure - GitHub Enterprise Server 3.4 Docs をベースに構築したもので、ストレージは下記の構成になっていました。

元のディスクサイズの状況

用途 サイズ 補足
OS disk 200 GiB 要件に従ったサイズ
Data disk 128 GiB 要件は 150GB だが、価格帯の閾値が 128 GiB のためケチっていました😇

仮想マシン Debian からみたストレージ状況も確認しておきます。どうやら、Data disk に割り当てられている /data/user が足りないようです。

lsblk
NAME                                 MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
fd0                                    2:0    1    4K  0 disk
sda                                    8:0    0  200G  0 disk
├─sda1                                 8:1    0  100G  0 part
└─sda2                                 8:2    0  100G  0 part /
sdb                                    8:16   0  128G  0 disk
└─ghe_storage_8b718e84-ghe_user_data 254:0    0  128G  0 lvm  /data/user
sdc                                    8:32   0   64G  0 disk
└─sdc1                                 8:33   0   64G  0 part /mnt/resource

対処

ストレージ容量を増やすために、Increasing storage capacity - GitHub Enterprise Server 3.4 Docs を確認すると、 /data/user を拡張するコマンド ghe-storage-extend が紹介されているので、これに従って作業してみます。作業手順は下記です。

  1. 必要に応じて、メンテナンスモードに変更する( ghe-maintenance -s
  2. 仮想マシンのディスクサイズを更新する
  3. ディスクサイズの更新を読み込むために OS をリブートする
  4. SSH 接続し、ghe-storage-extend を実行する
  5. リブートし、アップデートを完了させる
  6. 必要に応じて、メンテナンスモードを解除する( ghe-maintenance -u

ghe-maintenance については、Command-line utilities - GitHub Enterprise Server 3.4 Docs をご参照ください。

ディスクサイズの拡張は、Azure ポータルや Azure CLI から操作できます。ここでは、要件通り 150 GiB に増やしました。ディスクサイズの拡張について、詳細は Linux VM の仮想ハード ディスクを拡張する - Azure Virtual Machines | Microsoft Learn をご確認ください。

ghe-storage-extend を実行するとこのようになりました。

ghe-storage-extend
fsck from util-linux 2.33.1
[/usr/sbin/fsck.ext4 (1) -- /data/user] fsck.ext4 -n /dev/mapper/ghe_storage_8b718e84-ghe_user_data
e2fsck 1.44.5 (15-Dec-2018)
Warning!  /dev/mapper/ghe_storage_8b718e84-ghe_user_data is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
ghe_user_data: clean, 712869/8388608 files, 8128916/33553408 blocks
Growing physical volume from <128.00g to 150.00g...
  Physical volume "/dev/sdb" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
Growing logical volume from <128.00g to 150.00g...
  Size of logical volume ghe_storage_8b718e84/ghe_user_data changed from <128.00 GiB (32767 extents) to <150.00 GiB (38399 extents).
  Logical volume ghe_storage_8b718e84/ghe_user_data successfully resized.
  1 logical volume(s) in volume group "ghe_storage_8b718e84" now active
  Reading all physical volumes.  This may take a while...
  Found volume group "ghe_storage_8b718e84" using metadata type lvm2
Growing filesystem...
resize2fs 1.44.5 (15-Dec-2018)
Filesystem at /dev/ghe_storage_8b718e84/ghe_user_data is mounted on /data/user; on-line resizing required
old_desc_blocks = 16, new_desc_blocks = 19
The filesystem on /dev/ghe_storage_8b718e84/ghe_user_data is now 39320576 (4k) blocks long.

Success: ghe_storage_8b718e84 is 150.00g

このあと、おそらく自動ではアップデートが進まないように見えたので、リブートなど(GHES は立ち上がりが遅くしばらく画面が変わらない間に焦ったので、停止/起動まで行いました)を行いアップデートを完了させました。

無事にアップデートできました!🎉

Epilogue

ということで、アップデート中に異なる画面が出るとちょっと焦ってしまいますよね。そんなときに情報があると不安が減るので、記事にしたためてみました。ご参考になれば幸いです。

また、GitHub Enterprise の場合は、スタンダードサポートを(契約していればプレミアムサポートも)利用できるのでそちらで問い合わせも可能ですし、わたしが所属している ZEN Architects でも GitHub の技術サポートを行っておりますので、ご相談いただけましたら全力でサポートいたします。よろしくお願いいたします💪

Discussion

ログインするとコメントできます