Scratching the container networking itch
Muhammad Kamran Azeem
Kamran is a Senior Consultant in Infrastructure and Security from our Oslo office. Before moving to Norway he was a Senior Engineer working with HPC clusters. Kamran likes to be prepared for any eventuality and takes multi-tools with him wherever he goes. If it’s broken he can fix it.
What to do when you need more than just ping to reach a container.
The itch
We know that the idea behind a Docker container is that it should have just enough software to run a particular process or service. For example a web server, Java application server or database server.
Images are designed to be very minimalistic and lean in nature. If a container should only run a single process all its life, why bother filling it up with unused software? Great! But because they are lean, they can also be difficult to troubleshoot.
I have many times needed more than just ping to reach a container running on a particular host on a particular container network.
Recently I was working on a Kubernetes cluster with service names set up using the SkyDNS addon. But I was not able to resolve the service names. I had nginx running as a container and being minimalistic by nature, it had no tools inside it except ping. I installed nslookup with the usual apt-get update and apt-get install dnsutils. But it was still not giving me enough information about name resolution. I was not until I installed dig that I figured out what was going on. It took me many container starts and apt-get commands before things got clear.
It was a nasty itch and I needed a solution.
The solution
Being a big fan and user of multitools, such as the Leatherman Wave that I carry with me as EDC, I wanted a container image with all the necessary tools installed in it. One I could use at will, without getting into the apt-get mess. I also wanted the image to run as a standard pod, so I could achieve two things:
I would always have a web service to test my connections
I would just
docker exec bashinto it and not have to remember complexkubectlcommands to run it in interactive mode
I went ahead and created praqma/network-multitool. I am a Red Hat fan so I based my image on centos:7 . Initially I had Apache as web server, but later I replaced it with nginx - it is very light weight and fast.
Example usage
The image can be used in any container environment. Here are a few examples of how you can use it.
On a Docker host
Interactive:
[kamran@kworkhorse ~]$ docker run --rm -it praqma/network-multitool bash[root@92288413e051 /]# nslookup yahoo.comServer: 192.168.100.1Address: 192.168.100.1#53Non-authoritative answer:Name: yahoo.comAddress: 98.138.253.109Name: yahoo.comAddress: 98.139.183.24Name: yahoo.comAddress: 206.190.36.45[root@92288413e051 /]#Detached:
[kamran@kworkhorse ~]$ docker run -P -d praqma/network-multitoola76d156c674f2b61c9b9fb10f87c645620c4fcbe88a13162546379abc9a87f14[kamran@kworkhorse ~]$ docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESa76d156c674f praqma/network-multitool "/start_nginx.sh" 31 seconds ago Up 30 seconds 0.0.0.0:32769->80/tcp, 0.0.0.0:32768->443/tcp silly_franklin[kamran@kworkhorse ~]$ docker exec -it silly_franklin bash[root@a76d156c674f /]# curl -I yahoo.comHTTP/1.1 301 RedirectDate: Sun, 16 Apr 2017 16:09:20 GMTVia: https/1.1 ir28.fp.ne1.yahoo.com (ApacheTrafficServer)Server: ATSLocation: https://www.yahoo.com/Content-Type: text/htmlContent-Language: enCache-Control: no-store, no-cacheConnection: keep-aliveContent-Length: 304[root@a76d156c674f /]#In a Kubernetes cluster
First run the container image as a deployment:
[kamran@kworkhorse ~]$ kubectl run multitool --image=praqma/network-multitooldeployment "multitool" created[kamran@kworkhorse ~]$Then find the pod name and connect to it in interactive mode:
[kamran@kworkhorse ~]$ kubectl get podsNAME READY STATUS RESTARTS AGEmultitool-2814616439-hd8p6 1/1 Running 0 1m[kamran@kworkhorse ~]$ kubectl exec -it multitool-2814616439-hd8p6 bash[root@multitool-2814616439-hd8p6 /]# traceroute google.comtraceroute to google.com (64.233.184.102), 30 hops max, 60 byte packets 1 gateway (10.112.1.1) 0.044 ms 0.014 ms 0.009 ms 2 wa-in-f102.1e100.net (64.233.184.102) 0.716 ms 0.701 ms 0.896 ms[root@multitool-2814616439-hd8p6 /]# exitexit[kamran@kworkhorse ~]$Summary
Creating this network multitool image has completely soothed my itch. Now I use it to solve all sorts of problems. Packet capture, telnet, traceroute, mtr, dig, netstat, curl - you name it! I hope you will enjoy using this multitool as much as we do at Praqma.
- Cloud
Subscribe to our newsletter
Related blogs