i have 2 containers by docker, and bridge like this:
root@venus-166:~# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ef99087167cb images.docker.sae.sina.com.cn/ubuntu:latest /bin/bash -c /home/c 2 days ago Up 21 minutes 0.0.0.0:49240->22223/tcp night_leve3
c8a7b18ec20d images.docker.sae.sina.com.cn/ubuntu:latest /bin/bash -c /home/c 2 days ago Up 54 minutes 0.0.0.0:49239->22223/tcp night_leve2
bridge name bridge id STP enabled interfaces
docker0 8000.72b675c52895 no vethRQOy1I
vethjKYWka
How can i get which container match veth*
?
ef99 => vethRQOy1I or ef99 => vethjKYWka
//----------------------------------------------------------
I know it works by ethtool
, but is there any better way?
I don't know how to get it properly, but you use a hack: you can scan the syslog for added interfaces after you run your container:
Try this script:
Explains:
container
.NetworkMode
ishost
,none
, orcontainer:<name|id>
(sharenetwork stack
with another container's. For example:user's
containers in onepod
in kubernetes share thenetwork stack
with thepause pod
container'snetwork stack
)Here's a variation on the ethtool trick mentioned above, without actually using ethtool:
If anyone is still interested in this. I found this on the docker mailing list: http://permalink.gmane.org/gmane.comp.sysutils.docker.user/3182
There are multiple "hackish" ways to do it:
LOG
rule.The last option is, IMHO, the more reliable one (and the easiest to use), but it's still very hackish. The idea is very simple:
Add an iptables rule to log e.g. ICMP traffic arriving on the Docker bridge:
sudo iptables -I INPUT -i docker0 -p icmp -j LOG
Send a ping to the container you want to identify:
IPADDR=$(docker inspect -format='{{.NetworkSettings.IPAddress}}' 0c33)
ping -c 1 $IPADDR
Check kernel logs:
dmesg | grep $IPADDR
You will see a line looking like this:
[…] IN=docker0 OUT= PHYSIN=vethv94jPK MAC=fe:2c:7f:2c:ab:3f:42:83:95:74:0b:8f:08:00 SRC=172.17.0.79 …
If you want to be fancy, just extract
PHYSIN=…
with awk or sed.Remove the iptables logging rule (unless you want to leave it there because you will regularly ping containers to identify them).
If you need a bullet-proof version, you can install
ulogd
and use theULOG
target. Instead of just writing packet headers to the kernel log, it will send them through a netlink socket, and a userland program can then process them properly.