Self-reflection on Automation using Ansible and Ansible Tower
From the Redhat Ansible Automation expertise session conducted by Linuxworld Pvt Ltd, I had learned technical terminology related to Ansible and the importance of Automation in real-world and also the use cases of Automation using Ansible.
why we need Ansible??
As data centres grew, and hosted applications became more complex, administrators realized they couldn’t scale their manual systems management as fast as the applications they were enabling. It also hampered the velocity of the work of the developers since the development team was agile and releasing software frequently, but IT operations were spending more time configuring the systems. That’s why server provisioning and configuration management tools came to flourish.
But before I go ahead to explain to you all about Ansible, let me get you familiarized with few Ansible terminologies:
Ansible Terms:
- Controller Machine: The machine where Ansible is installed, responsible for running the provisioning on the servers you are managing.
- Inventory: An initialization file that contains information about the servers you are managing.
- Playbook: The entry point for Ansible provisioning, where the automation is defined through tasks using YAML format.
- Task: A block that defines a single procedure to be executed, e.g. Install a package.
- Module: A module typically abstracts a system task, like dealing with packages or creating and changing files. Ansible has a multitude of built-in modules, but you can also create custom ones.
- Role: A pre-defined way for organizing playbooks and other files in order to facilitate sharing and reusing portions of provisioning.
- Play: A provisioning executed from start to finish is called a play. In simple words, the execution of a playbook is called a play.
- Facts: Global variables containing information about the system, like network interfaces or operating system.
- Handlers: Used to trigger service status changes, like restarting or stopping a service.
Ansible is a helpful tool that allows you to create groups of machines, describe how these machines should be configured or what actions should be taken on them. Ansible issues all commands from a central location to perform these tasks.
No other client software is installed on the node machines. It uses SSH to connect to the nodes. Ansible only needs to be installed on the control machine (the machine from which you will be running commands) which can even be your laptop. It is a simple solution to a complicated problem
ANSIBLE ARCHITECTURE:
Ansible architecture is fairly straightforward. Refer to the diagram below to understand the Ansible architecture:
As you can see, in the diagram above, the Ansible automation engine has a direct interaction with the users who write playbooks to execute the Ansible Automation engine. It also interacts with cloud services and the Configuration Management Database (CMDB).
The Ansible Automation engine consists of:
- Inventories: Ansible inventories are lists of hosts (nodes) along with their IP addresses, servers, databases etc. which needs to be managed. Ansible then takes action via a transport — SSH for UNIX, Linux or Networking devices and WinRM for Windows system.
- APIs: APIs in Ansible are used as transport for Cloud services, public or private.
- Modules: Modules are executed directly on remote hosts through playbooks. The modules can control system resources, like services, packages, or files (anything really), or execute system commands. Modules do it by acting on system files, installing packages or making API calls to the service network. There are over 450 Ansible-provided modules that automate nearly every part of your environment. For e.g.
- Cloud Modules like cloud formation which creates or deletes an AWS cloud formation stack;
- Database modules like mssql_db which removes MYSQL databases from remote hosts.
- Plugins: Plugins allows to execute Ansible tasks as a job build step. Plugins are pieces of code that augment Ansible’s core functionality. Ansible ships with a number of handy plugins, and you can easily write your own. For example,
- Action plugins are front ends to modules and can execute tasks on the controller before calling the modules themselves.
- Cache plugins are used to keep a cache of ‘facts’ to avoid costly fact-gathering operations.
- Callback plugins enable you to hook into Ansible events for display or logging purposes.
There are a few more components in Ansible Architecture which are explained below:
Networking: Ansible can also be used to automate different networks. Ansible uses the same simple, powerful, and the agentless automation framework IT operations and development are already using. It uses a data model (a playbook or role) that is separate from the Ansible automation engine that easily spans different network hardware.
Hosts: The hosts in the Ansible architecture are just node systems which are getting automated by Ansible. It can be any kind of machine — Windows, Linux, RedHat etc.
Playbooks: Playbooks are simple files written in YAML format which describes the tasks to be executed by Ansible. Playbooks can declare configurations, but they can also orchestrate the steps of any manual ordered process, even if it contains jump statements. They can launch tasks synchronously or asynchronously.
CMDB: It is a repository that acts as a data warehouse for IT installations. It holds data relating to a collection of IT assets (commonly referred to as configuration items (CI)), as well as to describe relationships between such assets.
Cloud: It is a network of remote servers hosted on the Internet to store, manage, and process data, rather than a local server. You can launch your resources and instances on the cloud and connect to your servers.
ANSIBLE TOWER:
One of the major gripes from Ansible users is that it didn’t have a proper GUI. And that’s putting it mildly — the GUI was so bad that in the early days it wasn’t even properly synced to the CLI, meaning that the CLI and GUI could give you 2 different query results about the state of a certain node. This was an especially critical issue because good UI is important for occasional and new users to get comfortable and familiar with an application, before diving into the complexities of the CLI and playbook creation. Ansible itself was (and still is) rather new, so most of its users were by definition, new users.
Ansible Tower, previously called the AWX project, is the fix to this problem. It is a comprehensive web-based UI for Ansible, containing the most important Ansible features, especially those that render better as graphical rather than text-based output, such as real-time node monitoring.
From Ansible:
Ansible Tower is the easy-to-use UI and dashboard and REST API for Ansible. Centralize your Ansible infrastructure from a modern UI, featuring role-based access control, job scheduling, and graphical inventory management. Tower’s REST API and CLI make it easy to embed Tower into existing tools and processes. Tower now includes the real-time output of playbook runs, an all-new dashboard and expanded out-of-the-box cloud support.
Some of the important features of Ansible Tower are listed below. The full future list is in Ansible website.
- Role-based access control: you can set up teams and users in various roles. These can integrate with your existing LDAP or AD environment.
- Job scheduling: schedule your jobs and set repetition options
- Portal mode: this is a simplified view of automation jobs for newbies and less experienced Ansible users. This is an excellent feature as it truly lowers the entry barriers to starting to use Ansible.
- Fully documented REST API: allows you to integrate Ansible into your existing toolset and environment
- Tower Dashboard: use this to quickly view a summary of your entire environment. Simplifies things for sysadmins while sipping their coffee.
- Cloud integration: Tower is compatible with the major cloud environments: Amazon EC2, Rackspace, Azure.
In short, Ansible Tower is a remarkably useful add-on to Ansible, able to do much of what can be done on the CLI. It will complement, not replace, the main application by automating and presenting some of the main tasks graphically — especially the monitoring-dashboard types of tasks. As a major bonus, it also greatly helps to reduce the intimidation factor for those new to Ansible by presenting a much easier to understand the visual tool. But for playbook creation, Ansible’s CLI is still your best option
Thank you
