Setting up a network automation development environment is an interesting task:
- You have to install a half-dozen tools, each one with tons of dependencies;
- SSH libraries like paramiko have to installed manually;
- Ansible modules for individual network devices might need extra libraries;
- Parsing tools invoked with Ansible Jinja2 filters have to be installed separately;
- Add your pet peeve here ;)
Now imagine having to do that for a dozen networking engineers and software developers working on all sorts of semi-managed laptops. Containers seem to be one of the sane solutions1.
TL&DR: If you happen to like working with containers, you could use netsim-tools release 0.5 to provision your container-based Arista EOS labs.
Why does it matter? Lab setup is blindingly fast, and it’s easier to integrate your network devices with other containers, not to mention the crazy idea of running your network automation CI pipeline on Gitlab CPU cycles. Also, you could use the same netsim-tools topology file and provisioning scripts to set up container-based or VM-based lab.
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 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: