2つのコンテナー(両方とも独自の名前付きボリュームを持つJenkinsとNexus)を備えたdocker環境があります。未使用のコンテナとイメージを削除するcronジョブが毎日あります。これは正常に機能しています。しかし、問題は私のデバイスマッパー内にあります:
du -sh /var/lib/docker/
30G docker/
Dockerフォルダー内の各フォルダー:Volumes(大きいが、私の場合はそれが正常です):
/var/lib/docker# du -sh volumes/
14G volumes/
コンテナ:
/var/lib/docker# du -sh containers/
3.2M containers/
画像:
/var/lib/docker# du -sh image/
5.8M image/
デバイスマッパー:
/var/lib/docker# du -sh devicemapper/
16G devicemapper/
/var/lib/docker/devicemapper/mnt
は7.3G /var/lib/docker/devicemapper/devicemapper
は8.1G
Docker情報:
Storage Driver: devicemapper
Pool Name: docker-202:1-xxx-pool
Pool Blocksize: 65.54 kB
Base Device Size: 10.74 GB
Backing Filesystem: ext4
Data file: /dev/loop0
Metadata file: /dev/loop1
Data Space Used: 5.377 GB
Data Space Total: 107.4 GB
Data Space Available: 28.8 GB
Metadata Space Used: 6.148 MB
Metadata Space Total: 2.147 GB
Metadata Space Available: 2.141 GB
Udev Sync Supported: true
このスペースとは何ですか?また、物を壊さずにこれをきれいにできますか?
重大なこと にはdevicemapperループファイルを使用しないでください! Dockerにはこれについて大きな警告があります。
/var/lib/docker/devicemapper/devicemapper
ディレクトリには、dockerがマウントするすべてのデータを含むスパースループファイルが含まれます。そのため、lvmツールを使用してそれらを探し回って物事を行う必要があります。ただし、devicemapperの削除の問題 を削除してください .
可能な場合はdevicemapper
から離れるか、RHELベースのすべてでLVMシンプールを使用します。ストレージドライバーを変更できない場合、同じ手順で、少なくとも再利用できない割り当てられたスパーススペースはすべて消去されます。
ストレージドライバを変更するには、すべてのdockerデータを含む/var/lib/docker
ディレクトリをダンプする必要があります。その一部を保存する方法はありますが、それにはDocker内部をいじる必要があります。保持するコンテナまたはボリュームをコミットおよびエクスポートし、変更後にそれらをインポートすることをお勧めします。そうしないと、Dockerが新しく空の状態でインストールされます。
データのエクスポート
Dockerを停止する
/var/lib/docker
を削除
新しいストレージドライバーを使用するように、Dockerスタートアップを変更します。 --storage-driver=<name>
または/lib/systemd/system/docker.service
または/etc/systemd/system/docker.service
または/etc/default/docker
で/etc/sysconfig/docker
を設定します
Dockerを起動します
データをインポートする
AUFSはメインラインカーネルに含まれていません(今後もそうなることはありません)。これは、ディストリビューションが何らかの形で積極的にそれを含める必要があることを意味します。 Ubuntuの場合は、linux-image-extra
パッケージに含まれています。
apt-get install linux-image-extra-$(uname -r) linux-image-extra-virtual
次に、ストレージドライバオプションを--storage-driver=aufs
に変更します
OverlayFSはすでにUbuntuで利用可能です。まだ3.xカーネルを使用している場合は、ストレージドライバーを--storage-driver=overlay2
または--storage-driver=overlay
に変更するだけです
これが今どれほど良いアイデアなのかはわかりません。ループファイルよりも悪くなることはありませんが、 overlay2
ドライバーは、開発者が使用するのに非常に安定していますが、まだ製品の準備が整っているとは見なされません(たとえば、Docker Enterpriseはサポートを提供しません)。
Devicemapperループファイルの代わりに、LVMシンプールを直接使用できます。 RHELは、EPELドッカーパッケージで配布されている docker-storage-setup
ユーティリティを使用してこれを簡単にします。 Dockerには、ボリュームを手動で設定するための詳細な手順があります 。
--storage-driver=devicemapper \
--storage-opt=dm.thinpooldev=/dev/mapper/docker-thinpool \
--storage-opt dm.use_deferred_removal=true
Docker 17.06+は、 シンプルなdirect-lvm
ブロックデバイスセットアップの管理をサポートしています
LVMボリュームのスペースが不足しないようにしてください。終了する必要があるDockerデーモンが応答しなくなり、その後、クリーンアップが困難なLVMリソースがまだ使用されています。
まず、 devicemapperとは ( 公式ドキュメント )
Device Mapperは、バージョン2.6.9以降、メインラインLinuxカーネルに含まれています。これは、RHELファミリーのLinuxディストリビューションの中核部分です。
Devicemapperドライバーは、すべてのイメージとコンテナーを独自の仮想デバイスに保存します。これらのデバイスは、シンプロビジョニングされたコピーオンライトスナップショットデバイスです。
Device Mapperテクノロジーは、ファイルレベルではなくブロックレベルで機能します。つまり、devicemapperストレージドライバーのシンプロビジョニングおよびコピーオンライト操作は、ファイル全体ではなくブロックで機能します。Devicemapperは、一部のLinuxディストリビューションのデフォルトのDockerストレージドライバーです。
Devicemapperストレージドライバーを実行するDockerホストは、デフォルトでloop-lvmと呼ばれる構成モードになります。このモードでは、スパースファイルを使用して、イメージとコンテナーのスナップショットで使用されるシンプールを構築します
Docker 1.10以降では、イメージレイヤーIDと/ var/lib/docker内のディレクトリ名が一致しなくなりました。
ただし、2つの重要なディレクトリがあります。
/var/lib/docker/devicemapper/mnt
ディレクトリには、イメージおよびコンテナレイヤーのマウントポイントが含まれます。- / var/lib/docker/devicemapper/metadataディレクトリには、イメージレイヤーとコンテナースナップショットごとに1つのファイルが含まれています。
docker info
がStorage Driver
がdevicemapper
である(aufs
ではない)と表示されている場合は、これらのフォルダーを慎重に処理してください。
たとえば issue 18867 を参照してください。
定期的なdocker system Prune -a
は、LVMシンプールではなくdevicemapperを使用するシステムで機能します。私が使用するパターンは次のとおりです。
protected
」でコンテナ、画像などにラベルを付けますdocker system Prune -a --filter=label!=protected
を実行します(手動またはcronで-fを使用)ラベルの例:
docker run --label protected ...
docker create --label=protected=true ...
LABEL protected=true
一般的なDocker ラベルドキュメント
/ var/lib/docker/devicemapper/devicemapper/dataファイルでルートボリュームの〜91%(50Gの45G)に達する同じ問題に直面しました。不要な画像をすべて削除し、ボリュームを削除しようとしましたが、このファイルを減らすのに何も役立ちませんでした。
いくつかのグーグルを行い、「データ」ファイルはループバックマウントされたスパースファイルであり、Dockerはそれを使用して、コンテナ内に保存するマウント位置やその他のファイルを保存することを理解しました。
最後に、前に実行して停止したすべてのイメージを削除しました
これにより、devicemapperファイルが大幅に削減されました。これがあなたの役に立つことを願っています。