L'utilisation de dispositifs de bouclage est fortement déconseillée pour une utilisation en production
Je veux tester docker dans ma boîte CentOS 7.1, je reçois cet avertissement:
[root@docker1 ~]# docker run busybox /bin/echo Hello Docker
Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
Hello Docker
Je veux savoir la raison et comment supprimer cet avertissement.
L'instance CentOS s'exécute dans la virtualbox créée par vagrant.
Le message d'avertissement se produit car votre configuration de stockage Docker utilise un "périphérique de bouclage" - un périphérique de bloc virtuel tel que /dev/loop0 qui est en réalité sauvegardé par un fichier sur votre système de fichiers. Cela n’a jamais été autre chose qu’un simple bidouillage permettant à Docker de fonctionner rapidement comme preuve de concept.
Vous ne voulez pas supprimer l'avertissement; vous souhaitez corriger votre configuration de stockage de sorte que l'avertissement ne soit plus émis. Pour ce faire, le moyen le plus simple consiste à affecter un espace disque local au pilote de stockage devicemapper de Docker et à l'utiliser.
Si vous utilisez LVM et que vous disposez d'un peu d'espace libre sur votre groupe de volumes, cela est relativement facile. Par exemple, pour donner au docker 100 G d'espace, créez d'abord un volume de données et de métadonnées:
# lvcreate -n docker-data -L 100G /dev/my-vg
# lvcreate -n docker-metadata -L1G /dev/my-vg
Ensuite, configurez Docker pour utiliser cet espace en modifiant /etc/sysconfig/docker-storage pour ressembler à:
DOCKER_STORAGE_OPTIONS=-s devicemapper --storage-opt dm.datadev=/dev/my-vg/docker-data --storage-opt dm.metadatadev=/dev/my-vg/docker-metadata
Si vous n'utilisez pas LVM ou si vous ne disposez pas d'espace libre sur votre VG, vous pouvez exposer un autre périphérique de bloc (par exemple, un disque ou une partition disponible) à Docker de la même manière.
Il y a quelques notes intéressantes sur ce sujet ici .
Merci. Cela me rendait fou. Je pensais que bash sortait ce message. J'étais sur le point de soumettre un bogue contre bash. Malheureusement, aucune des options présentées n’est viable sur un ordinateur portable ou sur un disque où le disque est pleinement utilisé. Voici ma réponse pour ce scénario.
Voici ce que j'ai utilisé dans le répertoire/etc/sysconfig/docker-storage de mon ordinateur portable:
DOCKER_STORAGE_OPTIONS="--storage-opt dm.no_warn_on_loop_devices=true"
Remarque: je devais redémarrer le service de menu fixe pour que cela ait un effet. Sur Fedora, la commande est la suivante:
systemctl stop docker
systemctl start docker
Il y a aussi juste une commande de redémarrage (systemctl restart docker), mais c'est une bonne idée de vérifier pour vous assurer que l'arrêt a vraiment fonctionné avant de recommencer.
Si cela ne vous dérange pas de désactiver SELinux dans vos conteneurs, une autre option consiste à utiliser la superposition. Voici un lien qui décrit cela complètement:
http://www.projectatomic.io/blog/2015/06/notes-on-Fedora-centos-and-docker-storage-drivers/
En résumé pour/etc/sysconfig/docker:
OPTIONS='--selinux-enabled=false --log-driver=journald'
et pour/etc/sysconfig/docker-storage:
DOCKER_STORAGE_OPTIONS=-s overlay
Lorsque vous modifiez un type de stockage, le redémarrage de docker détruira l'intégralité de votre magasin d'images et de conteneurs. Vous pouvez également tout placer dans le dossier/var/lib/docker en procédant comme suit:
systemctl stop docker
rm -rf /var/lib/docker
dnf reinstall docker
systemctl start docker
Dans RHEL 6.6, tout utilisateur ayant accès au menu fixe peut accéder à mes clés privées et exécuter des applications en tant que root avec le plus simple des hacks via des volumes. SELinux est la seule chose qui empêche cela dans Fedora et RHEL 7. Cela dit, on ne sait pas combien de sécurité supplémentaire RHEL 7 provient de SELinux à l'extérieur du conteneur et combien à l'intérieur du conteneur ...
En règle générale, les périphériques de bouclage conviennent aux cas où la limite de 100 Go maximum et une performance légèrement réduite ne posent pas de problème. Le seul problème que je peux trouver est que le magasin de docker peut être corrompu si vous rencontrez une erreur de disque plein lors de l'exécution ... Cela peut probablement être évité avec des quotas ou d'autres solutions simples.
Cependant, pour une instance de production, le temps et les efforts nécessaires à son installation méritent vraiment d'être vus.
100G peut être excessif pour votre instance de production. Les conteneurs et les images sont assez petits. De nombreuses organisations exécutent des conteneurs Docker dans les ordinateurs virtuels comme mesure supplémentaire de sécurité et d'isolation. Si tel est le cas, le nombre de conteneurs exécutés par machine virtuelle peut être relativement faible. Dans ce cas, même 10G pourraient suffire.
Une dernière note. Même si vous utilisez direct lvm, vous souhaiterez probablement un système de fichiers supplémentaire pour/var/lib/docker. La raison en est que la commande "docker load" créera une version non compressée des images en cours de chargement dans ce dossier avant de l'ajouter au magasin de données. Donc, si vous essayez de rester petit et léger, explorez des options autres que le cinéma direct.
@Igor Ganapolsky Février et @ Mincă Daniel Andrei
Vérifie ça:
systemctl edit docker --full
Si la directive EnvironmentFile n'est pas répertoriée dans le bloc [Service], aucune chance (j'ai également ce problème sur Centos7), mais vous pouvez étendre l'unité standard systemd comme ceci:
systemctl edit docker
EnvironmentFile=-/etc/sysconfig/docker
ExecStart=
ExecStart=/usr/bin/dockerd $OPTIONS
Et créez un fichier /etc/sysconfig/docker avec le contenu:
OPTIONS="-s overlay --storage-opt dm.no_warn_on_loop_devices=true"