SEワンタンの独学備忘録

IT関連の独学した内容や資格試験に対する取り組みの備忘録

【Docker】Dockerがサーバ容量をひっ迫している（初心者向け）

Docker Linux 独学 エラー対応

Dockerの勉強をしていたら遭遇した。エラーエラーで本流の方が進まない！！！
業務で使用するような人にはすでに理解してほしいような内容ですが、勉強中の場合はハマる可能性もあると思います。

発生エラー

まずはコンテナの起動ができなくなった。さっきまではできていたはずなのに・・

docker run -p 28001:27017 --name devmongo -d mongo mongod --auth
 docker container ls -a

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f937676552c2 mongo "docker-entrypoint.s…" 16 seconds ago Exited (100) 15 seconds ago devmongo

立ち上がってない。エラーコード100で検索してもめぼしい情報はあまりでてこなかった。

ひとまずログを確認してみる。

docker logs devmongo

2020-04-11T09:58:34.947+0000 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2020-04-11T09:58:34.949+0000 W ASIO [main] No TransportLayer configured during NetworkInterface startup
2020-04-11T09:58:34.949+0000 I CONTROL [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=f937676552c2
2020-04-11T09:58:34.949+0000 I CONTROL [initandlisten] db version v4.2.5
2020-04-11T09:58:34.949+0000 I CONTROL [initandlisten] git version: 2261279b51ea13df08ae708ff278f0679c59dc32
2020-04-11T09:58:34.949+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.1.1 11 Sep 2018
2020-04-11T09:58:34.949+0000 I CONTROL [initandlisten] allocator: tcmalloc
2020-04-11T09:58:34.949+0000 I CONTROL [initandlisten] modules: none
2020-04-11T09:58:34.949+0000 I CONTROL [initandlisten] build environment:
2020-04-11T09:58:34.949+0000 I CONTROL [initandlisten] distmod: ubuntu1804
2020-04-11T09:58:34.949+0000 I CONTROL [initandlisten] distarch: x86_64
2020-04-11T09:58:34.949+0000 I CONTROL [initandlisten] target_arch: x86_64
2020-04-11T09:58:34.950+0000 I CONTROL [initandlisten] options: { net: { bindIp: "*" }, security: { authorization: "enabled" } }
2020-04-11T09:58:34.950+0000 I STORAGE [initandlisten]
2020-04-11T09:58:34.950+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2020-04-11T09:58:34.950+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2020-04-11T09:58:34.950+0000 I STORAGE [initandlisten] error creating journal dir /data/db/journal boost::filesystem::create_directory: No space left on device: "/data/db/journal"
2020-04-11T09:58:34.951+0000 I STORAGE [initandlisten] exception in initAndListen std::exception: boost::filesystem::create_directory: No space left on device: "/data/db/journal", terminating
2020-04-11T09:58:34.951+0000 I NETWORK [initandlisten] shutdown: going to close listening sockets...
2020-04-11T09:58:34.951+0000 I - [initandlisten] Stopping further Flow Control ticket acquisitions.
2020-04-11T09:58:34.951+0000 I CONTROL [initandlisten] now exiting
2020-04-11T09:58:34.951+0000 I CONTROL [initandlisten] shutting down with code:100

冷静に振り返ってみると以下のあたりでなんとなく原因がわかってしまいそうですが、コンテナやイメージの設定、ネットワークなどいろいろ疑いをかけました。サーバを再起動したりしても効果なし。

error creating journal dir /data/db/journal boost::filesystem::create_directory: No space left on device: "/data/db/journal"

イメージやコンテナに固有の原因がある？？と思って
取得、コンテナ化の実績があるCentOSで試してみる。

docker image pull centos

すると失敗。

Using default tag: latest
latest: Pulling from library/centos
8a29a15cefae: Extracting 73.23MB/73.23MB
failed to register layer: Error processing tar file(exit status 1): write /usr/bin/dwp: no space left on device

さすがにもっと根本的な問題があるのでは？という方に考えをシフトして「no space left on device」をキーワードに調べ始めました。
次章に続きます。

状態確認と原因

容量の確認

まずはEC2サーバ（Linux）の容量を確認しました。

df -h

Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 7.9G 7.8G 0 100% /

明らかに容量がヤバそうですが、詳細が分からないので実際に何が容量をくっているの確認します。

sudo du -x -h / | sort -r -h | head -40

7.7G /
5.6G /var
5.5G /var/lib/docker
5.5G /var/lib
5.1G /var/lib/docker/volumes
1.5G /usr
437M /home/ec2-user

Dockerのボリュームが5.1Gも使ってる？？

5.1G /var/lib/docker/volumes

対応

以下のディレクトリは何に使われているのでしょうか。

 /var/lib/docker/volumes

どうも生成したコンテナのボリュームを格納しているみたいです。
コンテナはこのボリュームをマウントして使用している感じですね。

また、このボリュームはデータの永続化のためにコンテナが削除されたあとも残っているようです。
コンテナが削除された後も復旧できるようにという配慮のためでしょうね。


ここまでの話でなんとなく予想がつきますが、学習用途でいろいろと試しているうちにコンテナの生成と削除を繰り返したため、削除したコンテナのボリュームが残ってしまっていると考えられます。

暫定対応

やることはコンテナに紐づいていないボリュームを削除することです。
※削除したコンテナの復旧ができなくなるため実施は自己責任です。まぁ検証で使用しているような場合には気軽に実施しても問題はないと思いますが

docker volume ls -qf dangling=true | xargs -r docker volume rm

実行すると削除したコンテナIDがばーっとでてきます。

実行後、容量を確認してみます。

df -h

・出力結果

Filesystem Size Used Avail Use% Mounted on
devtmpfs 483M 60K 483M 1% /dev
tmpfs 493M 0 493M 0% /dev/shm
/dev/xvda1 7.9G 2.7G 5.1G 35% /


おお、めっちゃ減ってますね
Docker関連の容量も併せて確認しておきます。

sudo du -x -h / | sort -r -h | grep "docker" | head -20

・出力結果の抜粋

385M /var/lib/docker
384M /var/lib/docker/overlay2
291M /var/lib/docker/overlay2/f27c6f269a852b481f257d864aa1c5015d79e9eaad53a4a877c7c3ef2b8c24ab/diff

うむ、常識的な範囲になったと思います。

予防策・恒久対応

定期的に上記を実行すればなんとかはなります。
しかし、原因は削除したコンテナの不要なボリュームが残っていることなのでそこを対応します。

起動前のボリュームディレクトリを確認。

drwxr-xr-x 3 root root 4096 Apr 11 09:58 35470d28b72e69afc6e17e629638d96e456344eebf6e91d508a0f98d7f8e09aa
drwxr-xr-x 3 root root 4096 Apr 11 09:58 aac7c759af538f579e01caf8c3ce66ee807f7253932a96e86768966b3edb5079

  • rw------- 1 root root 65536 Apr 11 13:02 metadata.db


とりあえず復旧確認もかねてコンテナを起動生成。
もちろんコンテナ自体はなんでもいいです。

docker run -p 28001:27017 --name devmongo -d mongo mongod --auth

起動生成によってボリュームが追加されていることが確認できます。

drwxr-xr-x 3 root root 4096 Apr 11 09:58 35470d28b72e69afc6e17e629638d96e456344eebf6e91d508a0f98d7f8e09aa
drwxr-xr-x 3 root root 4096 Apr 11 13:25 76254d45ce3d5b8ee33d202915c08e9df3685896aef3ea7b9e0fd329f0dc1413
drwxr-xr-x 3 root root 4096 Apr 11 09:58 aac7c759af538f579e01caf8c3ce66ee807f7253932a96e86768966b3edb5079
drwxr-xr-x 3 root root 4096 Apr 11 13:25 b70279734cb4dbf3ab888aea17009c2bbfbb14c0986380d3925737cead1d6d08

  • rw------- 1 root root 65536 Apr 11 13:25 metadata.db

コンテナを停止後、削除します。
そしてここが対応策で、削除の際に関連ボリュームも削除するために「-v」オプションを付与します。

docker container rm -v devmongo


ボリュームを確認します。

drwxr-xr-x 3 root root 4096 Apr 11 09:58 35470d28b72e69afc6e17e629638d96e456344eebf6e91d508a0f98d7f8e09aa
drwxr-xr-x 3 root root 4096 Apr 11 09:58 aac7c759af538f579e01caf8c3ce66ee807f7253932a96e86768966b3edb5079

  • rw------- 1 root root 65536 Apr 11 13:33 metadata.db

確かに削除されています。
なので今後は削除の際に-vオプションを付与することとします。

その他メモ

コンテナ削除時のボリュームの削除は起動時に「-rm」オプションを付与することでも対応可能。
但し、起動時「-d」オプションと共存できなきため一律で削除の「-v」オプションで対応することにした。

コンテナのボリューム確認は以下のvolumeコマンドでも確認可能。

docker volume ls

DRIVER VOLUME NAME
local 35470d28b72e69afc6e17e629638d96e456344eebf6e91d508a0f98d7f8e09aa
local aac7c759af538f579e01caf8c3ce66ee807f7253932a96e86768966b3edb5079

ただコマンド確認しているだけだと使いどころがわからないコマンドもこうゆうことがあると使い方もわかってきますね。


ーーーーー
ひとまずは大丈夫そうなので、やっと勉強再開できます。
しかし個人環境だとあまりぼかすかコンテナをたてるのも考え物ですね。