An Overview of Automation Tools before diving into Ansible, Puppet, and Chef!
These major 3 Automation Tools Ansible / Puppet / Chef offer powerful and robust Automation solutions rather than Ad-Hoc strategies such as BASH / Python / Etc.
These 3 Tools “wrap” Operating Systems functions into them for ease of use, with both robust and useful sets of pre-configured scripts or functions, which can built-in shell access that enables users to drill into scrips / inject / reuse code as needed.
These tools also go back to the word “Idempotency” which these Automation Tools aim to make as easy as possible to achieve by already having tools / modules based off of best-practice code that can be adjusted as needed to configure / backup / enable recovery.
Also being I have Ansible Installed I can demo this – The default feature-set is nuts:
^^^ These are just the different OS Platforms it comes with scripts for by default!
Its not just OS either, its Layer 2 / Layer 3 / RESTCONF / NETCONF / routing / system / Etc, so Ansible itself really hits the ground running right out of the can, as do the others though I probably won’t bother demo’ing them on here at this time for the sake of getting through my DevNet class work this week.
All modern Automation Tools strive to be Data-Driven to enable the following:
- Compilation of variable definitions
- Server Inventory as Structured Data and other details as separate and generic code
- Orderly way of injecting variable values into code, config templates, etc
- Perform basic Discovery / Inventory Management functions
- Scale incredibly large, extremely easily, depending on the Tool being used
These tools also engage Developer Community Collaboration to add to their Tool Sets as they are made in open source code versions, so developers can find and fix bugs for future deployments / Play Books, and Distributing these different Play Books through places like GitHub or Tool-Provider-Repo’s such as Ansible Galaxy.
Critical Automation Concepts – Which includes some review for absolute clarity!
First would be “Idempotency” which means that the software produces the same desired result, each time it is run, which enables convergence and enables you to:
- More easily gather components in collections that build new kinds of Infrastructure or perform Operational Tasks
- Execute whole build / deployment collections to safely repair small problems with Infrastructure / perform incremental upgrades / modify configs / manage scaling
The goal of “Idempotent” software is to allow for a critical failure caused by an incremental deployment to be remediated, and the entire cluster rebuilt from scratch within minutes, confident that even if an issue does arise it will be handled immediately.
Infrastructure as Code and Idempotency guarantees that the Codebase “Converges” towards the desired goal by converging in a sequenced / incremental approach, with the goal of deploying a working piece of software with every change made.
Procedure vs Declarative
While Procedural code can achieve idempotency, many modern Infrastracture Management / Deployment / Orchestration tools adopted the “Declarative” Method which is a Static Model that represents the desired end product.
Declarative Code often used by Middle-Ware that incorporates deployment-specific details / examines present circumstances / brings the actual Infrastructure into alignment with the Declarative model via the least disruptive / time consuming method.
Ansible and Puppet are considered “Declarative” Domain Specific Languages (DSLs), where as Chef is more inherently “Procedural” in how it works.
This is kind of an artificial statement how tools are characterized but this is how I would group them, since all of these at the lowest level use BASH / Python / Etc, Ansible itself is based on Python whereas Puppet and Chef are both built on Ruby.
This means all can use either Procedural or Declarative techniques as needed, and in real world practices are often case specific as to how they are used, but for exam day I would separate them out into those two categories for those Automation Tools.
Provisioning / Configuration / Deployment / Orchestration
- Provisioning – Obtaining the compute / storage / network resources to enable communications and making it ready for use by developers or operators to deploy resources as needed
- Configuration – Installing base level applications and services requires for operations / tasks / tests as required to prepare for platform deployment
- Deployment – Building / Arranging / Integrating / Preparation of Multi-Component Applications such as Database Cluster across a single or multiple nodes
- Orchestration – Platform-Inherent Automation that manages workloads by dynamically changing conditions, which may be a self-healing applications to SD-WAN Appliances dynamically routing traffic for best possible user experience
Statelessness
Automation works best when Applications can be made “stateless” because they do not track or retain any kind of “state” of data, meaning they can be redeployed without considering the “Stateful” Data they need to function properly.
Stateless = An Application that requires persists to a separate database, or requires no memory of its previous state between invocations
Not Stateless = An Application that saves critical information in files or a Database on a local file that it needs to reference in order to operate properly
Below is a visual demo of the APPLICATIONS “State” in different scenarios:
My website is Stateless in the way that it doesn’t care what the previous State was when browsing around it, it presents Data as requested, its doesn’t require any previous knowledge of anything to present that Data to a user.
If you are old enough like me (Dinosaur Age) an AS400 is a “Terminal Service” were multiple users sit down at the same computer to do Data Entry, the Application acts as an Intermediary between the Client and Database, however once its shut down it loses all memory of anything that was done between the User and the Database.
The last example would be something like a “SharePoint Database” that constantly keeps track of the state of files, provides a user permissions based on their credentials, and constantly tracks the state of connections / permissions / files to operate.
This has nothing to do with the “Network Connection” but the Application itself.
Websites will operate regardless of the state of the application at any given time (with the exception of e-commerce or payment systems), AS400 Terminal Services only provide / write Data to Databases on demand by a user, where something like SharePoint or even Outlook Email relies on its last current state to provide all previous Emails so that you can reply to them in an order – It must know its previous State or it doesn’t work!
Back to Popular Automation Tools!
Although Puppet was the first “Modern day” Automation Tool, it has a couple more modern competitors Chef and Ansible, which share the following common traits:
- They are easy to learn and work with
- They are ALL available in open source versions
- Plugins and Adapters allows the to interface with the 3 different types of Clouds (Bare Metal: Cisco UCS / ESXi, Private Cloud: VMware vCenter / OpenStack, and Public Cloud such as AWS and Azure)
In turn many different types of Cloud Platforms will provide their own vendor specific feature-sets available to integrate with different Automation Tools or Technologies.
Ansible
This is by far the most popular Automation Tool because it runs Autonomous to the Nodes it manages, meaning there is no Agent that needs to be installed, which when you are managing anything at a growing scale this is exactly what you want!
Ansible comes in either a Lightweight open source format available on basically any Linux platform (as I’ve downloaded and documented installing), and also in an Enterprise called “Ansible Tower” built in RedHat which is more feature rich with a nice GUI and added features to make it easier to work with.
Some of these features include:
- Ansible “Control Node” which runs on almost any Linux Platform with Python 2 / 3 installed, which can be a Linux server / Cloud Tenant in a Public Cloud / a VM running on a Host OS like I have running in Hyper-V on an Ubuntu VM
- The Control Node connects to managed resources via SSH, through which it can run shell commands via its REST Interface, Inject Python Scripts into targets and remove them after, and Install Python on the target if needed(!)
- Plugins allow Ansible to gather facts / perform operations on Infrastructure that can’t run Python locally, such as a Cloud Providers REST Interface (or just SSH)
This is why there are so many default packages it comes with as shown above, it can run SSH to an IOS device, HTTPS/REST to a Cloud Platform or Web-Based Controller, or to a Server Cluster using Shell Commands and Python Modules to perform tasks!
Ansible Code Structure is separated int YAML format (.yml) files that contain a sequence of tasks that are executed from the Top Down, where Task Names will Parameterize a module that performs work similar in how a Python Function will call Parameters.
Ansible contains tons of pre-built Python scripts that contain OS level functions to execute against a target, or some modules come in a “raw” format in that they present a single string to the shell or console, capture the return code and variables, and return it in the form of accessible variables. The “apt” module can be used to install / remove / upgrade / modify different packages or lists of packages to a Linux Server or machine running a Debian Distro of Linux.
Ansible Playbooks and Roles
An Ansible Playbook or “Play” is a large / monolithic file with a series of modular named tasks which are what make up the play book, these tasks are called “Roles” in the Ansible Play / Play Book which are complex yet low level tasks.
Some of the benefits include:
- Clarity – Named Plays and Roles within a Play can be intuitive enough to know what it purpose it serves
- Reusability / Shareability – Roles especially are “reusable” in other Plays / Play Books, and shareable with the larger community via Ansible Galaxy Project
Ansible Folder Hierarchy elements
Inventory Files / Host Files – This defines the resources or targets under your management via Ansible, you can logically group items by host name or IP Address, and then group those things as a “Parent:Children” configuration as I have here on my VM:
Shown here is a group “host1” that contains just a single host “autovm1” and then another group that contains another single host, but then at the bottom I make a parent group object called “vmhosts:children” which groups both those “groups” into the grouping of “vmhosts” so I can either ping a single host, a group of host, or a group of groups (or you can actually just do “ansible -m ping all” to ping every host it manages).
Variable Files – These files describe variable values pertinent to groups or individual hosts within the Ansible Inventory File shown above
Library and Utility Files – These optional files contain Python code for custom modules and utilities that may be required to write custom modules, or they might be found at Ansible Galaxy Project / Repository for more Platform or Scenario Specific tasks
Main Playbook Files – Written in YAML these files reference lower level Roles
Role Folders and Files – Role Folders contains a tree of tasks that perform a phase of configuration, a Role Folder contains “/tasks” folder with a “main.yml” tasks file and will also contain a folder of Asynchronous “handler” task files
Ansible at scale
Ansible Control Node is designed to sit as close to the Infrastructure it manages as possible such as a VM or Container in the Environment of the managed resources, meaning an organization with multiple sites may have Ansible Control Nodes operating at each site / in the local network – Ansible Control Nodes do not have to actually be persistent on the Network and can be spun up on demand if the Ansible code is stored in a Version Control system such as GIT.
When managing Ansible at scale some challenges are having both Flexibility and Security into Remote Controllers for seamless and secured control of an Enterprise level deployment which can consist of two different Control Planes:
- Commercial Ansible Tower which includes a sophisticated web interface REST APIs, and role-based access control for security
- AWX Project which is open-source and feature comparable alternative to the Enterprise solution, however this undergoes minimal testing is not comprised of signed binaries which is a deal breaker in many Enterprise Solutions
Continuous Delivery based around an Ansible Deployment can also be performed using CI/CD Tools such as Jenkins or Spinnaker, and for Larger / More Complex projects use a framework known as “Zuul” originally designed by OpenStack Project and is similar to the AWX Project as an Enterprise solution.
Cisco Ansible Resources
Cisco along with the Ansible community maintain extensive libraries of Ansible Modules for Automating Cisco Compute and Network Hardware which include:
- A very large built-in set of modules for configuring Cisco Application-Centric Infrastructure fabrics via the APIC (Application Policy Infrastructure Controller), which execute on the Ansible Host (not the Cisco controller) via the REST Interface
- Remote control of Cisco IOS-XR devices, including modules for sending command and retrieving results from these device via CLI or NETCONF / REST Interface
- Ansible Modules for “Intersight” REST Interface for the Cisco UCS Infrastructure
Puppet
This solution is more lean than Ansible in the following ways:
- A designated server is the Puppet Server / Puppet Master, its use of “Facter” the fact-gathering service for Puppet, and PuppetDB which can store facts / node catalogs / recent config or event history
- A secure client called “Puppet Agent” must be installed on all target machines, which authenticate using self-signed certs (SSL) between Client and Server, the agents using “Facter” to gather “facts” from Clients to pass up to the Puppet Server
- For Cloud APIs or Hardware unable to run a puppet agent there are modules available to enable these connections
- For Large-Scale Deployments where many devices are non-agent capable under Puppet Management, Puppet enables a proxy agent to offload the work of directly connecting to device CLI to gather and exchange information
Communication to a Puppet Server is largely done via SSH and CLI, the Puppet Server can either be a VM or a Docker Container for small “self-teaching” implementations, Docker / Puppet also provides a compact Docker install called “PUPPERWARE” for these smaller scale implementations. Puppet packages are also available to build a Puppet Server on Linux, which is currently the only option for a Puppet Server install – Agents / Clients are supported on Linux / Windows / Mac.
Puppet Server requires fairly powerful hardware or a large / resource intensive VM, and requires an NTP Client installed / configured / tested. Once a Puppet Server is installed the Agents can then be installed with a “puppet.conf” file configured with the self-signed cert from the Puppet Server for Authentication, once installed and authenticated it can start gathering Facts and update the Client State to push out Configurations.
Puppet uses the same folder tree structure as Ansible, where “environments” is the top level like a “Play Book” in Ansible terminology, which will contain a “modules” sub-directory in which projects and manifests can be stored for thing to build or gather.
For example you might create “modules” inside of “environments” folder, then “manifests” folder inside the “modules” folder, where you store manifest files declaring operational classes (units of code describing a config operation), manifests while typically be identified by their extension of “.pp” and are written in Puppets Declarative Language which is similar to Ruby Language.
Like Ansible, Puppet comes with Built-in features (not nearly as many) that can be invoked to define a configuration action to be performed on hosts and Clients, which the idea also being similar to Ansible in that a class will invoke resources the are parameterized to function “Idempotently” and will be applied in the context to produce the same result every time it runs.
Extra libraries and modules can be downloaded from “Puppet Forge” which is the equivalent to Ansible Galaxy only smaller (of course), and Cisco / Puppet also maintains extensive libraries of modules for automation of Cisco Compute platforms such as Cisco IOS Modules and Cisco UCS Modules.
Puppet at Scale
Puppet is very Monolithic at scale with a recommended maximum of “up to” 4000 hosts, which compile catalogs for client agents and place these behind load balancers to distribute the work load.
Puppet Enterprise customers can expand capacity by replacing PuppetDB with a stand-alone database called PE-PostgreSQL, which also offers a friendlier web-based interface with point and click options for access to logs and deploying configurations.
Chef
Chef provides a system for treating Infrastructure as Code, with its products partly licensed, but free for personal use (less than 25 Managed Nodes via Chefs Infra Server).
Chefs products and solutions enable infra-as-code creation / testing / organization / repo storage / execution on remote targets, either from a stand-alone Chef Workstation or indirectly from a central Chef Infra Server.
Chef components to be aware of:
- Chef Workstation – A standalone operator workstation for smaller operations
- Chef Infra Client (the host Agent) – Chef Infra Clients run on hosts and retrieve config templates and implement changes via “CookBooks” (and Proxy Clients) which enable control of hard and resource that can’t run a Chef Client locally such as network devices
- Chef Infra Server – Replies to queries from Chef Infra Agents on validated hosts and responds with config updates, which then converge the host configuration
Components of Chef Workstation:
- CLI Tools for authoring, testing, and maintaining CookBooks to run on Hosts
- Interacting with Chef Infra Server to bootstrap new nodes / set policy
- Test Kitchen a testing harness (environment?)
- ChefSpec that simulates the effects of code before implementing
- InSpec which is a security / compliance audit and testing framework
Chef provides hundreds of resources for performing common config tasks in an idempotent fashion as well as a Chef Supermarket, which is Chefs community sharing site for CookBooks / Custom Resources / Recipes.
Code is maintained in a local rep format called “chef-repo” which can be integrated with Git enterprise-wide efforts, within the repo is code organized as CookBooks which contain folders called “recipes” which are actual liner config code written in Chefs extended Ruby Syntax, which are segregated attributes / customer resources / test code / metadata.
Chefs domain-specific Language enables you to address config tasks by authoring a sequence of small bracketed templates, each declaring a resource and parameterizes it, Chef resources tend to be more Abstract than Ansible or Puppet which helps address cross-platform integration – This means that a package may require a certain OS running in the environment like Windows / Mac / Linux required to install.
Installing Chef and Chef at Scale
Chef Workstation is available for Linux and Windows, once Workstation is installed it can immediately be used to start making config changes on accessible hosts, though some prep is likely required on node managed such as Password or SSH Keys (SSH being preferred). It is advised to use both hostname and IP Address of target machines in Chefs Host File (/etc/hosts) file on the Chef Workstation / Server.
Chef Infra Server was written to increase its capacity / scalability, enabling to manage up to 10k hosts. It can be configured for high available by deploying its front-end services (NGINX and stateless app logic) into an array of load-balances proxies that connect to a three-server active/active cluster support back-end services like eslasticsearch, etcd, and PostgreSQL.
Chef also provides multiple products that solve most of the problems facing Enterprises in dealing with complex / hybrid / large-scale infrastructure. The “chef-repo” on Chef Workstation structures harmonize with Git enabling for convenient version control and collaboration with developers code, and simplifying infra-as-code regimes.
Chefs core Philosophy of continuous configuration management dovetails well with goal of continuous delivery, which is where features come in handy, such as Chefs built-in Unit testing framework Test Kitchen / Pre-deployment sims / companion security auditing and testing assessor inSpec.
Finally – Chef also has Cisco Resources modified for Chef Infra Agents that run in the guest shell of NX-OS switch equipment, enabling this hardware to work with Chef as if it were a managed host. Cisco also has “Check Cookbook for NX-OS Infrastructure” available on Chefs Supermarket.
With that I will end it here on the 3 big Automation Tools to know about
That was a lot of information to make sense of while reading through it and trying to translate it to this page, I may come back to do some clean up and add pics from labs built into my Cisco Hands on labs, however this is pretty full coverage of them.
I will try to find resources to work with these, I wrote an article maybe a few back on installing Ansible with 2 other VMs to play with, which can also be integrated with GNS3 I am sure to play with that as well.
I will update with further resources and info as I get it, until then, I am out!
The DEVNET GRIND! 