docker / overlay2 /をクリーンアップしても安全ですか

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。ボリュームやタグ付き画像を削除するオプションもありますが、データが失われる可能性があるため、デフォルトでは有効になっていません。

私はこれが私にとって最もうまくいったことを発見しました：

docker image prune --all

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

画像内の各レイヤーは、フォルダー内の/usr/lib/docker/overlay2/フォルダーであることに注意してください。

私はこの問題を抱えていました...それは巨大なログでした。ログはここにあります：

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

これは、実行コマンドラインまたは作成ファイルで管理できます。そこを参照してください：ロギングドライバーを構成します

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

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

急速に成長することにも問題がありました overlay2

/var/lib/docker/overlay2--dockerがコンテナーの書き込み可能なレイヤーを格納するフォルダーです。 docker system prune -a-コンテナが停止して削除された場合にのみ機能する可能性があります。

私の中で、私はoverlay2調査して、何がスペースを消費するのかを理解することができました。

そのフォルダーには、フォルダーという名前の他のハッシュが含まれています。それらのそれぞれには、フォルダを含むいくつかのフォルダがあり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フォルダーであり、いつでも構造を変更できます。上記のすべては、私がそこで見たものに基づいています。システムが完全にスペース不足であり、DockerコンテナーにSSHで接続することさえできないという理由だけで、Dockerフォルダー構造に入る必要がありました。

バックグラウド

この問題の原因は、コンテナボリュームの設定ミスと、これらのボリュームに書き込まれた一時データのDockerリーク（リリースの失敗）の問題に分けられます。アプリが頻繁におよび/または大量に書き込むコンテナの一時/ログ/スクラッチフォルダのすべてを（ホストフォルダまたは他の永続的なストレージクレームのいずれかに）マッピングする必要があります。Dockerは、デフォルトでにある、自動的に作成されたいわゆるEmptyDirのすべてのクリーンアップについて責任を負いません/var/lib/docker/overlay2/*/diff/*。これらの「非永続的」フォルダーの内容は、コンテナーが停止した後、dockerによって自動的にパージされる必要がありますが、明らかにそうではありません（コンテナーがまだ実行されている場合は、ホスト側からパージすることさえ不可能な場合があります。また、数か月間実行される可能性があります。一度に）。

回避策

回避策には注意深い手動クリーンアップが必要です。すでに他の場所で説明されていますが、私のケーススタディからいくつかのヒントが見つかる場合があります。これは、可能な限り有益で一般化できるようにしようとしました。

何が起こったのかというと、犯人のアプリ（私の場合clair-scanner）は、数か月にわたって数百ギガのデータを/diff/tmpdocker'sのサブフォルダーに書き込むことができました。overlay2

du -sch /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp

271G total

のすべてのサブフォルダー/diff/tmpはかなり自明だったので（すべてが形式でclair-scanner-*あり、廃止された作成日がありました）、関連するコンテナー（docker stop clair）を停止し、これらの廃止されたサブフォルダーをから慎重に削除diff/tmpしました。 Dockerエンジンへの影響のテスト（systemctl restart dockerディスクスペースを再利用するために再起動[ ]が必要でした）：

rm -rf $(ls -at /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp | grep clair-scanner | tail -1)

Dockerを再インストールしたり、フォルダー全体を削除したりすることなく、数百ギガのディスクスペースを再利用しました。ディスクスペースを再利用するにはdockerデーモンの再起動が必要だったため、実行中のすべてのコンテナーを一度に停止する必要がありました。最初に、フェイルオーバーコンテナーが他のノードで正しく実行されていることを確認してください。docker pruneコマンドが（さらに別のスイッチを介し/diff/tmpて/diff/*）廃止された（または）データもカバーできることを願っています。

これは現在3年前の問題であり、Dockerフォーラムでその豊かでカラフルな歴史を読むことができます。ここでは、上記のソリューションのアプリケーションログを対象としたバリアントが2019年に提案され、いくつかのセットアップで機能したようです：https：// forums.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604

警告：本番システムでは使用しないでください

/# df
...
/dev/xvda1      51467016 39384516   9886300  80% /
...

では、最初にシステムプルーンを試してみましょう

#/ docker system prune --volumes
...
/# df
...
/dev/xvda1      51467016 38613596  10657220  79% /
...

それほど大きくはありませんが、数メガバイトをクリーンアップしたようです。今、夢中になりましょう：

/# sudo su
/# service docker stop
/# cd /var/lib/docker
/var/lib/docker# rm -rf *
/# service docker start
/var/lib/docker# df
...
/dev/xvda1      51467016 8086924  41183892  17% /
...

いいね！これは使い捨てサーバー以外では推奨されないことを覚えておいてください。この時点で、Dockerの内部データベースはこれらのオーバーレイを見つけることができず、意図しない結果を引き起こす可能性があります。

これを本番環境で実行しないでください

@ ravi-luthraによる回答は技術的には機能しますが、いくつかの問題があります。

私の場合、ディスク容量を回復しようとしていました。このlib/docker/overlayフォルダーは30GBのスペースを使用しており、定期的に実行するコンテナーはごくわずかです。dockerにはデータ漏洩の問題があり、コンテナーが停止したときに一時データの一部がクリアされないようです。

そこで、先に進んでlib/docker/overlayフォルダの内容をすべて削除しました。その後、私のdockerインスタンスは使用できなくなりました。コンテナを実行またはビルドしようとすると、次のエラーが発生しました。

failed to create rwlayer: symlink ../04578d9f8e428b693174c6eb9a80111c907724cc22129761ce14a4c8cb4f1d7c/diff /var/lib/docker/overlay2/l/C3F33OLORAASNIYB3ZDATH2HJ7: no such file or directory

その後、試行錯誤しながら、実行してこの問題を解決しました

（警告：これにより、Dockerボリューム内のすべてのデータが削除されます）

docker system prune --volumes -a

したがって、システムの動作を完全に理解していない限り、このようなダーティクリーンアップを実行することはお勧めしません。

/ var / lib / docker内のすべては、コンテナーのファイルシステムです。すべてのコンテナを停止して整理すると、フォルダが空になってしまうはずです。あなたはおそらくそれを本当に望んでいないので、そこにあるものをランダムに削除しないでください。 / var / lib / docker内のものを直接削除しないでください。 あなたは時々それで逃げるかもしれません、しかしそれは非常に多くの理由でお勧めできません。

代わりにこれを行ってください：

sudo bash
cd /var/lib/docker
find . -type f | xargs du -b  | sort -n

表示されるのは、下部に表示されている最大のファイルです。必要に応じて、それらのファイルがどのコンテナーにあるかを把握し、それらのコンテナーを入力して、docker exec -ti containername -- /bin/shいくつかのファイルを削除します。

あなたも置くことができますdocker system prune -a -fあなたはあなたの周りが気にすることを止め、容器とボリュームを残していない限り、毎日/毎週のcronジョブに。それが成長している理由を理解し、コンテナレベルでそれらを修正することをお勧めします。

最近、同様の問題が発生しました。overlay2はどんどん大きくなりましたが、スペースの大部分を何が消費しているかがわかりませんでした。

df overlay2のサイズが約24GBであることを示しました。

du私はスペースを占領し...そして失敗したかを把握することを試みました。

違いは、プロセス（Docker）によってまだ使用されているファイル（私の場合は主にログファイル）が削除されたという事実にあります。したがって、ファイルはで表示されませんが、ファイルがdu占めるスペースはで表示されdfます。

ホストマシンの再起動が役に立ちました。dockerコンテナーを再起動すると、おそらくすでに役立つでしょう… linuxquestions.orgのこの記事は、私がそれを理解するのに役立ちました。

上記のコメントに加えて、クリアなぶら下がりボリューム、画像、出口コンテナなどのシステムを整理することを提案しています。アプリが原因になると、短時間で大量のログが生成され、空のダイレクトボリューム（ローカルボリューム）を使用している場合）これは/ varパーティションを埋めます。その場合、以下のコマンドは、/ varパーティションディスクのスペースを何が消費しているかを理解するのに非常に興味深いことがわかりました。

du -ahx / var / lib | 並べ替え-rh | 頭-n30

このコマンドは、単一のディスク上のほとんどのスペースを消費している上位30をリストします。コンテナで外部ストレージを使用している場合、duコマンドの実行に多くの時間がかかることを意味します。このコマンドはマウントボリュームをカウントしません。そして、はるかに高速です。スペースを消費している正確なディレクトリ/ファイルを取得します。次に、それらのディレクトリに移動して、どのファイルが有用かどうかを確認できます。これらのファイルが必要な場合は、アプリを変更してその場所に永続ストレージを使用するか、そのファイルの場所を変更することで、ファイルを永続ストレージに移動できます。そして残りのためにあなたはそれらをクリアすることができます。

「dockersystemprune -a」を使用して、ボリュームとoverlay2の下のすべてのファイルをクリーンアップしました

    [root@jasontest volumes]# docker system prune -a
    WARNING! This will remove:
            - all stopped containers
            - all networks not used by at least one container
            - all images without at least one container associated to them
            - all build cache
    Are you sure you want to continue? [y/N] y
    Deleted Images:
    untagged: ubuntu:12.04
    untagged: ubuntu@sha256:18305429afa14ea462f810146ba44d4363ae76e4c8dfc38288cf73aa07485005
    deleted: sha256:5b117edd0b767986092e9f721ba2364951b0a271f53f1f41aff9dd1861c2d4fe
    deleted: sha256:8c7f3d7534c80107e3a4155989c3be30b431624c61973d142822b12b0001ece8
    deleted: sha256:969d5a4e73ab4e4b89222136eeef2b09e711653b38266ef99d4e7a1f6ea984f4
    deleted: sha256:871522beabc173098da87018264cf3e63481628c5080bd728b90f268793d9840
    deleted: sha256:f13e8e542cae571644e2f4af25668fadfe094c0854176a725ebf4fdec7dae981
    deleted: sha256:58bcc73dcf4050a4955916a0dcb7e5f9c331bf547d31e22052f1b5fa16cf63f8
    untagged: osixia/openldap:1.2.1
    untagged: osixia/openldap@sha256:6ceb347feb37d421fcabd80f73e3dc6578022d59220cab717172ea69c38582ec
    deleted: sha256:a562f6fd60c7ef2adbea30d6271af8058c859804b2f36c270055344739c06d64
    deleted: sha256:90efa8a88d923fb1723bea8f1082d4741b588f7fbcf3359f38e8583efa53827d
    deleted: sha256:8d77930b93c88d2cdfdab0880f3f0b6b8be191c23b04c61fa1a6960cbeef3fe6
    deleted: sha256:dd9f76264bf3efd36f11c6231a0e1801c80d6b4ca698cd6fa2ff66dbd44c3683
    deleted: sha256:00efc4fb5e8a8e3ce0cb0047e4c697646c88b68388221a6bd7aa697529267554
    deleted: sha256:e64e6259fd63679a3b9ac25728f250c3afe49dbe457a1a80550b7f1ccf68458a
    deleted: sha256:da7d34d626d2758a01afe816a9434e85dffbafbd96eb04b62ec69029dae9665d
    deleted: sha256:b132dace06fa7e22346de5ca1ae0c2bf9acfb49fe9dbec4290a127b80380fe5a
    deleted: sha256:d626a8ad97a1f9c1f2c4db3814751ada64f60aed927764a3f994fcd88363b659
    untagged: centos:centos7
    untagged: centos@sha256:2671f7a3eea36ce43609e9fe7435ade83094291055f1c96d9d1d1d7c0b986a5d
    deleted: sha256:ff426288ea903fcf8d91aca97460c613348f7a27195606b45f19ae91776ca23d
    deleted: sha256:e15afa4858b655f8a5da4c4a41e05b908229f6fab8543434db79207478511ff7

    Total reclaimed space: 533.3MB
    [root@jasontest volumes]# ls -alth
    total 32K
    -rw-------  1 root root  32K May 23 21:14 metadata.db
    drwx------  2 root root 4.0K May 23 21:14 .
    drwx--x--x 14 root root 4.0K May 21 20:26 ..