Pas assez d'entropie pour supporter /dev / random dans les conteneurs docker tournant dans boot2docker
L'épuisement de l'entropie dans les systèmes Linux virtualisés semble être un problème courant (par exemple / dev / random extrêmement lent? , pour linux de tampon /dev/random ). Malgré l'utilisation d'un générateur de nombres aléatoires matériel (HRNG) l'utilisation d'un daemon de collecte d'entropie comme HAVEGED est souvent suggéré. Cependant, un démon de collecte d'entropie (EGD) ne peut pas être exécuté à l'intérieur d'un conteneur Docker, il doit être fourni par l'hôte.
utiliser un EGD fonctionne très bien pour les dockers basés sur des distributions linux comme Ubuntu, RHEL, etc. Obtenir un tel démon pour fonctionner dans boot2docker-qui est basé sur Tiny Core Linux (TCL) - semble être une autre histoire. Bien que TCL dispose d'un mécanisme d'extension, une extension pour un démon collecteur d'entropie ne semble pas être disponible .
donc un EGD semble être une bonne solution pour faire fonctionner des conteneurs docker dans un) environnement d'hébergement, mais comment le résoudre pour le développement/tests dans boot2docker?
depuis que lancer un EGD dans boot2docker semblait trop difficile, j'ai pensé à utiliser simplement /dev/urandom au lieu de /dev/random. Utiliser /dev / urandom est un peu moins sûr, mais tout de même très bien pour la plupart des applications qui ne génèrent pas de clés cryptographiques à long terme. Au moins, il devrait être parfait pour le développement/test à l'intérieur de boot2docker.
5 réponses
je viens de réaliser, qu'il est simple comme le montage / dev / urandom de l'hôte comme / dev / random dans le conteneur:
$ docker run -v /dev/urandom:/dev/random ...
le résultat est comme prévu:
$ docker run --rm -it -v /dev/urandom:/dev/random ubuntu dd if=/dev/random of=/dev/null bs=1 count=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB) copied, 0.00223239 s, 459 kB/s
au moins je sais comment construire mes propres images boot2docker maintenant ;-)
la solution la plus élégante que j'ai trouvée est de lancer Haveged dans un conteneur séparé:
docker pull harbur/haveged
docker run --privileged -d harbur/haveged
vérifier s'il y a suffisamment d'entropie disponible:
$ cat /proc/sys/kernel/random/entropy_avail
2066
comme je n'ai pas aimé modifier mes conteneurs Docker pour le développement/test, j'ai essayé de modifier l'image boot2docker. Heureusement, l'image boot2docker est construite avec Docker et peut être facilement prolongée . Donc j'ai mis en place mon propre docker build boot2docker-urandom . Il étend l'image standard de boot2docker avec une règle udev trouvée ici .
construire votre propre boot2docker.l'image iso est simple comme
$ docker run --rm mbonato/boot2docker-urandom > boot2docker.iso
pour remplacer le boot2docker standard.iso qui vient avec boot2docker vous devez:
$ boot2docker stop
$ boot2docker delete
$ mv boot2docker.iso ~/.boot2docker/
$ boot2docker init
$ boot2docker up
Edit:
Toutefois , à partir de l'intérieur d'un conteneur Docker /dev/random encore des blocs. Très probablement, parce que les conteneurs Docker n'utilisent pas /dev/random de l'hôte directement, mais utilisent le périphérique du noyau correspondant - qui bloque toujours.
Toutes les suggestions?
"1519130920 Alpin" Linux peut être un meilleur choix pour un léger docker de l'hôte. Alpine LXC & docker les images ne sont que de 5 Mo (contre 27 Mo pour boot2docker )
j'utilise haveged sur Alpine pour LXC invités & sur Debian pour docker les clients. Il donne assez d'entropie pour générer des certificats gpg / ssh keys & openssl dans des conteneurs. Alpine now a un officiel docker repo .
alternativement construire un haveged paquet pour le noyau minuscule - il ya un système de construction de paquet disponible.
une autre option est d'installer le paquet rng-tools et de le mapper pour utiliser le / dev /urandom
yum install rng-tools
rngd -r /dev/urandom
avec ceci je n'ai pas eu besoin de cartographier n'importe quel volume dans le conteneur docker.