These tools can Automate tasks themselves for common networks, or they can be setup to speak directly to an SDN Controller, that then has connectivity to the entire network to automate these tasks as communicated by the Tool (Ansible / Puppet / Chef).
SaltStack will be mentioned occasionally in this post, but not covered in any depth here.
Note that for these to work, you do need a Linux based server (I prefer Ubuntu) to push out the Automation Tasks, and like and API for communication, so there is still quite a bit of work and understanding outside of just knowing these exist to get them working!
Benefits of Automation Tools
- Remove need for node by node management
- Centralize tasks of configuration or software management
- Allow for Day-0 Provisioning / Zero-Touch provisioning
- Create resources (configurations) that can be pushed out to all network devices at once vs node by node (bullet point #1)
- Have the flexibility of scheduling changes, or creating them to run immediately
The Top Contenders for Automation Tools: Ansible, Chef, Puppet, and SaltStack
I am not including SaltStack here as it has a ways to go yet to be considered a real contender, however the following is a look of some commonalities between Ansible / Puppet / Chef to Automate your networks!
- All tools require some kind of CLI experience, whether it be Cisco IOS or something like YAML (Ansible) or Ruby (Chef I believe)
- Many of these tools also include a GUI for ease of use of scripts you must build to automate the tasks desired to be executed
- There are different ways in each programs GUI References the script being called out to execute on the network devices
Masters and Agents
Most programming tools have two mechanisms to communicate, a Master which resides on the Automation Server, and an Agent that resides on each node it controls awaiting input from the Automation server.
Ansible’s one big claim to fame is that it is the “Agentless” solution, meaning of course it does not require Agents be placed on all your network nodes to Automate network tasks, which if learning this for a quiz may be easy points on exam day!
Puppet does have a kind of solution that it is calling “Agentless” where the Agent is not built into the IOS Software, but rather some sort of an extra device that is plugged into the node that receives input from the Puppet server, then translates it to SSH / CLI commands into the IOS device – I personally would not call an extra piece of hardware translating Automation (another point of failure in the network) an Agentless solution but Puppet is trying to compete in this Arena.
CHEF and Puppet both refer to the model as Master / Agent, however SaltStack calls it Masters and Minions, which I thought was worth mentioning as I find that hilarious 🙂
The Push and Pull models
There are two different models of doing things with Masters / Agents on the network:
Push – The “Push” changes come down from the Master to the Agents, can be immediate or scheduled for a defined time. The “Push” model is preferred for network impacting changes, as you can be there if anything doesn’t go as planned to troubleshoot.
Ansible and SaltStack use the Push Model.
Pull – Using this method the Agents “Poll” the Master intermittently to detect changes meant for Agents (like configuration changes), so its almost like SNMP in reverse where Routers / Switches would check in with the SNMP Collector.
This model is obviously undesirable in the way that if a device for any reason misses a “Poll” to the Master during a change / update, the device may be missing a configuration / unreachable / everyone panicking until it can Poll the Master again to “Pull” the change.
Puppet and Chef use the Pull Model.
First things first with using any of these tools – Creating the configuration file!
The file name will depend on the tool used, as some will come them files while others will be modules, however they all have the same basic goal – That it properly calls out other configurations for network devices properly to Automate the network.
These other variable device configs is something that will need to be coded / scripted in advance, so that it can be coded / scriped into the Config File / Module / Manifest / Whatever it may be called that starts up and assigns the network its configurations.
YAML is used for Ansible and SaltStack, which all have repositories with template modules / manifests that are a base configuration for code, that you can then fill in with your own configurations for devices and protocols.
YAML is the coding language largely preferred to work with because they use logic that the human mind can grasp, whereas other languages are a bit more complex, and are more geared towards being read by the machine.
Ruby is used for Puppet and Chef (or Ruby derivatives) which also utilize something called “DSL”s or Domain-Specific Languages, Puppet is also the language which calls its config file a “Manifest” which is a good to know at least for exam day.
A high level overview of Puppet, Chef, and Ansible and their features
This will be a very high level overview of these three coding languages.
Puppet (Pull Model)
- Puppet Master (on Server) / Puppet Agents (on devices)
- Puppet uses “Modules” which goes into the “Manifest”
- Uses “Provider” and “Types” to fill in Modules with info such as “Cisco” and “Router” so that it knows if it can talk to it, and what it can say to that Agent
- Puppet Manifest again is the name of the “config” file for Puppet
- Puppet Forge is Puppets website where you can download the software, other peoples Manifests to use a Template for your own coding with some adjustment
Chef (Pull Model)
- Chef has a Server, Workstation, and Node
- Start on Chef Workstation where code is created / tested / changed
- The Config File would be “Pushed” from the Workstation to the Server, then “Pulled” from the Server by the Node
- Chef Cookbook is the main software library that allows it to talk to specific devices, for example there is a Cisco CookBook / Juniper Cookbook / Etc
- Chef Recipes are the functions contained within a CookBook, which is essentially the library of functions that Chef can perform with that vendor per its CookBook
- Obviously a Cisco function like “router ospf 100 vrf Chef” would be in a Cisco CookBook, you cannot use Recipes for one vendor from another vendors CookBook!
Ansible (Push Model)
- Ansible Master / AGENTLESS!
- Utilizes SSH to connect to managed devices
- Ansible PlayBooks uses modules to run Automated Tasks via Modules
- Ansible Modules are the actual configs for devices, so for example you might have a startup configuration file saved as the “ios_device” module that can be called on
- Ansible Playbooks are then comprised of both configured Modules and define Network Devices to run the modules against at a set time of a day (could be immediate) but can scheduled to automate tasks overnight or throughout the day
- “Ad Hoc” is another way to run a Module, meaning you can run a Module from the Server by itself to one device without a PlayBook being involved at all
That will do it for this look at the Automation Tools used in todays networks!
There is also one last website I forgot to list but want to slip it in here, it is a comparison site of all the different coding languages in a deeper look at them:
https://www.networkworld.com/article/2172097/puppet–vs–chef–vs–ansible–vs–salt.html
Its a good non-Cisco biased look at the different Tools that is a fairly light read after going through them in such depth, until next time, Happy almost Monday! 🙂
The DEVNET GRIND! 