This device services a subnet consisting of three containers – a web server, a php processor and a database – so there’s plenty of chatter.
Then I ask tshark to show me traffic on that interface: tshark -i br-0349e1f24c7a # note the interface name at the end of the line # find or grep the line that says "Gateway" and note the ip In other words: docker network inspect name_of_docker_network How do I know which of the many network interfaces to focus on? Not particularly elegant but to summarize: 1) check the docker network to see which local ip address it’s gateway is using, 2) find that ip address in a list of netowrk interfaces. This means that packets arriving at the bridge of the subnet the container lives in can be inspected from the host.įirst I will zoom in on the particular docker bridge interface of interest so as to exclude traffic from other containers. This turned out be wholly unnecessary: Docker networks interfaces do not exist in isolation of the host, they’re right there on the host as anybody who has played with docker networking on a GNOME desktop environment can attest (the network section of the settings widget becomes a bit crowded). My first idea was to put tshark inside of the container so as to be able to inspect the requests as they arrived.
Wire-/tshark are general purpose packet analyzers so the challenge here is to avoid casting a too wide net: I don’t want all the network traffic on my host, just the http headers and just those coming in and out of one particular container. Enter tshark (cue the ominous cellos), the command line version of Wireshark. Redirecting traffic from an nginx reverse proxy to a docker container I needed to add some forwarding information to the http headers – and check that it had been added.
0 kommentar(er)
