Moby: Comment gérer le cas où la taille du fichier de données Docker atteint le seuil de 100 G ?

Créé le 29 mars 2016  ·  3Commentaires  ·  Source: moby/moby

Sortie de docker version :

Client:
 Version:      1.8.2-el7.centos
 API version:  1.20
 Package Version: docker-1.8.2-10.el7.centos.x86_64
 Go version:   go1.4.2
 Git commit:   a01dc02/1.8.2
 Built:        
 OS/Arch:      linux/amd64

Server:
 Version:      1.8.2-el7.centos
 API version:  1.20
 Package Version: 
 Go version:   go1.4.2
 Git commit:   a01dc02/1.8.2
 Built:        
 OS/Arch:      linux/amd64

Sortie de docker info :

Containers: 0
Images: 130
Storage Driver: devicemapper
 Pool Name: docker-253:0-3221586422-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: /dev/loop4
 Metadata file: /dev/loop5
 Data Space Used: 107.4 GB
 Data Space Total: 107.4 GB
 Data Space Available: 0 B
 Metadata Space Used: 60.92 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.087 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: false
 Data loop file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.107-RHEL7 (2015-12-01)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.10.0-229.el7.x86_64
Operating System: CentOS Linux 7 (Core)
CPUs: 12
Total Memory: 31.2 GiB
Name: IP-5-14
ID: DNOS:FC2P:2WH4:OSYL:L2CH:U7HZ:MFL2:ZID3:SYTX:JWKP:TGIN:YYPB
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Détails supplémentaires sur l'environnement (AWS, VirtualBox, physique, etc.) :

Étapes pour reproduire le problème :
je veux exécuter mon image docker appelée passerelle en utilisant la cmd ci-dessous. (un point d'entrée sans démon a été défini dans le Dockerfile de la passerelle)

docker run -d -P gateway

Décrivez les résultats que vous avez reçus :
le conteneur peut fonctionner comme d'habitude

Décrivez les résultats que vous attendiez :

[root@IP-5-14 devicemapper]# docker run -d -P gateway
Error response from daemon: Error running DeviceCreate (createSnapDevice) dm_task_run failed

Informations supplémentaires que vous jugez importantes (par exemple, un problème ne survient qu'occasionnellement) :

  1. comme le montre le docker info , l'espace de données a été augmenté jusqu'au seuil 100G.
  2. quand je supprime le conteneur en utilisant docker rm -f $(docker ps -a -q) . Tous les conteneurs ont été supprimés, mais l'erreur ci-dessous a été signalée :
Error response from daemon: Cannot destroy container 5d5eed10468b: Driver devicemapper failed to remove root filesystem 5d5eed10468b809475b0eb23bda167e1a962d32092a348936d56e27417dbf578: Error running DeleteDevice dm_task_run failed
  1. j'ai utilisé docker ps -a pour m'assurer que tous les conteneurs avaient été supprimés après avoir effectué l'étape 2. le résultat cmd est vide. mais une erreur se produit (ci-dessous) lorsque je supprime une image NONE
[root@IP-5-14 devicemapper]# docker rmi 6fdebd7b0eb5   
Error response from daemon: Conflict, cannot delete because 6fdebd7b0eb5 is held by an ongoing pull or build
Error: failed to remove images: [6fdebd7b0eb5]

Quelqu'un peut-il me rendre un service ? Merci beaucoup

Commentaire le plus utile

Vous devez augmenter le pool autorisé pour vos conteneurs. Pour ce faire, vous devrez supprimer votre var/lib/docker qui détruira tous vos conteneurs et images.

sudo service docker stop
sudo rm -rf /var/lib/docker
sudo dd if=/dev/zero of=/var/lib/docker/devicemapper/devicemapper/data bs=1G count=0 seek=300
Cela rendra votre espace de données utilisé de 300 Go

Cela résout-il votre problème ? Essayez également d'arrêter les processus Docker, redémarrez Docker et voyez si vous pouvez supprimer les images.

Tous les 3 commentaires

Vous devez augmenter le pool autorisé pour vos conteneurs. Pour ce faire, vous devrez supprimer votre var/lib/docker qui détruira tous vos conteneurs et images.

sudo service docker stop
sudo rm -rf /var/lib/docker
sudo dd if=/dev/zero of=/var/lib/docker/devicemapper/devicemapper/data bs=1G count=0 seek=300
Cela rendra votre espace de données utilisé de 300 Go

Cela résout-il votre problème ? Essayez également d'arrêter les processus Docker, redémarrez Docker et voyez si vous pouvez supprimer les images.

Devicemapper à court d'espace peut en effet être très délicat; Nous suivons les problèmes à ce sujet dans https://github.com/docker/docker/issues/20272.

Pour Docker 1.11, il existe une nouvelle option pour spécifier une quantité minimale d'espace libre à conserver, et vous éviterait d'arriver dans cette situation ; voir https://github.com/docker/docker/pull/20786

Je vais fermer ce sujet, car je pense que ce n'est pas un bug, mais une question de support, mais n'hésitez pas à poursuivre la discussion ici

bien. Merci beaucoup. Espoir pour les nouvelles fonctionnalités de Docker1.11

Cette page vous a été utile?
0 / 5 - 0 notes