Everybody, welcome. This is going to be quick discussion on Ansible and its use in network automation. Ansible is an open-source IT automation tool. It is a stand-alone server that's maintained by Red Hat Linux appliance and it is based on Python scripting with YAML. There is a free community version and there is a supported pay version, previously referred to as Red Hat Ansible tower. The version we're going to be working with is the community version, now called AWX or Ansible works. It is modular and extensible scales to thousands of devices, and most importantly, it is agent-less. There are tools out there that like Chef Puppet that you can run as a central point of management, but they require some installation on the server or switch server that you plan on running these against. You run the Ansible servers centrally, but you don't have to install anything, any agent software on your machines. Slot like how SNMP would work where you would have an SNMP server and then SNMP would just run as a service as an agent talking back, there's actually nothing that's really required on the targets themselves other than opening up SSH and HTTPS. It is secure, uses standard transport including Secure Shell and secure SSL or HTTPS to interact with these devices. Most importantly, there is a ton of vendor support, Ansible has been around for a while so it is well-versed in vendor's providing automatic or automated environments where you can install Ansible modules for a particular vendor to make your answer and commands that much easier to automate whatever system it happens to be. Some concepts here, when it comes to Ansible. Ansible is going to be running what's called a Playbook. A playbook is a list of individual plays or tasks, which are tasks constituting a play. Individual tasks make up a play and you can have multiple plays in whatever order you like interacting with whatever vendor module that you have installed on your devices for your target systems. The way Ansible basically runs is you fire up Ansible and issue which playbook you want to run out of and it will issue the different plays in the order that you've specified but you need to specify targets systems, whether they're servers or in our case, switches and gateways that you want to interact with. This is done through an inventory system. Inventory contains all of the target devices that Ansible is going to operate on or run commands against. Each device is called a host and has a name, IP address, and possibly password. The inventory organizes devices into groups which tasks are applied on so this inventory file is going to be there right alongside your playbook file and your inventory file command, YAML as well or it could be just as a simple text INI file. The playbook consists of one or more plays in a list, and a play is a collection of one or more individual tasks or commands that you want to run. A task being a single action that you want to execute through Ansible against your inventory of devices. What's nice about this is this use of modules which are reusable standalone scripts that Ansible runs essentially on your behalf so you don't have to do a bunch of low-level commands you can just use the module is provided by a particular vendor and it makes it much more easy to go ahead and make what changes you would like to pull information, push information wherever you'd like. Here's an example where in Ansible, you have your Ansible machine, your control machine running on Linux, and you can just simply login and use the CLI on this control machine or if you're using the community works version, there's a GUI version that you can use as well. We're just going to use the simple command line version in our example. You can include with this your module plug-ins here. With these, a module is a Python code that automates a particular task that can be called with Ansible as plug-in is a little less complex and shorter Python code essentially that generally helps to fulfill a particular task. We'll see an example of some plug-ins from Aruba to make our jobs much easier and our play as much shorter here. With this, you have your inventory of files that you're going to call with your command in CLI and you would issue essentially a playbook against that inventory of devices that you want to run on. Originally, Ansible was built to connect to each target system through SSH and then execute whatever the define automation was but nowadays, you can use REST APIs for this as well. Rest or SSH, either or can be utilized. Here's an example of what this command will look like. You fire up the Ansible hyphen playbook, specify the file name and the playbook that you want to run and that playbook is a list of plays in order that you want to execute. Each play being a task, holding multiple tasks that you want to run and then with a -i, you can indicate where's your inventory file, the list of devices that you want to run against. We have these in the demonstration that we'll use for you. Ansible tower is the payed supported version. According to red hats own documentation, if you're going to run Ansible in a production network and you can't afford to be down for more than a few minutes, you need to be able to call support then you want to pay for Ansible tower. However, they're extremely open with their code and they actually test new features in Ansible AWX or Ansible works. This is community supported where you'll get all the latest features but they're not necessarily fully vetted. They're treating this almost like a Beta test bed. This is great for your own labs like we're using or if your own home system that just want to play around with but not recommended for production, use Ansible tower if you're going to be doing this 'no production' basis, you can run Ansible as a virtual machine or as a Docker-based container. Version upgrading is not supported. You have to actually rebuild the config each time when you're using AWX. Stability is supported through minimal testing and security is supported through a minimal testing. Fine for lab use but again, if you're going to step this over to production, consider the full product. Let's jump into Ansible and see an example of it using CX automation.
