はじめに
Capistorano を使った自動デプロイの実装中、
”bundle exec cap production deploy”を実行すると悲惨なエラーが起こりました。
一瞬、「不能」が「無能」に見えて心が折れそうでした。
（中略）
ar: vendor: mkdir 不能: No space left on device
DEBUG [7d5bfec5] tar: vendor/bundle/ruby/2.6.0/gems/websocket-extensions-0.1.5/README.md: open 不能: No such file or directory
tar: vendor: mkdir 不能: No space left on device
tar: vendor/bundle/ruby/2.6.0/gems/websocket-extensions-0.1.5/lib: mkdir 不能: No such file or directory
tar: vendor: mkdir 不能: No space left on device
tar: vendor/bundle/ruby/2.6.0/gems/websocket-extensions-0.1.5/lib/websocket: mkdir 不能: No such file or directory
tar: vendor: mkdir 不能: No space left on device
DEBUG [7d5bfec5] tar: vendor/bundle/ruby/2.6.0/gems/websocket-extensions-0.1.5/lib/websocket/extensions.rb: open 不能: No such file or directory
tar: vendor: mkdir 不能: No space left on device
tar: vendor/bundle/ruby/2.6.0/gems/websocket-extensions-0.1.5/lib/websocket/extensions: mkdir 不能: No such file or directory
tar: vendor: mkdir 不能: No space left on device
（中略）
「No space left on device」 とある通り、インスタンスのストレージの問題なんだろうなぁ、、、と思っていましたがそうでした。
対応をまとめたので是非参考に。
チェック
本当にボリュームがいっぱいか、確認していきます。
インスタンスに接続してEC2サーバーで以下のコマンドを実行します。
lsblk コマンドはボリュームに拡張が必要なパーティションがあるかどうかを確認します。
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 8G 0 disk
└─xvda1 202:1 0 8G 0 part /
インスタンスにアタッチされているブロックデバイスに関する情報を表示されています。
ルートボリュームxvda にはパーティション /dev/xvda1 が存在し、初期設定通り８GBサイズであることが確認できます。
df -h コマンドは各ボリュームのファイルシステムのサイズを確認します。
$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 482M 0 482M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 412K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 8.0G 8.0G 0 100% /
tmpfs 99M 0 99M 0% /run/user/1001
/dev/xvda1 の使用率が100％で拡張の必要性があることが分かります。
いくつかの記事を見た限り、100％でなくても80％を超えると挙動が重たくなったりエラーが発生したり、拡張の必要があることもあるようです。
ボリューム変更
AWS Linux インスタンス用ユーザーガイド EBSボリュームへの変更のリクエストを参考に、AWSのEC2マネジメントコンソールからボリューム変更します。
パーティションの拡張
再度、 lsblkコマンドで増加したボリュームサイズがパーティションに反映されていることを確認します。
（反映には時間がかかることもあるそうですが、私は1分程度で反映されていました。）
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk
└─xvda1 202:1 0 8G 0 part /
ルートボリュームxvda には変更時点で自動的に新しいサイズ (16 GB) が反映されますが、パーティションxvda1には元のサイズ (8 GB) が反映されるため、ファイルシステムを拡張する前に拡張する必要があります。
lsblk -f コマンドでマウントポイントに関する詳細情報も確認できます。
$ lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
xvda
└─xvda1 xfs / 55ee5a5f-d155-47e0-9121-e6f4522cb2bf /
xvda1 がXFSタイプのファイルであることが分かります。
「No space left on a block device (ブロックデバイスに空きスペースがありません)」エラーを回避するには、一時ファイルシステムである tmpfs を /tmp マウントポイントにマウントします。これにより、10 M の tmpfs が /tmp にマウントされます。
$ sudo mount -o size=10M,rw,nodev,nosuid -t tmpfs tmpfs /tmp
growpart コマンドを実行して、ルートパーティション(xvda1)のサイズを拡大します。/dev/xvda 1 をルートパーティションに置き換えます。
※ "xvda 1"にスペースが含まれることに注意。
$ sudo growpart /dev/xvda 1
CHANGED: partition=1 start=4096 old: size=16773087 end=16777183 new: size=33550303 end=33554399
lsblk コマンドを実行して、パーティションが16GiBに拡張されていることを確認します。
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 16G 0 disk
└─xvda1 202:1 0 16G 0 part /
次に、ファイルシステムを展開します。ルートパーティション「/」のファイルシステムを確認します。
以下では、XFSタイプのファイルシステムが展開されています。
$ sudo xfs_growfs -d /
meta-data=/dev/xvda1 isize=512 agcount=4, agsize=524159 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1 spinodes=0
data = bsize=4096 blocks=2096635, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 2096635 to 4193787
最後にdf -h コマンドを使用して追加したスペースがOS上で表示されることを確認します。
$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 482M 0 482M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 412K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 16G 8.0G 8.0G 51% /
tmpfs 99M 0 99M 0% /run/user/1001
tmpfs 10M 0 10M 0% /tmp
[kanji@ip-10-0-0-36 ~]$ sudo umount /tmp
[kanji@ip-10-0-0-36 ~]$ df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 482M 0 482M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 412K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 16G 8.0G 8.0G 51% /
tmpfs 99M 0 99M 0% /run/user/1001
unmount コマンドを実行して、tmpfs ファイルシステムをアンマウントします。
$ sudo umount /tmp
以上でエラーが解決します。
参考文献
・AWS ボリュームサイズ変更後の Linux ファイルシステムの拡張
・AWS ファイルシステムに空きスペースがないというエラーが表示された際に、EBS ボリュームのサイズを増やすにはどうすればよいですか?
puts 'I hope my article helps you.'