I remember Ansible pointing to Python 2.x being an issue last time as well, but I do a quick lab demo at the bottom to show I am all set to launch out of the dry walls of text, and back into the lab in the coming days / posts before I take my (now scheduled) DEVASC exam!
Time to get through some Basics of Ansible before diving into labbing DevNet!
Before installing and labbing Ansible in my new VMware Lab (bye bye Hyper-V!), I want to cover the basics again quick bullet point style here:
- Ansible is the only “Orchestration Tool” that is “Agentless”
- Ansible uses DSL or Domain Specific Languages to speak with many different devices
- Ansible Control Node can be ANY device that Ansible can run on, like a laptop with linux
- Ansible Files / Plays / Playbooks are written in YAML to the “Ansible Control Station”
From here I’ll go into the workflow but Ansible does not need agents on any “controlled” nodes, and its Control Station could be a $20 Linux Laptop running Ansible and executing Playbooks!
There is a fairly well defined flow actually of exactly how Ansible works:
- Engineers create playbooks in YAML that describes a workflow / config of infrastructure
- Ansible playbooks are deployed to the Ansible Control Station
- The Control Station will then copy or write these modules in Python to remote hosts
- Ansible will then finally “run” the modules on the remote hosts described in playbooks
Ansible cannot do all of this powerful Automation without a little leg work first though!
Firstly the “Control Machine” itself must be running the Ansible Tool, it uses a “Push” model for deploying configuration changes to the network, and uses SSH as its transport method so the receiving Host must accept the SSH connection or it will not be receive the Playbook Push.
- Modules – Written in Python, copied to remote hosts and then run via Ansible Tool, which is executed from the Ansible Control Machine, referenced as “Tasks” within “Playbooks”
- Inventory Files – Contains Host IP Addresses or FQDNs operated by Ansible, referenced when running Ansible commands
- Playbooks – Written in YAML and contain Ansible DSL (Domain specific language), these are modularized like software for re-use, Variables that contain data for Playbooks can be separated into separate YAML files on the same Ansible Control Machine
- Configuration Files – The main file that directs the Ansible Tool on how to run
Ansible CLI Tool command review:
- “ansible” – Used to run modules against targeted hosts
- “ansible-playbook” – Run entire Playbook against targeted hosts
- “ansible-vault” – Used to Encrypt Data within an Ansible Playbook
- “ansible-pull” – Enables clients to “pull” modules from a Centralized Server
- “ansible-docs” – Example syntax of how to parse the docstrings of Modules
- “ansible-galaxy” – Create or Download from the Ansible Community from Galaxy
A quick review of the different Ansible Flavors:
- “Ansible Core” – Free open source software that forms the baseline functions of Ansible, does not have any form of support (outside the community)
- “Ansible Engine” – Same as Core but with Red Hat support, suited for Enterprise solutions
- “Ansible Tower” – GUI Front end to Ansible Core which provides a GUI Front end, this is licensed on a “per node” basis
- “Ansible AWX” – Open source version of Ansible Tower
Use cases for Ansible Automation:
- Creating a Playbook to ensure all servers are running the same version # of an application, either downgrading / upgrading / leaving alone as needed
- Provisioning new devices such as servers are network devices with a baseline or standard configuration that will be pushed to all devices, or provision Cloud Resources such as services / host VMs / Databases
- Push new configs to existing network devices such as changing an NTP Server IP, by removing the old and adding the new, or just retrieving device running configs
The Control not is ANY device with Ansible installed on it, which only restriction is really being a Windows machine, otherwise it can be a PC / Laptop / Server with Python!
^^ Thought that is worth pointing out seemed like an exam oddball question so wanted to really point out Ansible can be run basically on anything outside of Windows devices.
Enough with the dry theory (I will be reading that offline), it is time to lab!
It took me a bit and switching back to VMware with my new laptop (with more Virtual Labbing Horsepower!), and to start out I’ve left out the L3 Routing for now, and made the following Topology below which the NetAuto Host will remain mostly unused:
Instead I created a quick generic startup file in notepad to apply to all switches:
en
conf t
host SW5
ip default-gateway 192.168.126.254
line con 0
no exec-t
logg sync
line vty 0 15
transport input all
int vlan 1
ip add 192.168.126.105 255.255.255.0
no shut
int range gi0/1 – 3
no shut
int range gi1/1 – 3
no shut
int range gi2/1 – 3
no shut
int range gi3/1 – 3
no shut
exit
username loopedback priv 15 secret MyPassword!
ip domain-name loopedback.com
crypto key generate rsa
2048
end
wr
I ran this on all 5 switches, only changing the Mgmt IP on VLAN 1 and the host name, the rest will be up to Ansible to configure! 🙂
I am not sure if I will need to copy the Ansible SSH Key to these switches, but for now I am just making the lab, speaking of Ansible my Ansible Control Node will be an Ubuntu VM:
I have not done anything other than installing and updating Ansible to the latest version, and am currently spinning up an Automation Host to control as well for fun as seen there with the GNS3 VM being used via David Bombals excellent GNS3 videos (among many).
In fact I used the same videos I believe are on YouTube as well for his GNS3 setup vids, and determined the network # to statically set VLAN 1 Management IP’s as shown below on my AutomationHost in the GNS3 Topology:
It is not apparent so this is the file to either remove the #’s to get rid of the statements on the DHCP portion and reload the machine to see the non-IPv6 pulled that it learned via GNS3:
Then in GNS3 mine makes me shut it down and re-start it cold boot style, and I console in to ensure it gets a response to DHCP and verify Connectivity to my Ansible Control Node:
I then verify this GNS3 Topology has Layer 3 IP Connectivity to my Host and the Internet:
I’m not concerned with NetMiko at this time as this is surrounding Ansible, the NetAuto Host can get an IP via DHCP, ping my Ubuntu Host, and can reach Google so that is about it here.
One issue I haven’t figured out and really haven’t tried is every time the VMware VMs boot DHCP / NAT vmnet8 adapter creates a different 3rd octet (192.168.x.0/24) so I have been trying to troubleshoot that while also dealing with VM boot issues, so the actual network # in the 192.168.x.0/24 range is will change from lab to lab!
Given the weird issues I’m having with VMware and this new laptop, I’m okay with winging it until I get the DEVASC out of the way, feel free to ping me if you know how to make that pool static on Workstation running on Win 10 home 🙂
The next post I will begin labbing and explaining things as I go, writing theory is no fun!
I will try to only post labbing going forward here, and resume being on my Discord Server more as I begin labbing, but tonight I just wanted to get things set, I intentionally left off a lot of configurations as I plan to Automate things like DNS for the Switches / Port Channels / STP Root Bridges / And set all this up next post labbing up making Host Files and much more!
Also the cat is out of the bag here – My DevNet is scheduled and I may move it up!
I got my DevNet OCG today with practice tests and I will be keeping theory to myself for exam day and just try to produce labbing that demonstrates the technology rather than explaining at length as fun as I am sure it is to read as it is to type for hours on end!
However the exam has been scheduled with Cisco Study Group Voucher tentatively(!) :
I am actually hoping to move this up before the holidays set in if I feel confident, but continue posting and labbing the topics here, as I’d like to progress in the new year into Enterprise Automation to finish re-certifying my CCNP Status (as the Cisco Study Group also gave 48 CLE credits to satisfy one exam!), however after the DEVASC it will be mostly fun / playing / labbing with no real direction for awhile to get comfortably with the new tools.
Anyways, lab will be coming soon, good to be back and productive after hitting slacking off!
Until next time! 🙂
The DEVNET GRIND! 