You might be asking yourself why a network engineer would be concerning himself with a product like Chef. It’s a long story, but lets start by saying that my interest was first peaked when I heard that the new line of Cisco Nexus switches would have a integrated Chef client. I’ve known about Chef and Puppet for a long time, but I’ve never really sat down and looked to see how they worked. So rather than starting with Chef on Nexus, I thought it would be prudent to get some base experience with the application in a more ‘normal’ application.
So how does this fit into networking? I think we can all agree that data center networking can change. I’m carefully phrasing that statement by using the word ‘can’. If you don’t know it already, I don’t buy the ‘SDN will change everything you do’ line of thinking. In fact, I try as hard as I can not even to use the term SDN. Why? Because it’s far too vague of a term that can mean almost anything depending on you how you want to interpret it. Beyond being a catch phrase , it really doesn’t mean much to me.
I like to think that this next generation of networking really boils down to how we tell the control plane what to do. AKA, having a more intelligent network that can act and react based on things that don’t happen or aren’t visible in a single switches local control plane. How this is done is up to you. Many vendors are coming up with controller based solutions to solve this. But the base premise is that there’s a higher level policy model that tells nodes (switches, servers, routers, etc.) what to do. A key piece of this is keeping that policy model generic enough to be used repetitively and without having to write custom code for custom objects. If you can ask a device to do something and have it perform its own local logic to complete that task, then you have what boils down to an abstraction layer. Boiled down further, you end up with the ability to scale exponentially higher than you could have before with just local control and policy on each node or device.
So how does Chef tie in? Simple, Chef lets you set policy on an end node based on all sorts of attributes. When we start looking at Chef, we’ll start by using a Linux server as the node. You’ll see that I can set a base policy for how I want the node to behave. This includes what files I want on the server, what applications I want installed, and lots of other attributes. Each time the Chef client is run, the node checks in with the server to make sure its local policy still matches with what the server says it should be. If a file changes, it downloads the new one, if the applications change, it installs or uninstalls. Not only does this give you the ability to quickly provision nodes, it also gives you the ability to ensure that nodes stay in compliance on an ongoing basis. So would this example be a full abstraction? Likely not. Some commands and attributes will depend on the OS the server is running. However, this is a step in the right direction so its certainly worth checking out.
In the networking world, I can see this as being a powerful tool for device configuration and base policy management. On top of that, this gives us another option on how we interact with the network. I’m a big believer in having options and I don’t think there’s a silver bullet (yet) for how to manage network devices. The next series of posts will include how to install Chef server, Chef Client, and interact with Chef using he knife command from the Chef client. I’m hoping after we get some experience with Chef on a server, we can see how it works on the Nexus 9k.
Stay tuned!