Ansible: Infrastructure As A Code(IAAC)

Ansible is an Open-source software used for provisioning, configuration management and application-deployment.It can run on linux kernel systems and can configure both linux and windows systems. It was written by Michael DeHaan and acquired by Red Hat in 2015. Ansible is agentless, it doesn’t requires any agent to be installed on the remote hosts. It uses SSH to connect linux kernel systems and Windows Remote Management to connect windows machines.

Infrastructure As A Code(IAAC)

Infrastructure as Code means that we can use a machine-readable automation language to define and describe the state of IT infrastructure and make the desired changes in it. Ideally a automation language should be very easy to read & understand, because then we can easily understand what is the current status and make changes needs on it. Ansible allows us to implement Infrastructure as Code practices.

If a automation language is represented in simple text files, it can be easily managed in a version control system like software code. Advantage is that every change can be checked into the version control system, so that we have a history of the changes we make over time. If we want to revert to an earlier known-good configuration, we can simply check out that version of the code and apply it to our infrastructure.

Strengths of Ansible

1. It supports cross platforms and provides agentless support for Linux, Windows, and network devices, in physical, virtual, cloud, and container environments.
2. Ansible Playbooks are written in YAML text files, and are easy to read and help ensure that everyone understands, we can say it as Human-readable automation.
3. Every changes  made by Ansible Playbooks, and every aspect of our application environment can be described and documented using Ansible.
4. Ansible Playbooks and projects are in plain text. They can be treated like source code and placed in existing version control system, it can easily managed by version control system.
5. Ansible supports for dynamic inventory, lists of machines that ansible manages can be dynamically updated from external sources  to capture the correct, current list of all managed hosts all the time, regardless of infrastructure or location.
6. Other systems that exist in our environment (i.e HP SA, Puppet, Jenkins, Red Hat Satellite etc.) can be leveraged and integrated into Ansible workflow.

 

Ansible: The Language of DevOps

Communication is the key of DevOps. Ansible is automation language that can be read and written across IT. It is only automation engine that can automate the application life cycle and continuous delivery pipeline from start to finish.

Ansible Concepts and Architecture

There are two types of hosts in the Ansible architecture control nodes and managed hosts. Ansible is installed and run from a control node. A control node could be an administrator’s laptop, a system shared by many administrators, or a server running Red Hat Ansible Tower. Managed hosts are listed in  inventory, which also organizes the systems into groups for easier collective management. The inventory can be defined in a static text file or dynamically determined by scripts that get information from external sources(i.e adding and deleting nodes in Kubernates autoscaling)

Ansible users create high-level plays Instead of writing complex scripts, to ensure a host or group of hosts are in a particular state. A play performs series of tasks on the hosts, in the order specified by the play. These plays are expressed in YAML format in a normal text file. A file that contains one or more plays is called a playbook.

Each task runs a module( A small piece of code with specific arguments). Each module works like a tool in your toolkit. Ansible ships with thousands of useful modules that can perform a wide variety of automation tasks. They can act on system files/directories, install/uninstall softwares, or make API calls.

Playbooks are designed to be idempotent, we can run a playbook multiple times on the same host, it will not make any changes if the system is in correct state.

Ansible also uses plug-ins. Plug-ins are the code that you can add to Ansible to extend it and adapt it to new uses and platforms.

Use Cases of Ansible

Ansible combines and unites orchestration with configuration management, provisioning, and application deployment in one easy-to-use platform. some use cases are explained below.

Configuration Management

Centralizing configuration file management and deployment is a most common use case for Ansible, and it is how many users are introduced to the Ansible automation platform.

Application Deployment

When we define our application with Ansible, and manage the deployment with Ansible, teams can effectively manage the entire application life cycle from development to production.

Provisioning

Ansible can help streamline the process of provisioning systems, whether you are PXE booting and kickstarting bare-metal servers or virtual machines, or creating virtual machines or cloud instances from templates. Applications have to be deployed or installed on systems.

Continuous Delivery

Creating a CI/CD pipeline requires coordination from many teams. You can’t do it without a simple automation platform that everyone in your organization can use. Ansible Playbooks keep the applications properly deployed throughout their entire life cycle.

Security and Compliance

When security policy is defined in Ansible Playbooks, scanning and remediation of site-wide security policies can be integrated into other automated processes.

Orchestration

Configurations alone do not define any environment. We need to define how multiple configurations interact, and ensure the disparate pieces can be managed as a whole.

How to Install Ansible

It is very simple to install Ansible.  Ansible software only needs to be installed on the control node from which Ansible will be run. Hosts that are managed by Ansible do not required to have Ansible installed. Ansible Installation involves few steps and has minimal requirements.

The control node must be a Linux or UNIX system. Microsoft Windows is not supported as a control node, although Windows systems can be the managed hosts.

Python 3 (version 3.5 or later) or Python 2 (version 2.7 or later) needs to be installed on the control nodes.

Install Ansible Engine on Control node

[root@onionlinux ~]# yum install ansible

Linux and UNIX managed hosts need to have Python 2 (version 2.6 or later) or Python 3 (version 3.5 or later) installed for most modules to work properly.

Install Python in Managed node

[root@onionlinux ~]# yum module install python36

 

Microsoft Windows managed hosts require PowerShell 3.0 or later on the managed host rather than Python. In addition, the managed hosts must have PowerShell remoting configured. Ansible also requires at least .NET Framework 4.0 or later to be installed on Windows managed hosts.

To senup windows managed host you can follow https://docs.ansible.com/ansible/latest/user_guide/windows.html.

We can write Ansible Playbooks for network devices using the same basic techniques that we uses when writing playbooks for servers. Because most network devices cannot run Python, Ansible runs network modules on the control node, not on the managed hosts. some  special connection methods are used to communicate with network devices, typically using either CLI over SSH, XML over SSH, or API over HTTP/HTTPS.

Follow   Ansible for Network Automation document to setup managed host for networking devices.