AWS EC2で実行されているいくつかのdockerコンテナーを取得しました。/var/lib/docker/overlay2フォルダーは、ディスクサイズが非常に速く成長します。
そのコンテンツを削除しても安全かどうか疑問に思っていますか?または、dockerにディスク使用量を解放するための何らかのコマンドがある場合。
ありがとう!
更新:
実際にdocker system Prune -a
を試してみましたが、0Kbを回収しました。
また、私の/ docker/overlay2ディスクサイズはdocker system df
からの出力よりもはるかに大きい
DockerのドキュメントとBMitchの答えを読んだ後、このフォルダに触れるのは馬鹿げた考えだと思うので、他の方法でディスク領域を再利用してみます。
Dockerは/ var/lib/dockerを使用して、イメージ、コンテナー、ローカルの名前付きボリュームを保存します。これを削除すると、データが失われ、エンジンの実行が停止する可能性があります。 overlay2サブディレクトリには、具体的にはイメージとコンテナのさまざまな ファイルシステムレイヤー が含まれています。
未使用のコンテナとイメージをクリーンアップするには、docker system Prune
を参照してください。ボリュームやタグ付き画像を削除するオプションもありますが、データ損失の可能性があるため、デフォルトでは有効になっていません。
overlay2
の急成長にも問題がありました
/var/lib/docker/overlay2
-dockerがコンテナーの書き込み可能なレイヤーを保存するフォルダーです。 docker system Prune -a
-コンテナが停止および削除された場合にのみ機能します。
私はoverlay2
に入って調査することで、スペースを消費しているものを把握することができました。
そのフォルダーには、foldersという名前の他のハッシュが含まれています。これらのそれぞれには、diff
フォルダーを含むいくつかのフォルダーがあります。
diff
フォルダー-コンテナーとして正確なフォルダー構造を持つコンテナーによって書き込まれた実際の違いが含まれます(少なくとも私の場合は-Ubuntu 18 ...)
つまり、du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmp
を使用して、コンテナ内の/tmp
が汚染されたフォルダーであることがわかりました。
回避策として、-v /tmp/container-data/tmp:/tmp
コマンドにdocker run
パラメーターを使用して、内部/tmp
フォルダーをホストにマップし、ホスト上のcronをセットアップしてそのフォルダーをクリーンアップしました。
cronタスクは簡単でした:
Sudo nano /etc/crontab
*/30 * * * * root rm -rf /tmp/container-data/tmp/*
save and exit
注:overlay2
はシステムドッカーフォルダーであり、いつでも構造を変更できます。上記のすべては、私がそこで見たものに基づいています。システムが完全にスペース不足であり、Dockerコンテナにsshすることさえできないので、dockerフォルダ構造に入れなければなりませんでした。
私はこの問題を抱えていました...それは巨大なログでした。ログはこちらです:
/var/lib/docker/containers/<container id>/<container id>-json.log
これは、コマンドラインの実行または構成ファイルで管理できます。参照: ロギングドライバーの設定
私はこれら3行をdocker-compose.ymlファイルに個人的に追加しました:
my_container:
logging:
options:
max-size: 10m
私はこれが私にとって最も効果的であることがわかりました:
docker image Prune --all
デフォルトでは、Dockerは、使用されていない名前の画像も削除しません。このコマンドは、未使用のイメージを削除します。
画像の各レイヤーは、/usr/lib/docker/overlay2/
フォルダー内のフォルダーです。