A tricky topic... Container networking can feel like magic at times. But it's not!
Rather it's a bunch of more primitive "LEGO bricks" like net namespaces, veth pairs, and bridges combined into a handy (but complex) higher-level abstraction.
Through the networking lens, every container represents a tiny little server with its own IP address.
Containers on a single host are attached to the same bridge (aka virtual switch) and can talk to each other on L2 (Ethernet) and L3 (IP) layers.
While packet routing between containers on a single host is often trivial, forwarding traffic originated in containers to the outside world and vice versa is trickier.
Typically, it's solved with a bunch of iptables rules.
Docker (rightfully) doesn't allow that. So, what are the options?
- Restart it, potentially from a committed state 🥱
- Modify container's configs and restart dockerd 🙈
- Call <container_ip>:<port>
- Write some iptables
...or 👇
Brush up your containers and networking skills and create an elegant solution!
- Containers in the same network can talk to each other using their IP addresses
- You can "connect" any two sockets using a user-space proxy like socat
Solution: create a helper forwarder sidecar!
By publishing a sidecar's port to the host and using a proxy process to forward data between this port and the target container, you're efficiently publishing the target's port (with an extra hop).
Works in many runtimes:
- Docker Engine & Desktop & Compose
- containerd, nerdctl
I work with containers a lot, and they often misbehave. My typical debugging needs include:
- Running an interactive shell in a container
- Using not-installed debugging tools
- Forwarding container ports to the host system
- etc.
I researched the available tools and non of them satisfied my needs fully.
My criteria:
- Portability: one tool for many runtimes (docker, containerd, k8s).
- Completeness: one tool for exec, net, and fs use cases.
- Unified UX: different runtimes but same command behavior.
Need to get into networking but all materials you find feel like they are written for bearded networking gurus?
I've got a bunch of "different" articles for you! Written by a developer for fellow developers 👇
1. Computer Networking Introduction: Ethernet and IP
A heavily-illustrated comic-like article - a foundation for further learning. I wish I had something like it when I was studying the networking basics in college.