In my previous post about Docker, I focused on an introduction to networking with Docker.  That post had a fair amount of traction mainly due to it being #dockercon the week it was published, and seemingly, people had an interest in learning more about it.  Following the post, there were a few folks (@hartley and others) that pointed me to some great links about more advanced concepts in Docker and a site that validated what I was speculating with leveraging overlay tunnels as means for connectivity between nodes running Docker.

There has been a ton of information out there on Docker over the last week.  Because the impact on networking is often overlooked for new technologies, I figured I’d get a head start to understand the basics of Docker Networking.  This post documents the steps I took to test docker analyzing the network constructs that are automatically configured during container creation.

Automating the configuration, provisioning, and management of particular workflows for cloud gets a lot of attention these days.  While automation makes perfect sense for deploying workloads faster, there are also other areas where automation can be leveraged to improve the overall operational efficiency of the IT Ops team. 

If you read this site often, you already know I’ve been doing quite a bit of work with Ansible specifically as it pertains to networking.  While I will be showing another video very soon in a follow up post, I wanted to take a step back and cover a few things before doing so.  The focus here is less about the technology and more my general mindset around automation PLATFORMS, code, open source, and why I do it.  Just something I’d like to share because I’m occasionally asked questions around these topics.

When networks are deployed in a box by box model, network admins know exactly what, where, and how something is being configured.  In highly dynamic environments, this may not be the case.  This is why it’s crucial to understand what is really going on behind the scenes.  In OpenStack, there are several components that together are comprised to make OpenStack Networking (aka Neutron).  These include the Neutron server, dhcp agent, metadata agent, L3 agent, and then the agents that would reside in the infrastructure to be programmed (on either physical and/or virtual switches).  For example, in Open vSwitch deployments, there would be a Neutron OVS agent on each host/server.  And this could vary based on which particular vendor plugin is being used too!