Przypisz fizyczny interfejs wyłącznie do dokera

12

Chciałbym uruchomić wysokowydajny test sieci w kontenerze dokowanym i nie chcę narzutu związanego z mostowaniem (aby rurociągi nie działały AFAIK). Chciałbym przypisać (oprócz zwykłego urządzenia dokującego veth) fizyczny interfejs sieciowy 40GbE od hosta do kontenera dokującego, jak w trybie lxc „phys”. Powinno to spowodować, że interfejs fizyczny stanie się niewidoczny dla hosta.

NeilenMarais
źródło

Odpowiedzi:

4

pipework może przenieść fizyczny interfejs sieciowy z domyślnego do przestrzeni nazw sieci kontenerowej:

    $ sudo pipework --direct-phys eth1 $CONTAINERID 192.168.1.2/24

Aby uzyskać więcej informacji, zobacz tutaj .

Christoph Zauner
źródło
1
Przyjąłem tę odpowiedź, ponieważ wydaje się prosta, ale sam jej nie wypróbowałem (skorzystałem z długiej odpowiedzi, którą napisałem, zanim rurociągi zwiększyły tę funkcjonalność)
NeilenMarais,
7

Podczas poszukiwań natknąłem się na stare rozwiązania, które obejmowały przekazywanie parametrów lxc-config do dokera, ale nowsze wersje dokera nie używają już narzędzi lxc, więc to nie może działać.

Zgodnie z sugestią tutaj: https://groups.google.com/d/msg/docker-user/pL8wlmiuAEU/QfcoFcKI3kgJ znaleziono rozwiązanie. Nie zastanawiałem się nad modyfikacją skryptu pipework, jak wspomniano powyżej, zamiast bezpośredniego użycia wymaganych poleceń. Zobacz także kolejny post na blogu: http://jason.digitalinertia.net/exposing-docker-containers-with-sr-iov/ .

Do przeniesienia interfejsu z hosta do kontenera dokującego można użyć następujących poleceń niskiego poziomu (tzn. Nie związanych z dokerem) narzędzi przestrzeni nazw sieciowych

CONTAINER=slave-play # Name of the docker container
HOST_DEV=ethHOST     # Name of the ethernet device on the host
GUEST_DEV=test10gb   # Target name for the same device in the container
ADDRESS_AND_NET=10.101.0.5/24

# Next three lines hooks up the docker container's network namespace 
# such that the ip netns commands below will work
mkdir -p /var/run/netns
PID=$(docker inspect -f '{{.State.Pid}}' $CONTAINER)
ln -s /proc/$PID/ns/net /var/run/netns/$PID

# Move the ethernet device into the container. Leave out 
# the 'name $GUEST_DEV' bit to use an automatically assigned name in 
# the container
ip link set $HOST_DEV netns $PID name $GUEST_DEV

# Enter the container network namespace ('ip netns exec $PID...') 
# and configure the network device in the container
ip netns exec $PID ip addr add $ADDRESS_AND_NET dev $GUEST_DEV

# and bring it up.
ip netns exec $PID ip link set $GUEST_DEV up

# Delete netns link to prevent stale namespaces when the docker
# container is stopped
rm /var/run/netns/$PID

Niewielkie zastrzeżenie dotyczące interfejsu, jeśli twój host ma wiele urządzeń ethX (mój miał eth0 -> eth5). Na przykład powiedz, że przenosisz eth3 do kontenera jako eth1 w przestrzeni nazw kontenerów. Gdy zatrzymasz kontener, jądro spróbuje przenieść urządzenie eth1 kontenera z powrotem na host, ale zauważ, że istnieje już urządzenie eth1. Następnie zmieni nazwę interfejsu na coś dowolnego; zajęło mi trochę czasu, aby go znaleźć ponownie. Z tego powodu edytowałem /etc/udev/rules.d/70-persistent-net.rules (myślę, że ta nazwa pliku jest wspólna dla większości popularnych dystrybucji Linuksa; używam Debiana), aby nadać interfejsowi unikalną, niepowtarzalną nazwę i użyj tego zarówno w kontenerze, jak i na hoście.

Ponieważ nie używamy dokera do wykonania tej konfiguracji, standardowe narzędzia cyklu życia dokera (np. Uruchomienie dokera --restart = w przypadku awarii: 10 ...) nie mogą być użyte. Na omawianej maszynie działa Debian Wheezy, więc napisałem następujący skrypt inicjujący:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          slave-play
# Required-Start:    $local_fs $network $named $time $syslog $docker
# Required-Stop:     $local_fs $network $named $time $syslog $docker
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Description:       some slavishness
### END INIT INFO

CONTAINER=slave-play
SCRIPT="docker start -i $CONTAINER"
RUNAS=root

LOGFILE=/var/log/$CONTAINER.log
LOGFILE=/var/log/$CONTAINER.log

HOST_DEV=test10gb
GUEST_DEV=test10gb
ADDRESS_AND_NET=10.101.0.5/24


start() {
  if [ -f /var/run/$PIDNAME ] && kill -0 $(cat /var/run/$PIDNAME); then
echo 'Service already running' >&2
return 1
  fi
  echo 'Starting service…' >&2
  local CMD="$SCRIPT &> \"$LOGFILE\" &"
  su -c "$CMD" $RUNAS 
  sleep 0.5 # Nasty hack so that docker container is already running before we do the rest
  mkdir -p /var/run/netns
  PID=$(docker inspect -f '{{.State.Pid}}' $CONTAINER)
  ln -s /proc/$PID/ns/net /var/run/netns/$PID
  ip link set $HOST_DEV netns $PID name $GUEST_DEV
  ip netns exec $PID ip addr add $ADDRESS_AND_NET dev $GUEST_DEV
  ip netns exec $PID ip link set $GUEST_DEV up
  rm /var/run/netns/$PID
  echo 'Service started' >&2
}

stop() {
  echo "Stopping docker container $CONTAINER" >&2
  docker stop $CONTAINER
  echo "docker container $CONTAINER stopped" >&2
}


case "$1" in
  start)
start
;;
  stop)
stop
;;
  restart)
stop
start
;;
  *)
echo "Usage: $0 {start|stop|restart}"
esac

Nieco zuchwały, ale działa :)

NeilenMarais
źródło
Dlaczego zaczynają się nazwy interfejsów sieciowych eth? Czy Debian nie robi spójnych nazw urządzeń sieciowych?
Michael Hampton,
Dla każdego, kto zastanawia się, dlaczego dowiązanie symboliczne /var/run/netns/$PIDjest potrzebne: potrzebujesz go do działania ip netns exec $PID ...poleceń.
Donn Lee
2

W tym celu piszę wtyczkę sieci dokującej.

https://github.com/yunify/docker-plugin-hostnic

docker pull qingcloud/docker-plugin-hostnic
docker run -v /run/docker/plugins:/run/docker/plugins -v /etc/docker/hostnic:/etc/docker/hostnic --network host --privileged qingcloud/docker-plugin-hostnic docker-plugin-hostnic
docker network create -d hostnic --subnet=192.168.1.0/24 --gateway 192.168.1.1 hostnic
docker run -it --ip 192.168.1.5 --mac-address 52:54:0e:e5:00:f7 --network hostnic ubuntu:14.04 bash
Jolestar
źródło