Dockerエラー：デバイスにスペースが残っていません

次の方法でDebian 7マシンにdockerをインストールしました

$ echo deb http://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list
$ sudo apt-get update
$ curl -sSL https://get.docker.com/ubuntu/ | sudo sh

その後、私が最初に画像を作成しようとしたときに、次のエラーで失敗しました

 time="2015-06-02T14:26:37-04:00" level=info msg="[8] System error: write /sys/fs/cgroup/docker/01f5670fbee1f6687f58f3a943b1e1bdaec2630197fa4da1b19cc3db7e3d3883/cgroup.procs: no space left on device"

これがドッカー情報です

Containers: 2
Images: 21
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 25
Dirperm1 Supported: true
Execution Driver: native-0.2
Kernel Version: 3.16.0-0.bpo.4-amd64
Operating System: Debian GNU/Linux 7 (wheezy)
CPUs: 2
 Total Memory: 15.7 GiB


WARNING: No memory limit support
 WARNING: No swap limit support

どうすればメモリを増やすことができますか？システム構成はどこに保存されますか？

カルの提案から：

すべてのイメージとコンテナを削除すると、一部のスペースが解放され、同じエラーで失敗する前にイメージのビルドに時間がかかりました。だから問題は、これはどのスペースを指しているのか、そしてどのようにそれを構成するのですか？

私は同じエラーがあり、それをこのように解決しました：

１。Dockerで孤立したボリュームを削除します。組み込みのdocker volumeコマンドを使用できます。組み込みコマンドは、ボリュームではない/ var / lib / docker / volumes内のディレクトリも削除するため、そこに保存したいものが何もないことを確認してください。

保持したいデータがある場合は、警告に注意してください。

掃除：

$ docker volume rm $(docker volume ls -qf dangling=true)

追加コマンド：

ダングリングボリュームのリスト：

$ docker volume ls -qf dangling=true

すべてのボリュームを一覧表示します。

$ docker volume ls

２。未使用の画像をすべて削除することも検討してください。

最初に<none>画像を削除します（画像の作成中に画像が生成されることがあり、何らかの理由で画像の作成が中断された場合、画像はそのまま残ります）。

ここに私がそれらを削除するために使用する素晴らしいスクリプトがあります

docker rmi $(docker images | grep '^<none>' | awk '{print $3}')

次に、Docker Composeを使用して、すべてのプロジェクトのローカルでイメージをビルドする場合。通常はフォルダーのように名前が付けられた多数の画像が作成されます（たとえば、プロジェクトフォルダーの名前がHelloの場合、画像名が見つかりますHello_blablabla）。これらの画像をすべて削除することも検討してください

上記のスクリプトを編集して削除するか、手動で削除できます

docker rmi {image-name}

更新
Dockerの開発が進むにつれて、以下のコマンドはハックになりました。現在のベストプラクティスは

docker system prune

これは削除されます：

- all stopped containers
- all volumes not used by at least one container
- all networks not used by at least one container
- all dangling images

以下のように、これは核です。

システムをクリーンアップするには、まずコンテナを削除します

$ docker rm $(docker ps -aq)

次に、画像を削除します

$ docker rmi $(docker images -q)

これはもちろん核であり、すべてのコンテナとすべての画像を削除します。docker rm #CONTAINER_ID#およびを使用して、一度に1つずつ削除できdocker rmi #IMAGE_IDます。

/ varに空き領域があることを確認してください。これは、Dockerがデフォルトでイメージファイルを格納する場所です（/ var / lib / docker内）。

まず、docker ps -aすべてのコンテナー（停止したコンテナーを含む）をリストdocker rmし、それらを削除するためにを使用して、内容をクリーンアップします。次に、を使用docker imagesして、保存したすべての画像を一覧表示し、docker rmiそれらを削除します。

次に、dockerデーモンの-gオプションを使用するか/etc/default/docker、-gオプションを編集してに追加することにより、保存場所を変更しますDOCKER_OPTS。-g「Dockerランタイム」の場所を指定します。これは、基本的に、イメージをビルドしてコンテナーを実行するときにDockerが作成するすべてのものです。使用されるディスク容量は時間とともに大きくなる傾向があるため、十分な容量のある場所を選択してください。を編集した場合/etc/default/docker、変更を有効にするにはdockerデーモンを再起動する必要があります。

これで、新しいイメージを作成（またはDocker Hubからイメージをプル）できるようになり、-gオプションで指定したディレクトリに一連のファイルが作成されます。

すでに述べたように、

docker system prune

は役立ちますが、Docker 17.06.1以降では未使用のボリュームを削除しません。Docker 17.06.1以降、次のコマンドもボリュームを整理します。

docker system prune --volumes

Dockerドキュメントから：https : //docs.docker.com/config/pruning/

docker system pruneコマンドは、イメージ、コンテナー、およびネットワークをプルーニングするショートカットです。Docker 17.06.0以前では、ボリュームも整理されます。Docker 17.06.1以降では、ボリュームをプルーニングするには、Dockerシステムのプルーニングに--volumesフラグを指定する必要があります。

ボリュームをプルーニングしてイメージとコンテナーを保持する場合：

docker volume prune

Dockerのテストインストールだけ（つまり、本番環境ではない）で、核のクリーンアップを行う必要がない場合は、次のことができます。

すべてのコンテナを清掃します。 docker ps -a | sed '1 d' | awk '{print $1}' | xargs -L1 docker rm

すべての画像を消去： docker images -a | sed '1 d' | awk '{print $3}' | xargs -L1 docker rmi -f

繰り返しますが、Dockerを開発するときは、ec2インスタンスでこれを使用します。深刻なQAやプロダクションパスでは使用しません。すばらしいのは、Dockerfileがあれば、再構築やを簡単に実行できることdocker pullです。

未使用のコンテナー、ボリューム、ネットワーク、イメージをすべて一度に削除するには（https://docs.docker.com/engine/reference/commandline/system_prune/#related-commands）：

docker system prune -a -f --volumes

それが十分でない場合は、最初に実行中のコンテナを削除できます。

docker rm -f $(docker ps -a -q)
docker system prune -a -f --volumes

/ var / lib / dockerを増やすか、より多くのスペースを持つ別の場所を使用することも、このエラーを取り除くための良い選択肢です（Dockerイメージのインストールディレクトリを変更する方法を参照してください）。

Mac用Docker

だから、docker system pruneおよびdocker system prune --volumes他の回答で提案解放されたいくつかのスペースを毎回、結局、私は何を実行したたびに、私はエラーを取得しました。

ルートの問題を実際に修正したのはDocker.raw、Docker for Macがストレージに使用するファイルを削除し、再起動することでした。

そのファイルを見つけるには、Mac用Dockerを開き、次の場所に移動します*

Preferences > Resources > Advanced > Disk Image Location

*これはバージョン2.2.0.5向けですが、古いバージョンでは同様のはずです。

新しいバージョンのDocker for Mac **では、UIのディスク上のファイルの実際のサイズと、最大割り当てサイズが表示されます。あなたはおそらくそれが巨大であることを見るでしょう。たとえば、私のマシンでは41GBでした。

**古いバージョンでは、UIに実際のディスク使用量は表示されず、MacOS Finderは常に最大割り当てサイズとしてファイルサイズを表示します。ターミナルでディレクトリを開いて実行すると、ディスク上の実際のサイズを確認できますdu -h Docker.raw

削除Docker.rawしてMac用Dockerを再起動すると、ファイルは自動的に再度作成され、0GBに戻りました。

もちろん、Dockerキャッシュは失われていましたが、以前と同様にすべてが機能し続けました。予想通り、いくつかのDockerコマンドを実行した後、ファイルは数GBのデータで再びいっぱいになりましたが、41 GBに近いところはありませんでした。

更新

_{数か月後、私はDocker.raw再び同じようなサイズに満たしました。したがって、この方法は機能しましたが、数か月ごとに繰り返す必要があります。私にはそれで結構です。}

_{なぜこれが機能するのかについての注記-私はそれがDocker for Macのバグであると想定しなければなりません。docker system prune/ docker system prune --volumesはこのファイルの内容を完全にクリアするように見えますが、ファイルにはこれらのコマンドで削除できない他のものが蓄積されているようです。とにかく、手動で削除すると問題は解決します！}

Dockerは、宙ぶらりんの画像を残し、スペースを占有する可能性があります。Dockerの後にクリーンアップするには、次を実行します。

docker image prune [-af if you want to force remove all images]

または古いバージョンのDockerの場合：

docker rm $(docker ps -q -f 'status=exited')
docker rmi $(docker images -q -f "dangling=true")

これにより、終了してぶら下がっている画像が削除され、デバイスのスペースが空くことが期待されます。

1. ぶら下がり画像をクリーンアップ docker rmi $(docker images -f "dangling=true" -q)
2. 不要なボリュームを削除する
3. 未使用の画像を削除する
4. 未使用のコンテナを削除する

あなたも使うことができます：

docker system prune

またはボリュームのみの場合：

docker volume prune

私の場合、ubuntu-server 18.04.1 [奇​​妙な理由で]をインストールすると、750GBではなく4GBのサイズのLVM論理ボリュームが作成されました。したがって、イメージをプルすると、「デバイスにスペースがありません」というエラーが表示されます。修正は簡単です：

lvextend -l 100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv

RHELマシンでもこの問題が発生しました。私はスタックオーバーフローとドッカーハブコミュニティのどこにも適切な解決策を見つけませんでした。以下のコマンドの後でもこの問題に直面している場合：

docker system prune --all

最終的に機能したソリューション：

1. ドッカー情報
   • 現在のDockerストレージドライバーを確認するには
   • 鉱山だった：ストレージドライバー：devicemapper; overlay2としてストレージドライバーを使用している場合、心配する必要はありません。ソリューションは引き続き機能します。
2. df -h
   • これは、マシンで使用可能なファイルシステムと、それらがマウントされているパスを確認するためのものです。メモを付けるための2つのマウントされたパス：
   • / dev / mapper / rootvg-var 7.6G 1.2G 6.1G 16％/ var
   • / dev / mapper / rootvg-apps 60G 9.2G 48G 17％/ apps
   • 注 -デフォルトでは、Dockerのストレージパスは/ var / lib / dockerです。使用可能なスペースは6 GB以下であり、スペースに関連するすべての問題があります。したがって、基本的には、デフォルトのストレージを、使用可能なスペースが多い他のストレージに移動する必要があります。私にとっては、/ appsにマウントされているFile sysyemパス '/ dev / mapper / rootvg-apps'です。次に、/ var / lib / dockerを/ apps / newdocker / dockerなどに移動します。
3. mkdir / apps / newdocker / docker
4. chmod -R 777 / apps / newdocker / docker
5. / usr / lib / systemd / systemの下にあるLinux上のdocker.seriveファイルを更新します。
   • vi /usr/lib/systemd/system/docker.service
6. ストレージデバイスがdevicemapperの場合は、既存のExecStart行をコメントにして、[Service]の下に以下を追加します。
   • ExecStart =
   • ExecStart = / usr / bin / dockerd -s devicemapper --storage-opt dm.fs = xfs --storage-opt dm.basesize = 40GB -g / apps / newdocker / docker --exec-opt native.cgroupdriver = cgroupfs
7. または、ストレージデバイスがoverlay2の場合：
   • 既存のExexStartステートメントに-g / apps / newdocker / dockerを追加するだけです。
   • ExecStart = / usr / bin / dockerd -g / apps / newdocker / docker -H fd：// --containerd = / run / containerd / containerd.sockのようなもの
8. rm -rf / var / lib / docker（既存のすべてのDockerデータが削除されます）
9. systemctl stop docker
10. ps aux | grep -i docker | grep -v grep
    • 上記のコマンドで出力が生成されない場合は、以下のコマンドでsystemdデーモンをリロードしてください。
11. systemctl daemon-reload
12. systemctl start docker
13. ドッカー情報
    • 利用可能なデータスペースを確認してください：新しいファイルシステムにドッキングするようにマウスアウトした後、62.15GB。
14. 完了

次のコマンドを使用してDockerをクリーンアップします。

docker images --no-trunc | grep '<none>' | awk '{ print $3 }' \
| xargs docker rmi

cgroupでcpusetコントローラーが有効になっています。このコントローラーは、タスクの実行を許可するCPU /メモリーバンクを細かく指定できるNUMA環境で主に役立ちます。

デフォルトでは必須cpuset.memsでcpuset.cpusあり、設定されていません。つまり、タスクに「スペースが残っていない」ため、エラーが発生します。

これを修正する最も簡単な方法cgroup.clone_childrenは、ルートcgroupで1 を有効にすることです。あなたの場合、それは

echo 1 > /sys/fs/cgroup/docker/cgroup.clone_children

それは基本的にシステムに自動的にコンテナの初期化cpuset.memsとcpuset.cpusその親cgroupからの初期化を指示します。

Docker Toolkitを介してboot2dockerイメージを使用している場合、問題は、boot2docker仮想マシンのスペースが不足していることが原因です。

を実行するdocker importか、新しい画像を追加すると、画像は/mnt/sda1いっぱいになった可能性のある画像にコピーされます。

イメージで使用可能なスペースを確認する1つの方法は、vmにsshして実行df -hし、/ mnt / sda1の残りのスペースを確認することです

sshコマンドは docker-machine ssh default

それが本当にスペースの問題であることを確認したら、この質問の回答のいくつかの指示に従ってクリーンアップするか、上のスペースを増やしてboot2dockerイメージ自体のサイズを変更することを選択できます。 /mnt/sda1

ここの指示に従って、画像のサイズ変更を行うことができます https://gist.github.com/joost/a7cfa7b741d9d39c1307

Dockerデスクトップを使用している場合は、ディスクイメージのサイズを増やすことができます中に詳細設定ドッカーさんに行くことによって環境設定。

これはmacOSのスクリーンショットです。

デフォルトのストレージスペースが40GBに設定されていることが原因である可能性があります（デフォルトパス、/ var / lib / docker）

別のパスを指すようにストレージボリュームを変更できます

• ファイルを編集-> / etc / sysconfig / docker-storage
• 下の行を更新（存在しない場合は追加）

DOCKER_STORAGE_OPTIONS = '-storage-driver = overlay --graph = CUSTOM_PATH'

• docker systemctlを再起動しますdocker systemctlデーモンを再起動しますsystemctl start dockerを再読み込みします

コマンドdocker infoを実行した場合（ストレージドライバーがオーバーレイとして表示されるはずです）

これが発生する可能性があるいくつかの方法があるようです。私が抱えていた問題は、Dockerディスクイメージが最大サイズに達したことです（OSXのサイズを表示する場合は、Docker Whale-> Preferences-> Disk）。

限界まで上げて行ってよかった。未使用の画像のクリーンアップも機能すると確信しています。

以下のコマンドを実行します。

後でイメージを再構築する必要はありません。

docker rm $(docker ps -qf 'status=exited')
docker rmi $(docker images -qf "dangling=true")
docker volume rm $(docker volume ls -qf dangling=true)

これらは、終了した/ぶら下がっているコンテナとぶら下がっているボリュームを削除します。

私にとってdocker system pruneはトリックをしました。Mac OSを実行しています。

$ docker rm $(docker ps -aq)

これは私のために働いた

docker system prune 

最新バージョンではより良いオプションのようです