Category: Docker

Feedback: Docker Networking Deep Dive

While the pundits keeps telling me Docker is dead (looking at its documentation I would say they’re right) and Kubernetes it the way to go (yay!), some people still have to deal with Docker networking, and at least some of them found the Docker Networking Deep Dive webinar useful. Here’s a recent review:

You can scroll over internet pages as long as you can, you will rarely find this kind of specialized knowledge. This is the next level in term of knowledge about Docker.

If you belong to the “Kubernetes will rule the world” camp, we have you covered as well: Stuart Charlton created a phenomenal Kubernetes Networking Deep Dive webinar (approximately half of it is already accessible with free subscription).

add comment

Running Network Automation Tools in a Container

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.

read more see 2 comments

Accessing Docker Container Services over IPv6

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.

add comment

Docker Services 101

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.

add comment

Docker Swarm Services behind the Scenes

Remember the claim that networking is becoming obsolete and that everyone else will simply bypass the networking teams (source)?

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).

read more see 2 comments

The Cost of Disruptiveness and Guerrilla Marketing

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.

Before moving on, please note that the following observations were made from my outsider perspective. If I got something badly wrong, please correct me in a comment.

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).

read more see 3 comments

Container Security through Segregation

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.

read more see 3 comments
Sidebar