Ansible - What Is It And How Does It Work?
Ansible is a simple and versatile automation tool for all network-connected devices. Keep your configurations consistent and add new devices rapidly.
Recently, I’ve been learning how to use Ansible and what the limits are. This article is looking at the basics of what ansible is, why you might want to use it and, how to dip your toes into it.
What is Ansible
Simply put, Ansible is an open source automation framework that allows executing commands on remote systems.
Marketing says a few things and I'm giving some context on these:
- Agentless Architecture - Ansible uses SSH and WinRM/Powershell so that it can "live off the land" to perform actions.
- Simple and Decentralized Management - Uses easily trackable and distributable text files for all configuration from each administrator's workstation.
- Scalable - It would be a simple matter to distribute the text files among several management servers and run subsets of inventory hosts.
- Flexible - New modules can be written to extend functionality. You can manage devices of all OSs, Active Directory, network devices, and others! If you can get a remote connection to a device then a module can be written to manage it.
- Idempotent and Predictable - If you running a playbook on a host then only changed items are actually modified. Likewise if you run it against multiple systems, the result will be identical.
There are a few other things I have to add after using it. Some of this can be taken at face value and some of it is just generally correct:
- Python-based SSH/Powershell Automation - Yes, other methods can be developed and used but at the core python modules are executed over ssh or powershell modules are executed over WinRM.
- Declarative Configuration Platform - When done properly, you can have a folder that declares all your configuration and then is executed as a playbook. Changing one variable on a group config and then executing the playbook updates the value. Likewise, if one of the values you set in a playbook is modified directly on the system then running the playbook can put it back to the declared value.
- Role-based Server Deployment - If you use groups to define hosts into roles, such as a web server, then you can deploy updates and security settings specifically for web servers by role instead of ad-hoc.
- Self-documenting Server Installation - Kinda. If you have a file that produces a predictable installation then you always have a step-by-step guide to installing a server. Just make sure to add comments on the oddball things specific to your installations.
But, do I really need it?
Yes.
A bit of explanation:
- You need to be documenting server installations anyway so they can be reproduced when the server inevitably crashes or is replaced. Nothing is worse than having a server crash and not knowing how to install it or how it was configured to begin with.
- It never fails that some update comes out that needs to get pushed ASAP and happens to have a tweak needed on remote systems. Yes, in Windows this can be done with WSUS and GPOs but if you need it to immediately go to all remote systems then Ansible can be used to execute it RIGHT NOW on all online systems.
- If you need more devices added to an existing cluster then it can also help. If you have virtualization setup then it could be as simple as adding a line for the server in the Inventory file, add it to a group representing the role, then executing your predefined playlist. Ansible does the rest and gets in online with all of the special settings the other servers have.
- Help! The Server completely stopped working and I don't know why! Well, you can just delete the VM(Not responsible for data loss) and rerun the playbook. It's possible to configure it to automatically restore the filesystem data for whatever server, or copy it from another server in the cluster. *This depends greatly on your environment.
Not convinced yet? Let's look at one more aspect.
Unconventional Management Tasks
Because Ansible can use custom modules, there are modules that have been written to control unconventional equipment.
- Manage VOIP Phone settings centrally to ensure all devices are configured identially without having to use the boot configuration process. (I admit, the boot configuration process is the RIGHT solution)
- Manage networking. You can define Uplinks, Trunks, VLANs, etc in the inventory files and let Ansible streamline the configuration of them. Routers and Firewalls as well.
- Manage users. Anisble can interact with Active Directory, Windows Local Users, Linux users, and even iSeres (AS/400). So you can use it as a way to mange roles across multiple platforms for a single user account in addition to users that aren't in active directory. If you use 3rd parties then you can leverage Web APIs to create a user.
- For example, automatically give a web user access to the Linux servers for web hosting, Active Directory, MySQL Database Accounts, Admin on a fresh VM for testing, AWS login with appropriate permissions, mailgun, etc depending on requirements.
- Yes, this requires substational understanding and setup, but once done, you simply define a user like a device and add them to the appropriate group for their permissions and run the playbook. If it is setup write then it also prevents permission drift from manual settings.
- Thermostat management of schedules? I'm not sure if there is a module but the point is that you could write one for it and then configure everything at one time.
- Use with Drones for a drone show? Ok... this one is out there.
It devolves from here into some really crazy stuff where Ansible probably isn't the best tool. But it is interesting to explore oddball use cases.
I will be reviewing and making articles on how to do the first 3 items, but it is going to be a while before they are released.
How does it work?
Ansible is divided into a Control Node, where the administrator works, and the Managed Nodes which are the things that Ansible is managing.
The control node has a file folder with the Ansible Inventory, Playbooks, and Roles along with the program code. We'll explore all of this in more detail.
The Administrator runs playbooks which are files that define the execution flow and then things happen. Wonderful things.