Pourquoi l'image du menu fixe absorbe-t-elle mon espace disque qui n'est pas utilisé par le menu fixe
J'ai installé docker et j'ai utilisé un périphérique de bloc complètement différent pour stocker les données système de docker:
[root@blink1 /]# cat /etc/sysconfig/docker
# /etc/sysconfig/docker
other_args="-H tcp://0.0.0.0:9367 -H unix:///var/run/docker.sock -g /disk1/docker"
Notez que /disk/1 utilise un disque dur complètement différent /dev/xvdi
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.8G 5.1G 2.6G 67% /
devtmpfs 1.9G 108K 1.9G 1% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/xvdi 20G 5.3G 15G 27% /disk1
/dev/dm-1 9.8G 1.7G 7.6G 18% /disk1/docker/devicemapper/mnt/bb6c540bae25aaf01aedf56ff61ffed8c6ae41aa9bd06122d440c6053e3486bf
/dev/dm-2 9.8G 1.7G 7.7G 18% /disk1/docker/devicemapper/mnt/c85f756c59a5e1d260c3cdb473f3f4d9e55ac568967abe190eeaf9c4087afeac
Le problème est que, lorsque je continue à télécharger des images de docker et à exécuter des conteneurs de docker, il semble que l’autre disque dur /dev/xvda1 est également épuisé.
Je peux vérifier ce problème en supprimant certaines images de menu fixe. Après avoir supprimé certaines images du menu fixe, /dev/xvda1 a maintenant plus d’espace supplémentaire.
Est-ce que je manque quelque chose?
Ma version de docker:
[root@blink1 /]# docker info
Containers: 2
Images: 42
Storage Driver: devicemapper
Pool Name: docker-202:1-275421-pool
Pool Blocksize: 64 Kb
Data file: /disk1/docker/devicemapper/devicemapper/data
Metadata file: /disk1/docker/devicemapper/devicemapper/metadata
Data Space Used: 3054.4 Mb
Data Space Total: 102400.0 Mb
Metadata Space Used: 4.7 Mb
Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.2
Kernel Version: 3.14.20-20.44.amzn1.x86_64
Operating System: Amazon Linux AMI 2014.09
C'est un problème de noyau lié à devicemapper, qui affecte la famille de systèmes d'exploitation RedHat (RedHat, Fedora, CentOS et Amazon Linux). Les conteneurs supprimés ne libèrent pas d'espace disque mappé. Cela signifie que sur les systèmes d'exploitation concernés, vous manquerez progressivement d'espace lorsque vous démarrez et redémarrez les conteneurs.
Le projet Docker en est conscient et le noyau est censé être corrigé en amont ( https://github.com/docker/docker/issues/3182 ).
Une solution de rechange consiste à donner à Docker son propre volume sur lequel écrire ( "(Lorsque Docker utilise votre espace disque" ). Cela ne l'empêche pas réellement de manger de l'espace, mais simplement de supprimer d'autres parties de votre système.
Ma solution consistait à désinstaller Docker, puis à supprimer tous ses fichiers, puis à réinstaller:
Sudo yum remove docker
Sudo rm -rf /var/lib/docker
Sudo yum install docker
Cela m'a permis de récupérer de l'espace, mais ce n'est pas très différent du simple lancement d'une instance de remplacement. Je n'ai pas trouvé de solution plus intéressante.
Supprimer tout mon/var/lib/docker ne me convient pas. Ce sont des moyens plus sûrs:
Solution 1:
Les commandes suivantes du numéro libèrent de l’espace pour moi. C’est beaucoup plus sûr que de supprimer/var/lib/docker ou que Windows vérifie l’emplacement de votre image disque ici .
Avant:
docker info
Exemple de sortie:
Metadata file:
Data Space Used: 53.38 GB
Data Space Total: 53.39 GB
Data Space Available: 8.389 MB
Metadata Space Used: 6.234 MB
Metadata Space Total: 54.53 MB
Metadata Space Available: 48.29 MB
Commande dans les versions plus récentes de Docker, par exemple. 17.x +
docker system Prune -a
Il vous montrera un avertissement indiquant qu'il supprimera tous les conteneurs, réseaux, images et construction de cache arrêtés. En règle générale, il est prudent de supprimer cela. (La prochaine fois que vous exécuterez un conteneur, il pourra être extrait du registre de Docker)
Exemple de sortie:
Total reclaimed space: 1.243GB
Vous pouvez ensuite exécuter à nouveau le menu fixe pour voir ce qui a été nettoyé.
docker info
Solution 2:
Parallèlement à cela, assurez-vous que vos programmes dans le conteneur Docker n'écrivent pas beaucoup/de gros fichiers dans le système de fichiers.
Vérifiez la taille d'utilisation de l'espace de votre processus de menu fixe en cours d'exécution
docker ps -s #may take minutes to return
ou pour tous les conteneurs, même sortis
docker ps -as #may take minutes to return
Vous pouvez ensuite supprimer le ou les conteneurs incriminés
docker rm <CONTAINER ID>
Trouvez le coupable possible qui utilise peut-être des concerts d'espace
docker exec -it <CONTAINER ID> "/bin/sh"
du -h
Dans mon cas, le programme écrivait des concerts de fichiers temporaires.
( Nathaniel Waisbrot mentionné dans la réponse acceptée this numéro et j'ai reçu des informations du numéro)
[~ # ~] ou [~ # ~]
Commandes dans les anciennes versions de Docker, par exemple. 1.13.x (exécuté en tant que root et non Sudo):
# Delete 'exited' containers
docker rm -v $(docker ps -a -q -f status=exited)
# Delete 'dangling' images (If there are no images you will get a docker: "rmi" requires a minimum of 1 argument)
docker rmi $(docker images -f "dangling=true" -q)
# Delete 'dangling' volumes (If there are no images you will get a docker: "volume rm" requires a minimum of 1 argument)
docker volume rm $(docker volume ls -qf dangling=true)
Après:
> docker info
Metadata file:
Data Space Used: 1.43 GB
Data Space Total: 53.39 GB
Data Space Available: 51.96 GB
Metadata Space Used: 577.5 kB
Metadata Space Total: 54.53 MB
Metadata Space Available: 53.95 MB
J'ai eu un problème similaire et je pense que cela se produit lorsque vous ne disposez pas de suffisamment d'espace sur le disque pour toutes vos images de menu fixe. J'avais 6 Go réservés pour les images de docker, ce qui s'est avéré ne pas suffire dans mon cas. Quoi qu'il en soit, j'avais supprimé chaque image et chaque conteneur et le disque semblait toujours plein. La plupart de l'espace était utilisé par/var/lib/docker/devicemapper et/var/lib/docker/tmp.
Cette commande n'a pas fonctionné pour moi:
# docker ps -qa | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ fstrim /proc/Z/root/
Tout d'abord, j'ai arrêté le service de docker:
Sudo service docker stop
Puis j'ai supprimé/var/lib/docker:
Ensuite, j'ai fait ce que quelqu'un a suggéré ici https://github.com/docker/docker/issues/18867#issuecomment-23230107
Supprimer l'instance existante des métadonnées du menu fixe rm -rf/var/lib/docker
Sudo rm -rf/var/lib/docker
Passez les options suivantes au démon docker: -s devicemapper --storage-opt dm.fs = xfs --storage-opt dm.mountopt = discard
Démarrez le démon docker.
Pour les deux dernières étapes, je lance:
Sudo dockerd -s devicemapper --storage-opt dm.fs=xfs --storage-opt dm.mountopt=discard
Déplacez le répertoire /var/lib/docker.
En supposant que le répertoire /data Dispose de suffisamment de place, sinon remplacez-le par celui qui en a,
Sudo systemctl stop docker
Sudo mv /var/lib/docker /data
Sudo ln -s /data/docker /var/lib/docker
Sudo systemctl start docker
De cette façon, vous n'avez pas à reconfigurer le menu fixe.
Comme mentionné dans le numéro # 18867 - La suppression de données dans un conteneur devicemapper ne peut pas libérer de l'espace utilisé de Github.com
Essayez d’exécuter la commande ci-dessous:
# docker ps -qa | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ fstrim /proc/Z/root/
Il utilise l'outil fstrim pour découper le disque fourni par devicemapper.
Docker Prune, par défaut, ne supprime pas les volumes.
vous pouvez essayer quelque chose comme
docker system Prune --volume
Oui, Docker utilise le dossier/var/lib/docker pour stocker les calques. Il existe des moyens de récupérer l'espace et de déplacer le stockage dans un autre répertoire.
Vous pouvez monter un espace disque plus important et déplacer le contenu de/var/lib/docker vers le nouvel emplacement de montage et créer un lien sym.
Il y a des explications détaillées sur la façon de faire la tâche ci-dessus.
http://www.scmtechblog.net/2016/06/clean-up-docker-images-from-local-to.html
Vous pouvez également supprimer les couches intermédiaires.
peut-être que vous pouvez essayer docker system Prune pour supprimer toutes les images sans importance