El subsistema "net/core" se registra por espacio de nombres de red. Y el valor inicial de somaxconn se establece en 128.
Cuando hace sysctl en el sistema host, establece los parámetros principales para its espacio de nombres de red, que es propiedad de init . (básicamente, este es el espacio de nombres predeterminado). Esto no afecta a otros espacios de nombres de red.
Cuando se inicia un contenedor Docker, la interfaz de red virtual (aparece como vethXXX en el host) de ese contenedor se adjunta a su propio espacio de nombres, que todavía tiene el valor somaxconn inicial de 128. Por lo tanto, técnicamente, no puede propagar este valor en el contenedor, ya que los dos espacios de nombres de red no lo comparten.
Sin embargo, hay dos formas de ajustar este valor, además de ejecutar el contenedor en modo privilegiado.
-
use "--net host" cuando ejecute el contenedor, por lo que usa la interfaz de red del host y, por lo tanto, comparte el mismo espacio de nombres de red.
-
puede montar el sistema de archivos proc como lectura y escritura utilizando el soporte de asignación de volumen de Docker. el truco consiste en asignarlo a un volumen que NO se llame "/proc", ya que Docker volverá a montar /proc/sys, entre otros, como de solo lectura para contenedores sin privilegios. Esto requiere que el host monte /proc como rw, que es el caso en la mayoría de los sistemas.
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
El método 2 debería funcionar en Elastic Beanstalk a través de su soporte de asignación de volumen en Dockerrun.aws.json. También debería funcionar para otros parámetros ajustables en /proc que es por espacio de nombres. Pero lo más probable es que esto sea un descuido por parte de Docker, por lo que pueden agregar una validación adicional en el mapeo de volúmenes y este truco no funcionará entonces.
Actualización:esta respuesta está obsoleta ya que Docker ahora es compatible con docker run --sysctl opción!
La solución que uso para mi contenedor OpenVPN es ingresar el espacio de nombres del contenedor con todas las capacidades usando nsenter , volviendo a montar /proc/sys lectura y escritura temporalmente, configurando cosas y volviendo a montarlas como solo lectura nuevamente.
Aquí un ejemplo, habilitando el reenvío de IPv6 en el contenedor:
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 esta manera, el contenedor no necesita ejecutarse con privilegios.
docker 1.12 agrega soporte para configurar sysctls con --sysctl.
docker run --name some-redis --sysctl=net.core.somaxconn=511 -d redis
documentos:https://docs.docker.com/engine/reference/commandline/run/#/configure-namespaced-kernel-parameters-sysctls-at-runtime
Encontré una solución:
{
"AWSEBDockerrunVersion": "1",
"Command": "run COMMAND",
"Image": {
"Name": "crystalnix/omaha-server",
"Update": "true"
},
"Ports": [
{
"ContainerPort": "80"
}
]
}
más detalles aquí:/opt/elasticbeanstalk/hooks/appdeploy/pre/04run.sh
Actualización:
Añadir archivo .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'