Got automation? Here's a quick guide to get you up to speed on Ansible

Ansible is an open source automation tool that sysadmins use to automate infrastructure configuration, application deployment, and configuration management. It is agentless, which means it does not require any software to be installed onto hosts—unlike some other automation tools—to perform the needed tasks. Instead, it uses SSH, if the target system is Linux-based, WinRM if the target system is Windows-based, or an API if the target system exposes an API.

It uses a declarative programming language to define the desired target configuration. However, it does not declare how the configuration needs to be accomplished. For instance, to create a new virtual machine, you need to define the specifications of the target virtual machine and how it is to be deployed. The Ansible Engine, with the aid of the relevant module, then performs the needed task.

Automation in the IT world

Automation in the IT world is needed to avoid doing repetitive actions manually and to speed up the deployment cycle. Ansible is meant to address these needs. Here are some examples of how Ansible can be an essential part of your IT infrastructure:

Infrastructure as Code

• Spinning up new virtual machines can be done in several ways. However, after spinning up a new VM, you still need to install additional software packages, applications, and so on until the new system is functional. With Ansible, you can automate that entire process, from creating a new virtual machine to application configuration.
• If you have a cloud environment that continuously grows, actually attaching new compute resources to your cloud can be achieved by different cloud-native tools. Still, you first need to prepare the hardware before attaching it (i.e., create RAID configurations for local disks, add VLANs to its profile, etc.). Ansible can be the primary tool to prepare your hardware and attach it to your cloud using cloud-native APIs.

Application automation

• Suppose you have an application that requires updates regularly. For instance, adding new entries in a database can be completed in several ways. If your application is scattered among specific servers, instead of making different scripts for various systems, you can make an Ansible playbook containing one or more plays to automate and orchestrate this action from A to Z.

[ You might also like to read: Introducing the new Ansible Automation Hub ]

Ansible modules

Ansible modules take the instructions to perform the tasks. One of the most vital points in Ansible is its vast community, which regularly creates new modules. These modules usually are coded in Python. The initial installation always comes with preinstalled modules. However, you can install additional modules from the Internet. You can get more information regarding each module (i.e., what is this module doing, how to use it, examples, etc.) in two ways:

Online: By searching Ansible documentation. 

When searching, you must be sure to choose the appropriate Ansible version from the dropdown list at the top left corner of the page.

Offline: Using the ansible-doc command from the command line.

$ ansible-doc file

Here, you are searching on how to use a module called file. Ansible's rich selection of modules is actually a double-edged sword, where it has its advantages and disadvantages.

Advantages:

1. You can find a module for almost every task you want to perform.
2. You have a huge community to support you if needed.

Disadvantages:

1. With this many modules, you can get confused quickly on which to use. That is why when you start planning to use Ansible to automate specific tasks, you need to create a strategy to determine which modules to use and test them.
2. You will find many community modules that no one supports anymore or are deprecated with new Ansible releases. Be sure to carefully perform every new Ansible upgrade. Also, do enough testing prior to moving the module to your production environment before risking your automation chain. Choosing modules to use and building an automation strategy is something you will do over time.

Ansible and Python

Ansible is heavily dependent on Python. Most of the modules are coded with Python. Also, the target Linux-based system must have Python installed to start automating tasks using Ansible. Although Ansible is heavily dependent on Python, in-depth Python knowledge is not required. However, knowing how to use pip to manage Python packages (install, update, etc.) and creating Python virtual environments is recommended.

Warnings:

1. Changing Python versions or any of the preinstalled packages on the Ansible Engine system is a risky action that can break your automation chain.
2. If you are using the Red Hat-supported Ansible Engine, Red Hat will help you create your Python virtual environment if you want, but the virtual environment's content is not supported.

Ansible Engine vs. Ansible Tower

Ansible is meant to be used by different DevOps teams. Ansible Tower allows many teams to execute automation tasks from a centralized location that permits RBAC, logging of executed tasks, a GUI to run tasks, and more features. Having a centralized automation system for a huge automation chain will simplify your maintenance tasks. For a small Ansible automation chain, Ansible Engine can be used, which is a Linux-based node with Ansible binaries installed. In this setup, you will miss out on RBAC and the GUI. However, Ansible Engine provides the needed environment to run the relevant automation tasks.

Which Ansible approach?

Ad-hoc

Ad-hoc is a way to send a single Ansible task to the target system(s). You can see this by running a command on a remote system using SSH or legacy rsh. With ad-hoc Ansible, you are running a more sophisticated task rather than one command only because you are using an Ansible module, which is doing more than a single command.

Plays

Ansible Plays are collections of different files in YAML format, which will run on one or more target systems. These plays are written in a file called a playbook.

Which type to use?

In my experience with Ansible, I have seen both approaches used. I have seen developers listing ad-hoc commands in a simple Bash script and others creating neat playbooks. Although Bash scripts with ad-hoc Ansible might look simpler, Ansible was not meant to be used like this. Ad-hoc commands are suitable for some simple tasks. For a full automation scenario, you need a playbook to debug the activities to be executed in an easy visual way. One significant advantage of using playbooks is that you can import them into Ansible Tower as your automation chain grows. As mentioned earlier, you will find developers who prefer different ways, but as an "automation chain" designer or architect, you have to consider the scalability of your chain and determine the point at which you decide to consolidate your automation tasks into Ansible Tower.

YAML

YAML Ain't Markup Language, (YAML) is the format in which Ansible playbooks are written. The YAML format is used in several areas (i.e., heat templates in OpenStack, creating/modifying objects in Kubernetes, etc.). The YAML format is easy to read. However, it is somewhat tricky because it is sensitive to indentation. If you have not written any files in YAML, and to avoid spending time debugging your playbook, you need to pick up an editor that understands YAML syntax and formatting and can automatically adjust your indentation. Personally, I like to use the free Vim editor on Linux systems. You just need to add the following line to a file, name it .vimrc and save it in your home directory:

autocmd FileType yaml setlocal ai ts=2 sw=2 et

Files

In Ansible, there are some types of files you will regularly hear about. Here are some:

Playbook

A playbook is a file written in YAML format which contains tasks to be executed on the target system(s). Tasks that target the same systems are usually grouped in a play, and a playbook can contain one or more plays. Ansible engine executes the tasks from the top of the file down.

Inventory

Ansible Inventory is a file that identifies your target system(s). You can create groups within your inventory to organize your systems. For instance, you can create a group for web servers and another group for databases. Ansible has two types of inventory files:

Static Inventories: Files for static inventories can be written in either INI or YAML formats, and you can have more than one inventory file. You can specify which one to use by typing -i path in the command file.

Dynamic Inventories: A dynamic inventory is a script that will execute to get the targeted system(s) each time you run your playbook. This is useful when you are running your playbook targeting systems deployed in the cloud, and every time you have more (or less) system(s), for the playbook to target.

Ansible Tower has prebuilt some dynamic inventory scripts.

Ansible.cfg

Ansible.cfg is the Ansible configuration file. It is in INI format. Usually, it is saved in /etc/ansible/ansible.cfg. It controls system-wide Ansible settings. However, you might need to change one or more settings for your specific project (i.e., changing the format of stdout on the screen from JSON to YAML). You can create your own ansible.cfg file and place it in the project directory where you are changing only the setting you want to overwrite.

Variable files

Variables in Ansible are an important subject, and require time to understand and practice. You can define variables in more than 20 locations. You must understand variable precedence to pick up the proper location.

Roles

The main goals of automation are to minimize manual tasks and speed up deployment activities. If you have one or more tasks that you are doing often during different plays and want to keep them in a shared location and reference them when needed, then Ansible Roles will help you. Ansible Roles has a file structure that you must follow. Having this well-defined structure makes it handy to download Roles developed by the community to use in your playbooks.

Ansible Galaxy

Ansible Galaxy is a community platform where you can download extra tools for Ansible, additional modules, roles, and playbooks. If you are new to Ansible, remember that Ansible has a vast community. For almost every case you want to solve with Ansible, someone else in the community has probably thought about it and uploaded it to Ansible Galaxy. To avoid re-inventing the wheel, it's worth spending some time on Ansible Galaxy searching for something that performs the tasks you want, download it, then use it as is, or modify it for your own environment or application.

Automation Hub

As mentioned earlier, Ansible has a huge number of modules developed by its community. That sounds very useful indeed, but for businesses that are very sensitive to time-to-market or have a small automation team lacking Python coding skills, it's less desirable to solely rely on community modules. Some might not be supported in future Ansible releases, while others might even be abandoned by their developers.

No one is required to fix issues found when using community modules, so Red Hat has elevated Ansible from just a community supported automation tool to enterprise-level and delivered what is called Automation Hub. Automation Hub can be seen as the paid, supported version of Ansible Galaxy. The beauty of this service that you can choose the modules you need that match your Ansible version, as well as get support if a module is not working as expected.

Some bits of advice

Ansible, like any IT technology, has best practices. You can develop your own over time, but I would like to share mine here:

1. Start using Ansible. You can only master it when using it.
2. If you are the designer or the architect of the automation chain, although you are starting in small steps, always consider the future and what you need to do from day one to be ready when your automation chain gets bigger.
3. If you are writing playbooks to automate tasks, always think simple and search Ansible Galaxy. If you see what you're doing is too complex, then you're moving in the wrong direction because you won't be able to maintain it in the future.
4. Automation is not a one-person show in the sense that you have other people working with you, so write your playbooks in a clear, descriptive way, and use SCM systems for version control.

Resources to learn

Ansible has a variety of learning resources. Here are some:

Books: Ansible has many books in the market, but by far, Ansible: Up and Running in my opinion, is the most complete reference.

IRC: On freenode servers, Ansible has a channel where the community can help you if needed.

Online documentation: Ansible documentation is online where you can visit and learn from it.

Online and video resourses: Here are some online and video resources to learn Ansible.

• Ansible video instruction
• Ansible's YouTube channel
• Red Hat Ansible courses

[ Need more on Ansible? Take a free technical overview course from Red Hat. Ansible Essentials: Simplicity in Automation Technical Overview. ] 

Wrap up

Ansible is a state-of-the-art tool for IT automation. It's simple to learn, accessible, and rich with modules. If you're planning more than just learning Ansible—for instance, building your automation chain or migrating it to Ansible—there are plenty of resources available to get you going.