Dockerスペースがいっぱいでコンテナに入れない場合の解決策

トラブル発生が突然で、業務も迫っていたため、現場のスクリーンショットを撮る時間がありませんでしたので、現場のスクリーンショットは後ほど通常時のものになります。

月曜日に出勤し、いつものようにサーバーにログインし、dockerコンテナに入ります

>>> docker exec -i -t xxx /bin/bash
Docker エラー: デバイスに空き容量がありません

スペースがありませんか？

すぐにシステムスペースを確認することを考えました。

>>> df -h

ファイルシステムサイズ 使用済み 使用可能使用率 マウント先
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 984K 3.9G 1% /実行
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/vda1 50G 50G 0G 100% /
オーバーレイ 50G 5.9G 41G 13% /var/lib/docker/overlay2/4d0941b78fa413f3b77111735e06045b41351748bcea7964205bcfbf9d4ec0b6/マージ済み
オーバーレイ 50G 5.9G 41G 13% /var/lib/docker/overlay2/54a7a7b66d9c12d7e42158d177a6b67321f7da1f223b301e838e9bc109a2bda4/マージ済み
shm 64M 0 64M 0% /var/lib/docker/containers/712f65baea85d898f6c948e7149f84f2f5eaf3b1934540603f32ab278f9acec4/mounts/shm
shm 64M 0 64M 0% /var/lib/docker/containers/a5fa673086c8f46ba98fc4425b353ed2e12de3277a5fe2dc5b8b7affa63b4518/マウント/shm
オーバーレイ 50G 5.9G 41G 13% /var/lib/docker/overlay2/7fbbc8a29119a1eaa1f212c50b75405a1f16fd68e3ae3949cc0c963d0727a9ab/マージ済み
shm 64M 0 64M 0% /var/lib/docker/containers/011a83deceacecbacb4ef7eb06eb5b812babf9e83914a4fb33d4925cc1ad375b/マウント/shm
tmpfs 783M 0 783M 0% /run/user/0

ルートディレクトリがいっぱいになっていることが判明

さらに詳しく

>>> cd /
>>> du -h --max-depth=1

984K ./run
16K ./opt
13M ./ルート
4.0K ./メディア
du: './proc/4382/task/4382/fd/4' にアクセスできません: そのようなファイルまたはディレクトリはありません
du: './proc/4382/task/4382/fdinfo/4' にアクセスできません: そのようなファイルまたはディレクトリはありません
du: './proc/4382/fd/3' にアクセスできません: そのようなファイルまたはディレクトリはありません
du: './proc/4382/fdinfo/3' にアクセスできません: そのようなファイルまたはディレクトリはありません
0 ./proc
204M ./ブート
12K ./redis
39M ./その他
16K ./紛失+発見
4.0K ./srv
0 ./sys
47G ./var
2.8G ./usr
4.0K ./月
36K ./tmp
0 ./dev
4.0K ./ホーム
50G 。

>>> cd var
>>> du -h --max-depth=1

116M ./キャッシュ
8.0K ./空
4.0K ./ゲーム
4.0K ./opt
24K ./db
46G ./lib
4.0K ./ゴーファー
4.0K ./adm
4.0K ./クラッシュ
12K ./ケルベロス
4.0K ./保存
4.0K ./nis
16K ./tmp
4.0K ./年
4.0K ./ローカル
104K ./スプール
374M ./ログ
47G .

>>> CDライブラリ
>>> du -h --max-depth=1

76K ./systemd
24K ./ネットワークマネージャ
4.0K ./調整済み
4.0K ./ゲーム
248K ./クラウド
215M ./rpm
8.0K ./プリマス
46G ./docker
248K ./コンテナ
4.0K ./dbus
4.0K ./initramfs
4.0K ./os-prober
8.0K ./rsyslog
24K ./代替案
8.0K ./authconfig
12K ./ステートレス
4.0K ./その他
4.0K ./ntp
8.0K ./dhclient
4.0K ./selinux
8.0K ./chrony
4.0K ./rpm-状態
12M ./yum
8.0K ./ポストフィックス
28K ./polkit-1
4.0K ./マシン
8.0K ./logrotate
46G .

>>> ドッカーを起動
>>> du -h --max-depth=1

84K ./ネットワーク
108K ./ビルドキット
4.0K ./信頼
4.0K ./ランタイム
5.7M ./画像
42G ./巻
24K ./プラグイン
4.0K ./tmp
20K ./ビルダー
180K ./コンテナ
3.3G ./オーバーレイ2
4.0K ./スウォーム
46G .

>>> CD ボリューム
>>> du -h --max-depth=1

172K ./kudu_to_jdy_kudu_to_jdy
42G ./jdy_extensions_logs
748K ./bot_etl_bot_etl
42G .

jdy_extensions_logs ボリュームがいっぱいであることが判明し、コードのバグを発見しました。

追記:

実際、Dockerはコンテナイメージを管理するための多くのコマンドを提供しており、その中でもdocker system dfはより便利なコマンドです。

# docker ファイルシステムの使用状況を表示します >>> docker system df

タイプ 合計 アクティブサイズ 再利用可能
画像 7 3 2.146GB 693.2MB (32%)
コンテナ 3 3 127.5kB 0B (0%)
ローカルボリューム 3 3 1.511MB 0B (0%)
キャッシュを構築 0 0 0B 0B

# スペース使用量を表示 >>> docker system df -v

画像のスペース使用量:
リポジトリ タグ イメージ ID 作成サイズ 共有サイズ 固有サイズ コンテナ
jdy_extension 1.7 e3be3be9664a 15時間前 627.6MB 73.86MB 553.7MB 1
<なし> <なし> 4b5825747ae9 19時間前 74.02MB 73.86MB 158.8kB 0
redis 6.2.1 f877e80bb9ef 2週間前 105.3MB 0B 105.3MB 0
kudu_to_jdy 2.9 888b72288bca 2週間前 538.1MB 73.86MB 464.3MB 1
jdy_to_db 1.9 c345c4e15c1a 7か月前 587.7MB 73.86MB 513.9MB 0
bot_etl 2.3 020d41691ec7 7か月前 508.6MB 73.86MB 434.8MB 1
ubuntu 20.04 adafef2e596e 8か月前 73.86MB 73.86MB 0B 0
コンテナのスペース使用量:
コンテナID イメージ コマンド ローカルボリューム サイズ 作成 ステータス 名前
011a83deceac jdy_extension:1.7 "supervisord -n -c /…" 1 17.8kB 15 時間前 15 時間前 jdy_extension_1.7
712f65baea85 kudu_to_jdy:2.9 "supervisord -n -c /…" 1 36.9kB 2 週間前 45 時間前 kudu_to_jdy_2.9
a5fa673086c8 bot_etl:2.3 "supervisord -n -c /…" 1 72.8kB 7 か月前 45 時間前 bot_etl_2.3
ローカルボリュームのスペース使用量:
ボリューム名 リンク サイズ
jdy_extensions_logs 1 658.5kB
クドゥ_to_jdy_クドゥ_to_jdy 1 128kB
bot_etl_bot_etl 1 724kB
ビルドキャッシュ使用量: 0B
キャッシュID キャッシュタイプ サイズ 作成日 最終使用日 使用状況 共有

# 未使用のボリュームをすべて削除
>>> docker ボリューム rm $(docker ボリューム ls -q)

補足：dockerディスクが100%占有するケースを記録する

git pull origin master を実行すると、次のエラーがスローされます。

エラー: RPC に失敗しました。HTTP 500 curl 22 要求された URL がエラーを返しました: 500
致命的: リモート側が予期せず切断されました

Baidu で検索したところ、nginx のファイルサイズ制限が原因だという意見が多かったのですが、設定ファイルを確認したところ、サイズ制限は 500M に設定されていたので、この理由によるものではないはずです。

サーバ
{
  聞く 80;
  server_name ローカルホスト;
  クライアントの最大ボディサイズは500Mです。
  位置 / {
    proxy_redirect オフ;
    proxy_set_header ホスト $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://localhost:180;
  }
}

次に、df -h を使用してディスクの状態を確認し、data2 ディスクが 100% いっぱいであることを確認します (docker はここに保存されます)。

docker system prune -a を使用すると、多くのスペースが解放され、問題は解決しました。

注: 上記のコマンドを使用すると、次のコンテンツが削除されます。

警告! これにより以下が削除されます:
    - 停止したコンテナすべて
    - 少なくとも 1 つのコンテナで使用されていないすべてのネットワーク
    - 少なくとも 1 つのコンテナが関連付けられていないすべてのイメージ
    -すべてのビルドキャッシュ
本当に続行しますか? [y/N] y

上記は私の個人的な経験です。参考になれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。間違いや不備な点がありましたら、遠慮なくご指摘ください。

以下もご興味があるかもしれません: