Getting Docker to work with IPv6 is an interesting and under-documented (trying to stay diplomatic) adventure, but there’s a shortcut to the promised land: even if your Docker environment is pure IPv4 morass, you can still reach published container ports over IPv6 thanks to the userland proxy I described last week. The performance is obviously commensurate with traversing kernel-user boundary too many times.
New to this rabbit hole? Start here.
Finally, you don’t have to tell me (again) that Docker is dead and we should all use K8s. It’s as useful as telling me CloudStack is dead and we should all use OpenStack. Different challenges deserve different tools.
Now let’s peek behind the curtain and explore how Docker uses iptables to publish container ports, and why it runs a userland proxy process for every published port.
For even more details, explore the Docker Networking Deep Dive webinar.
Last week I published an overview of how complex (networking-wise) Docker Swarm services can get. This time let’s focus on something that should have been way simpler: running container-based services on a single Linux host.
In the first part of this article I’m focusing on the basics, including exposed ports, and published ports. The behind-the-scenes details are coming in a week or so; in the meantime you can enjoy (most of them) in the Docker Networking Deep Dive webinar.
Good news for you – there are many fast growing overlay solutions that are adopted by apps and security teams and bypass the networking teams altogether.
That sounds awesome in a VC pitch deck. Let’s see how well that concept works out in reality using Docker Swarm as an example (Kubernetes is probably even worse).
A Docker networking rant coming from my good friend Marko Milivojević triggered a severe case of Deja-Moo, resulting in a flood of unpleasant memories caused by too-successful “disruptive” IT vendors.
Imagine you’re working for a startup creating a cool new product in the IT infrastructure space (if you have an oversized ego you would call yourself “disruptive thought leader” on your LinkedIn profile) but nobody is taking you seriously. How about some guerrilla warfare: advertising your product to people who hate the IT operations (today we’d call that Shadow IT).
One of my readers sent me this question:
It would be nice to have a blog post or a webinar describing how to implement container networking in case when: (A) application does not tolerate NAT (telco, e.g. due to SCTP), (B) no DNS / FQDN, is used to find the peer element and (C) bandwidth requirements may be tough.
One of my readers sent me a container security question after reading the Application Container Security Guide from NIST:
We are considering segregating dev/test/prod environments with bare-metal hardware. I did not find something in the standard concerning this. What should a financial institution do in your opinion?
I am no security expert and know just enough about containers to be dangerous, but there’s a rule that usually works well: use common sense and identify similar scenarios that have already been solved.
One of my readers wanted to know more about containers and wondered how ipSpace.net materials could help him. Here’s a short step-by-step guide: