L’utilisation de périphériques de bouclage est fortement déconseillée pour une utilisation en production

Je veux tester Docker dans mon boîtier CentOS 7.1, j’ai eu 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 connaître la raison et comment supprimer cet avertissement.

L’instance CentOS s’exécute dans virtualbox créé 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 réellement sauvegardé par un fichier sur votre système de fichiers. Cela n’a jamais été une simple tentative de faire fonctionner rapidement Docker comme une 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. La méthode la plus simple consiste à atsortingbuer un espace disque local à utiliser par le pilote de stockage devicemapper de Docker et à l’utiliser.

Si vous utilisez LVM et que vous disposez d’un espace libre sur votre groupe de volumes, c’est relativement facile. Par exemple, pour donner de l’espace au docker 100G, 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 

Et ensuite configurez Docker pour utiliser cet espace en éditant /etc/sysconfig/docker-storage pour ressembler à ceci:

 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 de rechange) à 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 sharepoint soumettre un bug contre bash. Malheureusement, aucune des options présentées ne sont viables sur un ordinateur portable ou sur un disque entièrement utilisé. Voici ma réponse à ce scénario.

Voici ce que j’ai utilisé dans / etc / sysconfig / docker-storage sur mon ordinateur portable:

 DOCKER_STORAGE_OPTIONS="--storage-opt dm.no_warn_on_loop_devices=true" 

Remarque: j’ai dû redémarrer le service docker pour que cela fonctionne. Sur Fedora, la commande pour cela est:

 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 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 en détail:

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 votre image complète et le magasin de conteneurs. Vous pouvez tout aussi bien dans le dossier / var / lib / docker lorsque vous faites ceci:

 systemctl stop docker rm -rf /var/lib/docker dnf reinstall docker systemctl start docker 

Dans RHEL 6.6, tout utilisateur ayant access à Docker peut accéder à mes clés privées et exécuter des applications en tant que root avec le plus sortingvial 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 quelle part de la sécurité RHEL 7 supplémentaire provient de SELinux à l’extérieur du conteneur et combien à l’intérieur du conteneur …

Généralement, les périphériques de bouclage conviennent parfaitement aux cas où la limite de 100 Go maximum et une performance légèrement réduite ne posent aucun problème. Le seul problème que je peux trouver est que Docker Store peut être corrompu si vous avez une erreur de disque en cours d’exécution … Cela peut probablement être évité avec des quotas ou d’autres solutions simples.

Cependant, pour une instance de production, cela vaut certainement le temps et les efforts nécessaires pour la configurer correctement.

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 VM comme mesure supplémentaire de sécurité et d’isolation. Si c’est le cas, vous pourriez avoir un nombre de conteneurs relativement petit par machine virtuelle. Dans ce cas, même 10G pourrait suffire.

Une dernière note Même si vous utilisez direct lvm, vous voudrez 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 chargées dans ce dossier avant de l’append au magasin de données. Donc, si vous essayez de le garder petit et léger, explorez les options autres que le lvm direct.

@Igor Ganapolsky Fév et @ Mincă Daniel Andrei

Vérifie ça:

systemctl edit docker --full

Si la directive EnvironmentFile n’est pas listée dans le bloc [Service] , alors pas de chance (j’ai aussi ce problème sur Centos7), mais vous pouvez étendre l’unité systemd standard comme ceci:

systemctl edit docker EnvironmentFile=-/etc/sysconfig/docker ExecStart= ExecStart=/usr/bin/dockerd $OPTIONS

Et créez un fichier /etc/sysconfig/docker avec un contenu:

OPTIONS="-s overlay --storage-opt dm.no_warn_on_loop_devices=true"