uruchamia skrypt po dodaniu nowego interfejsu użytkownika

Question

Docker tworzy interfejs veth połączony z mostem (docker0) dla każdego z tworzonych kontenerów.

http://docs.docker.io/use/networking/

Chcę ograniczyć przepustowość te nowe veth interfejsy mają. Znalazłem sposób, aby to zrobić z cudaczem. Jednak chcę to zautomatyzować.

Czy istnieje sposób na uzyskanie haka uruchamiającego skrypt za każdym razem, gdy dołączony jest nowy interfejs veth?

Sprawdziłem, dodając skrypty w /etc/network/if-up.d/, ale nie działają, gdy veth jest dodawany tylko podczas rozruchu.

Oto niektóre syslogi tego, o czym próbuję uzyskać powiadomienie. Wiem, że mogę zakończyć te dzienniki, ale ta metoda wydaje się być trochę hackowata i musi istnieć sposób powiadomienia o tym zdarzeniu za pośrednictwem systemu operacyjnego.

May 2 23:28:41 ip-10-171-7-2 kernel: [22170163.565812] netlink: 1 bytes leftover after parsing attributes. 
May 2 23:28:42 ip-10-171-7-2 kernel: [22170163.720571] IPv6: ADDRCONF(NETDEV_UP): veth5964: link is not ready 
May 2 23:28:42 ip-10-171-7-2 kernel: [22170163.720587] device veth5964 entered promiscuous mode 
May 2 23:28:42 ip-10-171-7-2 avahi-daemon[1006]: Withdrawing workstation service for vethdc8c. 
May 2 23:28:42 ip-10-171-7-2 kernel: [22170163.743283] IPv6: ADDRCONF(NETDEV_CHANGE): veth5964: link becomes ready 
May 2 23:28:42 ip-10-171-7-2 kernel: [22170163.743344] docker0: port 27(veth5964) entered forwarding state 
May 2 23:28:42 ip-10-171-7-2 kernel: [22170163.743358] docker0: port 27(veth5964) entered forwarding state 
May 2 23:28:48 ip-10-171-7-2 kernel: [22170170.518670] docker0: port 26(vethb06a) entered forwarding state 
May 2 23:28:57 ip-10-171-7-2 kernel: [22170178.774676] docker0: port 27(veth5964) entered forwarding state 

Answer 1

Należy napisać niestandardowy udev regułę, który uruchamia skrypt twój każdym razem nowy interfejs jest dodawany. To właśnie robi Debian do obsługi interfejsu "hotplug".

/etc/udev/rules.d/90-my-networking.rules:

SUBSYSTEM=="net",   RUN+="/usr/local/bin/my-networking-agent.sh" 

/usr/local/bin/my-networking-agent.sh:

#!/bin/sh 
logger "hey I just got interface ${INTERFACE} with action ${ACTION}" 

EDIT

Oto w jaki sposób można go przetestować:

# modprobe dummy0 
# ifconfig dummy0 up 
# tail -n1 /var/log/syslog 
May 3 01:48:06 ernst logger: hey I just got interface dummy0 with action add 

Answer 2

Reguły są jednym ze sposobów, aby to zrobić, jednak istnieje pewien niedobór informacji, tj. Nie ma żadnego wiarygodnego i prostego sposobu na określenie, z którym kontenerem wiąże się veth. Nie jestem pewien, czy w twoim przypadku wystarczy ustawić limit przepustowości na końcu pary komputerów gospodarzy z veth, co może oznaczać koniec, ale jest też drugi jego koniec w przestrzeni nazw kontenera, czyli coś, co możesz sprawdzić przy użyciu poleceń ip netns lub nsenter. Jeśli więc potrzebujesz działać na obu końcach pary veth, najlepiej jest mieć identyfikator pojemnika, aby można było wyszukać PID i powiązaną z nim siećową przestrzeń nazw. Jednym ze sposobów na to jest uruchamianie docker events i analizowanie jego wyników, a jeszcze lepszym sposobem jest użycie interfejsu API gniazda Docker. W przypadku użycia, które miałem wcześniej, wystarczyło wyłapać do docker events i tutaj jest skrypt, który napisałem, co robi, to dodawanie trasy do kontenera i wyłączanie sumy kontrolnej z ethtool.

#!/bin/sh -x 

[ ! $# = 2 ] && exit 1; 

container_interface="$1" 
add_route="$2" 

docker events | while read event 
do 
    echo $event | grep -q -v '\ start$' && continue 

    container_id=`echo $event | sed 's/.*Z\ \(.*\):\ .*/\1/'` 

    nsenter="nsenter -n -t {{ .State.Pid }} --" 
    ip_route_add="ip route add ${add_route} dev ${container_interface} proto kernel scope link src {{ .NetworkSettings.IPAddress }}" 
     ethtool_tx_off="ethtool -K ${container_interface} tx off >/dev/null" 

    eval `docker inspect --format="${nsenter} ${ip_route_add}; ${nsenter} ${ethtool_tx_off};" ${container_id}` 
done 

Oprócz docker events, istnieje inny sposób połowu zdarzenia sieciowe z poleceniem ip monitor. Jednak w ten sposób nadal nie masz identyfikatorów kontenerów, podobnie jak w przypadku metody udev.