Aktualisieren Sie net.core.somaxcomm (oder eine beliebige sysctl-Eigenschaft) für Docker-Container

Das Subsys "net/core" wird pro Netzwerk-Namespace registriert. Und der Anfangswert für somaxconn ist auf 128 gesetzt.

Wenn Sie sysctl auf dem Hostsystem ausführen, werden die Kernparameter für sein festgelegt Netzwerk-Namespace, der init gehört . (im Grunde ist dies der Standard-Namespace). Dies wirkt sich nicht auf andere Netzwerk-Namespaces aus.

Wenn ein Docker-Container gestartet wird, wird die virtuelle Netzwerkschnittstelle (wird als vethXXX angezeigt auf dem Host) dieses Containers an seinen eigenen Namensraum angehängt, der immer noch den anfänglichen somaxconn-Wert von 128 hat. Technisch gesehen können Sie also nicht weitergeben diesen Wert in den Container, da die beiden Netzwerk-Namespaces ihn nicht teilen.

Es gibt jedoch zwei Möglichkeiten, diesen Wert anzupassen, zusätzlich zum Ausführen des Containers im privilegierten Modus.

1. Verwenden Sie "--net host", wenn Sie den Container ausführen, damit er die Netzwerkschnittstelle des Hosts verwendet und daher denselben Netzwerk-Namespace verwendet.

2. Sie können das proc-Dateisystem mit der Volume-Mapping-Unterstützung von Docker mit Lese-/Schreibzugriff mounten. Der Trick besteht darin, es einem Volume zuzuordnen, das NICHT „/proc“ heißt, da Docker unter anderem /proc/sys als schreibgeschützt für nicht privilegierte Container neu einhängen wird. Dies erfordert, dass der Host /proc als rw einhängt, was auf den meisten Systemen der Fall ist.

   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
   

Methode 2 sollte auf Elastic Beanstalk über die Volume-Mapping-Unterstützung in Dockerrun.aws.json funktionieren. Es sollte auch für andere einstellbare Parameter unter /proc funktionieren, die pro Namespace sind. Dies ist jedoch höchstwahrscheinlich ein Versehen von Docker, sodass sie möglicherweise eine zusätzliche Validierung der Volume-Zuordnung hinzufügen und dieser Trick dann nicht funktioniert.

Update:Diese Antwort ist veraltet, da Docker jetzt den docker run --sysctl unterstützt Option!

Die Lösung, die ich für meinen OpenVPN-Container verwende, besteht darin, den Container-Namespace mit vollen Funktionen mit nsenter einzugeben , Wiedereinhängen von /proc/sys temporär lesen-schreiben, Dinge einrichten und wieder schreibgeschützt einhängen.

Hier ein Beispiel zum Aktivieren der IPv6-Weiterleitung im Container:

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'

Auf diese Weise muss der Container nicht privilegiert ausgeführt werden.

Docker 1.12 fügt Unterstützung für das Setzen von sysctls mit --sysctl hinzu.

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

Ich habe eine Lösung gefunden:

{
    "AWSEBDockerrunVersion": "1",
    "Command": "run COMMAND",
    "Image": {
        "Name": "crystalnix/omaha-server",
        "Update": "true"
    },
    "Ports": [
        {
            "ContainerPort": "80"
        }
    ]
}

Weitere Details hier:/opt/elasticbeanstalk/hooks/appdeploy/pre/04run.sh

Aktualisierung:

Datei .ebextensions/02-commands.config hinzufügen

container_commands:
    00001-docker-privileged:
        command: 'sed -i "s/docker run -d/docker run --privileged -d/" /opt/elasticbeanstalk/hooks/appdeploy/pre/04run.sh'