With the release of Docker 1.9, Docker has eliminated many of the challenges of container networking. But, Project Calico is another unique option.
I've spoken to the complexity of Docker networking in the past, and now Docker 1.9 introduces a new model. Docker Networking supports the pluggable tenant of Docker management. Opposed to creating a static way of creating and managing networks, Docker creates a network namespace that developers can consume.
On the backend, network vendors can insert their specific technologies to manage networks. Most vendors take an overlay approach via network virtualization. Although, Project Calico takes a pure Layer 3 approach to Docker networking.
Docker has the "batteries included" model, which means there's a basic solution included as part of the Docker platform. Docker eliminated many of the previous challenges associated with cross host communication. In Docker 1.9, the platform allows creation of a network overlay that spans multiple hosts. The network overlay setup is very similar to how VMware approaches networking in its NSX product.
The use of overlays versus Docker's previous Links concept means developers have to take an additional step and have some understanding of networking. Docker believes the advantages are worth the additional effort. Docker lists the advantages of the network overlay as follows:
- Connect containers to each other across different physical or virtual hosts
- Containers using Networking can be easily stopped, started, and restarted without disrupting the connections to other containers
- You don't need to create a container before you can link to it. With Networking, containers [can] be created in any order and discover each other using their container names.
As with most Docker subsystems, the vendor ecosystem can offer alternatives. The alternatives I've encountered have primarily been other overlay solutions. But, Project Calico takes a more traditional networking approach.
Introduction to Project Calico
Project Calico is an open source project that plugs into Docker. Jon Berger, evangelist for Project Calico, appeared on a recent episode of The Cloudcast Podcast discussing Docker Networking, and the complexity of an overlay versus pure Layer 3 networking. Instead of creating an overlay, Calico leverages an agent on each Docker host to provide IP addressing for each container.
Network I/O is provided by the native Linux Kernel. By leveraging the native Linux Kernel, Project Calico users can leverage existing network tools, including IP-Tables, to perform micro-segmentation. Berger claims customers have seen the side benefit of creating micro-services that leverage a similar network model seen in AWS.
AWS networking also leverages Layer 3 connectivity between containers. By default, an explicit rule must be created to allow instance-to-instance communication in AWS. Docker users who implement the Project Calico plugin can leverage the familiar model.
On a surface level, the plugin nature of Docker Networking adds great flexibility. However, with great flexibility comes complexity. As I think about one of the primary advantages of Docker--portability--how do the drastically different approaches in networking impact portability?
From a practical sense, the same API calls are used to create Docker instances and networks. However, additional burdens appear as data center managers need to ensure hosts contain the correct agents and dependencies to support plugins such as Cisco ACI, VMware, and Project Calico. As container hosts move to cloud instances, the challenges compound.
What do you think?
I'd like to hear your feedback. Am I off? Does the network flexibility come at a minimum cost, or are all of the network plugins coupled with storage and management plugins making Docker less portable?
- Pro Tip: A DevOps approach to network changes (TechRepublic)
- IPv6: The smart person's guide (TechRepublic)
- Let's Encrypt wants to use open source to simplify the security certificate process (TechRepublic)
- Screenshots: Five easy-to-use IP traffic monitors (TechRepublic)