web-dev-qa-db-ja.com

docker / overlay2 /をクリーニングしても安全ですか?

AWS EC2で実行されているいくつかのdockerコンテナーを取得しました。/var/lib/docker/overlay2フォルダーは、ディスクサイズが非常に速く成長します。

そのコンテンツを削除しても安全かどうか疑問に思っていますか?または、dockerにディスク使用量を解放するための何らかのコマンドがある場合。

ありがとう!


更新:

実際にdocker system Prune -aを試してみましたが、0Kbを回収しました。

また、私の/ docker/overlay2ディスクサイズはdocker system dfからの出力よりもはるかに大きい

DockerのドキュメントとBMitchの答えを読んだ後、このフォルダに触れるのは馬鹿げた考えだと思うので、他の方法でディスク領域を再利用してみます。

36
qichao_he

Dockerは/ var/lib/dockerを使用して、イメージ、コンテナー、ローカルの名前付きボリュームを保存します。これを削除すると、データが失われ、エンジンの実行が停止する可能性があります。 overlay2サブディレクトリには、具体的にはイメージとコンテナのさまざまな ファイルシステムレイヤー が含まれています。

未使用のコンテナとイメージをクリーンアップするには、docker system Pruneを参照してください。ボリュームやタグ付き画像を削除するオプションもありますが、データ損失の可能性があるため、デフォルトでは有効になっていません。

21
BMitch

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フォルダ構造に入れなければなりませんでした。

4
user2932688

私はこの問題を抱えていました...それは巨大なログでした。ログはこちらです:

/var/lib/docker/containers/<container id>/<container id>-json.log

これは、コマンドラインの実行または構成ファイルで管理できます。参照: ロギングドライバーの設定

私はこれら3行をdocker-compose.ymlファイルに個人的に追加しました:

my_container:
  logging:
    options:
      max-size: 10m
4
Tristan

私はこれが私にとって最も効果的であることがわかりました:

docker image Prune --all

デフォルトでは、Dockerは、使用されていない名前の画像も削除しません。このコマンドは、未使用のイメージを削除します。

画像の各レイヤーは、/usr/lib/docker/overlay2/フォルダー内のフォルダーです。

2
Sarke