Basics of Ansible in DevOps
In this article, I am going to present brief introduction about Ansible & its usage in DevOps. I will also explain its architecture and some advantages. Here we go…..
Ansible and its Advantages
Ansible is an open source IT Configuration Management, Deployment & Orchestration tool. It can also do IT orchestration, where you have to run tasks in sequence and create a chain of events which must happen on several different servers or devices.
DevOps orchestration is the automation of numerous tasks that run at the same time in a way that minimizes production issues and time to market. Automation applies to functions that are common to one area, such as launching a web server, or integrating a web app, or changing a database entry
Ansible is easy to deploy because it does not use any agents or custom security infrastructure.
Ansible uses playbook to describe automation jobs, and playbook uses very simple language i.e. YAML
YAML — It’s a human-readable data serialization language which is very easy for humans to understand, read and write. It is commonly used for configuration files and in applications where data is being stored or transmitted.
Configuration Management
Configuration management in terms of Ansible means that it maintains configuration of the product performance by keeping a record and updating detailed information which describes an enterprise’s hardware and software
Ansible Architecture
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 Configuration Management Database (CMDB).
The Ansible Automation engine consists of :
Inventory
Invertories 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.
Playbooks are simple files written in YAML format which describes the tasks to be executed by Ansible
For e.g.
- Database modules like mssql_db which removes MYSQL databases from remote hosts.
There are over 450 Ansible-provided modules that automate nearly every part of your environment.
Plugins
These are extra pieces of code that augment functionality. Ansible comes with a number of its plugins, but you can write your own as well.
Examples: Action, cache, and callback plugins
Working of Ansible
Ansible works by connecting to your nodes and pushing out small programs, called “Ansible modules” to them. It then executes these modules (over SSH by default), and removes them when finished. Your library of modules can reside on any machine, and there are no servers, daemons, or databases required.
Management Node is the controlling node which controls the entire execution of the playbook. It’s the node from which you are running the installation.
The inventory file provides the list of hosts where the Ansible modules needs to be run and the management node does a SSH connection and executes the small modules on the hosts machine and installs the product/software.
Ansible removes the modules once those are installed so effectively it connects to host machine, executes the instructions and if it’s successfully installed removes the code which was copied on the host machine which was executed.
This article only explains brief introduction to Ansible, its architecture & working.
In my next article I will explain Ansible Installation, Write Ansible Playbooks and Some Ad hoc Commands.
Happy Learning!!!
