Network Automation with StackStorm and Docker

May 24, 2016
by Matthew Stone

What is StackStorm going to do with network automation? Ever since we joined Brocade, it’s been everyone’s question, and we have been hand-waving some answers. But the talk walks, code talks: let’s show something really working. Today’s example is on Docker network automation, where StackStorm makes physical networking follow Docker containers as they get created.

Millennial kids should watch my video with detailed explanations on StackStorm’s YouTube channel.

True hackers might jump straight to automation code on GitHub to see how it is built and try it out on your StackStorm instance.

Or, just read on.

The evolution of Docker networking has been fun to watch, and with the latest additions to libnetwork, things are getting even better. Docker recently added Macvlan and Ipvlan to the list of drivers for libnetwork. (Note: At the time of writing these drivers are still considered experimental) These drivers allow Docker containers to speak directly to the physical network. Getting traffic in and out of overlay networks can be a challenge. You need to implement a VTEP on the physical switch or vSwitch to communicate with the rest of the network. Docker decided to solve the problem by allowing you to send traffic tagged with a VLAN ID. Something every network engineer has done. This allows you to treat container networking similarly to how you treat virtual machine networking. I’ll leave the detailed explanation to the writeup Docker did on the subject.

Tagging container traffic means you need to coordinate your physical network configuration with your Docker configuration, and do it automatically. We use StackStorm to trigger on creating of Docker network, and fire a workflow that reconfigures the physical network using Brocade VDX switch API. Here is now it’s done, step-by step.

We started by creating a Swarm cluster, connected to a Brocade VDX switch.

As you can see this cluster has two healthy nodes and only the default networks created.

Before we get into the other details let’s briefly look at the current Ve interfaces on the Brocade VDX switch and see how that output will change based on the workflow.

These three existing Ve interfaces are for services outside of the docker deployment we’ll use in this example.

With the Swarm cluster in place I started exploring Docker’s event API. This is an HTTP based streaming API that notifies any subscribers of cluster-wide events. Things like container creation, network creation, etc get pushed to this API. I wrote a simple Sensor that subscribes to the event API and fires a Trigger when a new network is created:

Next, I created an action that pushes the needed configuration changes to the VDX. The building blocks of it is VDX pack that I auto-generated from VDX YANG model – an interesting topic that I’ll save for a separate blog. The network reconfiguration action is a workflow that uses these building blocks, and looks like this:

Lastly, I set up a Rule, to fire a workflow when the sensor fires a trigger:

So let’s create a docker network and see what happens in StackStorm and Docker. Again, watch the video to see it in action. Or, follow alone:

The previous command tells the swarm cluster to create a new network named dockernetwork112 with the subnet of 172.16.112.0/24 and pinned to the host interface eth0.112.

Lets now list the networks in the swarm cluster.

Unsurprisingly our new network is now listed and available to attach containers to. In a normal cluster this is where you would log into the physical network and create the related configuration for the network to work correctly. Since we’ve attached to the event API and have a StackStorm workflow waiting to create the network lets see what happened in the background once we created the network.

Let’s begin by showing you the execution that ran when the event API created a new network. (I got the hash value by running st2 execution list)

From the output you can see this workflow executed several actions. Creating a VE interface, creating the global VE interface, setting the IP address, no shutting the interface, and notify_success. We’ll come back to notify_success later. For now let’s look at the other actions which are all actions to send NETCONF formed XML to the VDX to have it create our configuration. If we log into the VDX again and use some show command we can see the additional configuration.

We can see here how StackStorm used the VDX action pack to push the needed configuration to the device. Reducing the time to delivery of the network and freeing up the network engineer to focus on more pressing issues.

The last piece of the workflow was the notify_success. This action sends a message into a slack channel which can notify network staff or operational staff of the net network’s availability.
This is a simple but powerful example of network automation. Enabling operational staff to capture their repetitive tasks as a workflows is an incredibly powerful concept, for network operators and devops alike. I’m personally excited to see Brocade doubling down on this event driven, workflow centric, community approach to operations. Expect to see us deliver more network automation capabilities like this over the next few months. Don’t stop there though: Use your imagination and think about how you can tie the network into your workflows!