Docker Networking
No, not the social activity. This is about hardcore bit shipping: ports, IP addresses, routing tables, etc. in the context of (Docker) containers.
Tim Hockin (Google) recently gave a presentation on Kubernetes. The part where he shared Google’s design decisions around networking in the context of (Docker) containers made me think. Think about where we are concerning SDN when doing Docker. Here’s what I’ve figured so far …
Before we dive into the topic, I strongly encourage you to watch above YouTube video of Tim’s talk, especially the part around networking, starting at around 10:15 min into the talk.
OK, now you know about the basics, right? In a nutshell: you want to enable the containers to see each other and be able to communicate with each other but don’t want to rely on non-scalable methods such as NAT. So, you may end up picking one of the available (FOSS) SDN solutions to address the problem.
First, Docker’s stance: https://docs.docker.com/articles/networking/ and in fact, Docker (the company) recently went a step further by acquiring the SDN start-up SocketPlane. I suppose we can expect more native support here, going forward, as a result of this acquisition.
In the following just a simple listing of SDN solutions relevant for Docker networking. Know of more? Please comment here or let me know via Twitter.
Open vSwitch
Open vSwitch is a multilayer virtual switch licensed under the open source Apache 2.0 license, designed to enable massive network automation through programmatic extension, while still supporting standard management interfaces and protocols (e.g. NetFlow, sFlow, IPFIX, RSPAN, CLI, LACP, 802.1ag). In addition, it is designed to support distribution across multiple physical servers similar to VMware’s vNetwork distributed vswitch or Cisco’s Nexus 1000V.
Weave — the Docker network
Weave creates a virtual network that connects Docker containers deployed across multiple hosts. Applications use the network just as if the containers were all plugged into the same network switch, with no need to configure port mappings, links, etc. Services provided by application containers on the weave network can be made accessible to the outside world, regardless of where those containers are running. Similarly, existing internal systems can be exposed to application containers irrespective of their location.
Weave can traverse firewalls and operate in partially connected networks. Traffic can be encrypted, allowing hosts to be connected across an untrusted network. Weave works alongside Docker’s existing (single host) networking capabilities, so these can continue to be used by containers.
Pipework — Software-Defined Networking for Linux Containers
Pipework lets you connect together containers in arbitrarily complex scenarios. Pipework uses cgroups and namespace and works with “plain” LXC containers (created with lxc-start), and with the awesome Docker.
Flannel
flannel (originally rudder) is an overlay network that gives a subnet to each machine for use with Kubernetes.
Where next? You might also want to have a look at the Kubernetes networking approach and check out a rather useful hands-on walkthrough I stumbled upon, called Multi-host Docker Network.
UPDATE 1: Kudos to Patrick (Member of Technical Staff, Docker) who suggested a few more additions:
UPDATE 2: Project Atomic also provided an update on their Docker networking approach:
