Le sous-système "net/core" est enregistré par espace de noms de réseau. Et la valeur initiale de somaxconn est définie sur 128.
Lorsque vous faites sysctl sur le système hôte, il définit les paramètres de base pour son l'espace de noms réseau, qui appartient à init . (il s'agit essentiellement de l'espace de noms par défaut). Cela n'affecte pas les autres espaces de noms de réseau.
Lorsqu'un conteneur Docker est démarré, l'interface réseau virtuelle (s'affiche sous la forme vethXXX sur l'hôte) de ce conteneur est attaché à son propre espace de noms, qui a toujours la valeur somaxconn initiale de 128. Donc, techniquement, vous ne pouvez pas propager cette valeur dans le conteneur, car les deux espaces de noms réseau ne la partagent pas.
Il existe cependant deux façons d'ajuster cette valeur, en plus d'exécuter le conteneur en mode privilégié.
-
utilisez "--net host" lors de l'exécution du conteneur, il utilise donc l'interface réseau de l'hôte et partage donc le même espace de noms réseau.
-
vous pouvez monter le système de fichiers proc en lecture-écriture à l'aide de la prise en charge du mappage de volume de Docker. l'astuce consiste à le mapper sur un volume NON nommé "/proc", puisque Docker remontera /proc/sys, entre autres, en lecture seule pour les conteneurs non privilégiés. Cela nécessite que l'hôte monte /proc en tant que rw, ce qui est le cas sur la plupart des systèmes.
docker run -it --rm -v /proc:/writable-proc ubuntu:14.04 /bin/bash [email protected]:/# echo 1024 > /writable-proc/sys/net/core/somaxconn [email protected]:/# sysctl net.core.somaxconn net.core.somaxconn = 1024
La méthode 2 devrait fonctionner sur Elastic Beanstalk via sa prise en charge du mappage de volume dans Dockerrun.aws.json. Cela devrait également fonctionner pour d'autres paramètres réglables sous /proc qui sont par espace de noms. Mais il s'agit très probablement d'un oubli de la part de Docker, ils peuvent donc ajouter une validation supplémentaire sur le mappage de volume et cette astuce ne fonctionnera alors pas.
Mise à jour :cette réponse est obsolète car Docker prend désormais en charge le docker run --sysctl !
La solution que j'utilise pour mon conteneur OpenVPN est d'entrer dans l'espace de noms du conteneur avec toutes les fonctionnalités en utilisant nsenter , remontage /proc/sys lecture-écriture temporaire, configuration des éléments et remontage en lecture seule.
Voici un exemple, activant le transfert IPv6 dans le conteneur :
CONTAINER_NAME=openvpn
# enable ipv6 forwarding via nsenter
container_pid=`docker inspect -f '{{.State.Pid}}' $CONTAINER_NAME`
nsenter --target $container_pid --mount --uts --ipc --net --pid \
/bin/sh -c '/usr/bin/mount /proc/sys -o remount,rw;
/usr/sbin/sysctl -q net.ipv6.conf.all.forwarding=1;
/usr/bin/mount /proc/sys -o remount,ro;
/usr/bin/mount /proc -o remount,rw # restore rw on /proc'
De cette façon, le conteneur n'a pas besoin de s'exécuter en mode privilégié.
docker 1.12 ajoute la prise en charge de la définition de sysctls avec --sysctl.
docker run --name some-redis --sysctl=net.core.somaxconn=511 -d redis
docs :https://docs.docker.com/engine/reference/commandline/run/#/configure-namespaced-kernel-parameters-sysctls-at-runtime
J'ai trouvé une solution :
{
"AWSEBDockerrunVersion": "1",
"Command": "run COMMAND",
"Image": {
"Name": "crystalnix/omaha-server",
"Update": "true"
},
"Ports": [
{
"ContainerPort": "80"
}
]
}
plus de détails ici :/opt/elasticbeanstalk/hooks/appdeploy/pre/04run.sh
Mise à jour :
Ajouter le fichier .ebextensions/02-commands.config
container_commands:
00001-docker-privileged:
command: 'sed -i "s/docker run -d/docker run --privileged -d/" /opt/elasticbeanstalk/hooks/appdeploy/pre/04run.sh'