Uncategorised

What is Ansible and How its works?

August 14, 2023 comments off

What is Ansible?

  • Founded in February 2012.
  • First commercial product released in the year 2012.
  • Multiple in-built functional modules.
  • Strong community member database.
  • Tremendous users base.
  • Rapid market adaptability since October 2015, after RedHat acquisition.
  • Support for Red Hat, CentOS, Ubuntu, Oracle Linux, MAC,OS,Solaris 10/11, and Windows.
  • Ansible controller node supported on Linux variants only; controller machine cannot be installed on Windows OS yet.
  • Ansible by default manages machines over the SSH protocol.

Ansible in SDLC Cycle?

Ansible History

  • Michael DeHaan, the author of the provisioning server application Cobbler and coauthor of the Func framework for remote administration, developed the platform called “Ansible” on February 20, 2012.
  • It is included as part of the Fedora distribution of Linux, owned by Read Hat Inc., and is also available for red Hat Enterprise Linux, CentOS, and Scientific Linux via Extra Packages for Enterprise Linux (EPEL) as well as for other operating systems.
  • Ansible, Inc. (originally AnsibleWorks, Inc.) was the company set Up to support and sponsor Ansible commercially.
  • RedHat acquired it in October 2015.

Feature of Ansible

Benefits of Ansible

  • Productivity/Efficiency: Ansible takes care of all your regular, repetitive tasks along with deployment and infrastructure management by providing you an opportunity to invest your time in new products to do profit-oriented business. Running of Ansible codes will give you the same result, every time, with 100% consistency and efficiency.
  • Simplicity: Ansaible is written in Python, and is very simple to understand. Ansible is one of the simplest amongst other Configuration Management tools like Puppet and Chef.
  • Scalability: Ansible Inventory (management server list) is scalable with any Cloud Instance, Virtual Machine, and Standalone server in a fraction of seconds by adding an entry in Ansible Inventory file on Controller node. You need not install any agent on the hosts you want to manage through Ansible.
  • Consistency: Codes written in Ansible are idempotent. You will explore more about “idempotent” in the next chapter. Ansible run will always ensure the defined state on the managed nodes and make them consistent across all run.
  • Operation Efficiency: With Ansible, operation teams will have to spend less time in doing regular, repetitive incident management tasks. They can write an Ansible playbook to handle such tasks to save time and solve regular-occurring tasks quickly.

How Ansible works AKA Ansible Architecture?

Ansible is based on Agentless Model with Push based mechanism. There are two types of machines in Ansible architecture which are as follow:

Controller Node/Master Node:
This is a Linux –based machine we install and configure Ansible software. You cannot have Windows OS as your Controller node in Ansible. This host is primarily responsible for maintaining host inventory files”. “Host Inventory Files” are text files on Controller Node with the list of Managed Nodes. System Administrator will log into the Controller to write code in the form of Playbooks and / or to execute ad-hoc commands on Managed Nodes. Hence all Ansible operations are performed from the controller node.

Managed Node /Remote Node:
All other machines which are managed by Controller Master Node are called Managed Node are called Managed Node /Agent Node. Every managed node should have an entry in the “Host Inventory Files” in Controllers/Master Node.

SSH (also referred to as Secure Shell) is the default communication protocol used between Controller Node and Managed Nodes. When you run Ansible from Controller Node, Ansible does the following on Managed Nodes:

  • Log in to the Managed Nodes (through SSH)
  • Install Modules (Ansible-specific Modules and Playbooks-related modules)
  • Execute Playbook and /or Remote ad-hoc Commands ( sets of instructions to be executed on the managed node)

Note:
Push-based mechanism means Ansible Playbooks are pushed from the Controller Note to the Managed Nodes, where the actual Playbooks will run and perform specific action/actions. Puppet and Chef are based on Pull Mechanism whereas Ansible is based on Push Mechanism.

Communication between Servers in Ansible?

The major function of these section are as follows:

  • [defaults]: This section has almost all major configuration settings.
  • [privilege_escalation]: This section defines escalated privileges to run different operations on Managed Nodes
  • [paramiko_connection] : Paramiko is the default SSH connection implementation on Enterprise Linux 6 or earlier, and is not used by default on other platforms (for old OS’s)
  • [ssh_connection]: SSH is default connection type for Ansible on OS.
  • [Persistent _connection]: Persistent connection support allows one SSH connection to stay active across multiple Ansible tasks.
  • [accelerate]: Connection Related Options for optimization
  • [selinux]: To define security settings with Secure Linux
  • [colors]: Different color options for different Ansible outputs

Dataflow in Ansible

Agentless Architecture is a simple example to understand Dataflow of Ansible: Ansible Provisioner Machine is the Controller Machine having Ansible software installed and configured. This machine is responsible for every Ansible operation. Every Admin has to log in to this machine to create or change Ansible codes (called Playbooks) or to run ad-hoc commands to perform specific operations on a set of servers .

Files” to perform operations. Now we can create two separate playbooks.. servers (package installation, configuration, setups, users, groups, services, etc.) and another for web servers (web packages, configurations, index files, users, permissions, files, services). Based on the requirements, you can run the code (Playbook) on a single server or a group of servers to perform operations mentioned in the Playbook.

Ansible will accordingly create a connection with the managed nodes, install the modules, and perform all the operations mentioned in the playbook. On top of it, Ansible run will generate outputs based on executed playbooks on the controller node with status such as failed, .ok, changed, unreachable, etc.

You will learn more about Playbooks, Playbooks run and status checks in chapter 5, Ansible Playbooks. This chapter is just to create a strong foundation of Ansible; you will explore in-depth about all concepts in successive chapters.

Ansible Configurations

It is very important to mention about the file location precedence in which Ansible looks for the configuration parameters:

  • The first priority is given to “ANSIBLE_CONFIG, configuration file location defined by an environment variable”.
  • The second priority is given to “. /ansible. cfg”, the location from where the Ansible is running (current working directory).
  • The third priority is given to “~/ .ansible . efc “ file present in user’s home directory.
  • The last thing comes is default configuration file path “/ etc/sndible /ans ible .cfg”.

Keep in mind that any of the configuration parameters can be changed at run-time while executing Ansible, the values mentioned in the file are ignored if any parameter is mentioned during the Ansible run time.

Multiple configuration files sometimes create a lot of fuss as multiple admins have access to the Controller Node and might be having multiple configuration files. Ansible also provides the flexibility to check active configuration file before executing Ansible run with “–version” option.

Ansible Terminology

Before proceeding with the real Ansible, let us get familiar with the most commonly used terms with Ansible Software.

  • Controller/ Master Node: The Ansible master is the machine that controls the infrastructure and dictates policies for the server it managed. It operates both as a repository for configuration data, and as the control center, it initiates remote commands and ensures the state of your other machines.
  • Managed/Agent Nodes: All machines managed by Controller /Master Node are called Managed Node/Agent Node.
  • Ansible Inventory: Ansible Inventory represent which machines “Ansible Controller Node“should manage by defining it in a very simple plaintext file.
  • Ansible Ad-Hoc Tasks: Ansible user ad –hoc request to confirm simple and small tasks on any server right away without logging into the clien . The best example is to Check the Alive Status for the entire managed inventory.
  • Playbooks: A well- structured way to put all of the defined tasks for Orchestrstion, Configuration, Administration , Server & Application installation and Deployments.
  • Roles: Roles are the best way to organize you playbooks and make your code generic to be shared with anyone.
  • Modules: Modules are the in built function (core modules) the execute at the backend to perform underlined operation in Ansible.
  • *yml files: YAML stands for “ Yet Another Markup Language”. All of the Playbooks in Ansible are written in YAML format with yml extension. “.yml” stand for YAML file.
  • Ansible Galaxy: Ansible Galaxy is a free site for finding downloading, and sharing com- munity- developed roles. Downloading roles for, Galaxy in an excellent way to jumpstart your automation projects.
  • Ansible Vault: “Vault” is a feature of Ansible that allows keeping sensitive data such as password or keys in encrypted file, rather than as plaintext in your Playbooks or roles. These vault file can then be distributed or placed in source control.
  • Ansible Tower: Ansible Tower by Redhat is a web-based solution that makes Ansible even more easy to use for all teams. It is designed to be the hub for all of your automation tasks. One can perform any Ansible task through Ansible Tower with complete visibility.
  • Ansible for Unix /Linux: The Ansible master communication and manages Unix/ Linux
    Clients Using SSH by default.
  • Ansible for Windows: Starting From Ansible version 1.7, Ansible also contains support for managing Windows machines through native PowerShell remoting, rather that SSH and uses the “ winrm” Python module to remote hosts.

Ansible Architecture

Now that you are familiar with many terms used in Ansible, let us understand the Ansible Architecture and communication in simple step

  1. Ansible is installed on one master server called ‘’ Controller Node’’ which acts as central repository server for all Ansible operations.
  2. Ansible inventory is a list of “Managed Nodes‘”,which “Controller Node” will manage for different Ansible operation . Inventory can be sourced from a simple text file (Static Inventory ) or cloud and other sources like CMDBs (Dynamic Inventory).
  3. Playbooks are the list of organized tasks and operation that need to be performed on ‘’ Managed Nodes”.
  4. Core Modules are the in built modules shipped with Ansible to perform tasks and operations on “Managed Nodes” .In simple layman language, the Playbooks are written by using different Ansible Modules . You will learn n about modules and play books in Chapter 4, Ad –Hoc Execution with Ansible and Chapter 5, Ansible Playbooks.
  5. The users also have the flexibility to write customized modules in Ansible and use them as requirements.
  6. Connection plugins establish connection between “Control Node” and “Managed Node”. By default, Ansible Work on Port 22 (for Linux). Ansible also allows using other Plugins for “emails, reports, logging and much more”.
  7. Host1, Host2…Hostn, Private/ Public Cloud Instances are all “Managed Nodes”.

Ansible Terminology

  1. Inventory: An inventory is a list of hosts (or machines) that Ansible manages. It can be defined in a configuration file (typically in INI or YAML format). The inventory file specifies information about each host, such as its IP address, hostname, and group memberships.
  2. Playbook: A playbook is a YAML file that defines a set of tasks to be executed on specific hosts. Playbooks contain a series of plays, each consisting of tasks that Ansible runs in sequence. Playbooks allow you to define complex automation workflows.
  3. Task: A task is a single unit of work that Ansible performs on a host. It can involve tasks like installing a package, copying a file, restarting a service, or running a script. Each task is defined within a play in a playbook.
  4. Module: A module is a standalone script that Ansible uses to interact with systems, perform actions, and retrieve information. Modules are responsible for carrying out individual tasks. Ansible has a wide range of built-in modules that cover various system administration and configuration tasks.
  5. Role: A role is a predefined set of tasks, handlers, and variables that can be reused across multiple playbooks. Roles allow you to organize your playbooks into more modular and manageable components. They help promote code reusability and maintainability.
  6. Handler: A handler is a task defined in a playbook that is only executed if a change occurs that requires it. Handlers are typically used for actions like restarting a service after a configuration change. Handlers are executed after all tasks in a play are completed.
  7. Facts: Facts are system information and data gathered by Ansible when it connects to a host. These facts provide insights into the current state of the system, such as its operating system, hardware details, network configuration, and more. Facts can be accessed and used in playbooks and templates.
  8. Ad-hoc Command: An ad-hoc command is a one-liner Ansible command that you can run directly from the command line, without using a playbook. Ad-hoc commands are useful for quickly executing tasks on remote hosts without the need for a full playbook.
  9. Module Parameters: Modules accept parameters that configure their behavior. These parameters are defined in the playbook and specify how the module should perform its task. For example, the apt module for package management accepts parameters like name and state.
  10. Variables: Variables are values that can be assigned within Ansible playbooks, roles, or inventories. They allow you to parameterize your automation and make it more flexible. Variables can be defined at different levels, such as globally in the playbook, within a role, or even at the command line.
  11. Templates: Templates are text files that contain placeholders for dynamic content. Ansible can use these templates along with variables to generate configuration files tailored to specific hosts. This is especially useful when you need to manage configuration files across multiple hosts.
  12. Tags: Tags allow you to selectively execute specific tasks in a playbook based on user-defined labels. This can be helpful when you want to run only a subset of tasks during playbook execution.

Workflow of Data Transformation

Pre-Requisites for Managed Ansible Node

Ansible uses the agentless mechanism, so there is no requirement to install any Ansible packages on the supported Manages nodes. The only requirement to run Ansible is mode of communication between Controller Node and Managed Nodes and Python compatibility. Python is a pre-requisite because the modules in Ansible are written in Python, and hence a compatibility for Ansible run.

Ansible handles the communication by using secure, reliable SSH protocol by default for Linux.

Note: Since Ansible version 1.7, Ansible started support for managing Windows machines, which use native PowerShell remoting, rather than SSH. Managed Nodes require Python 2.6 or greater version, but in OS’s, where lower Python version are installed, ensure that it is not lower than Python version 2.4. If installed version is older than Python version 2.5 on managed nodes, install “python-simplejson” package to get Ansible work on Managed Nodes.

Ansible connects with Managed Nodes using the same username you have logged in while running Ansible on Controller Node. For example, if you log in as a user “yogesh” on Controller ensure that the user has proper privileges to connect to the Managed Nodes. In such cases, ensure that the user has proper privileges to run commands.

By default Ansible user SSH During communication this communication connection

Rajesh Kumar
Follow me
Latest posts by Rajesh Kumar (see all)