Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Getting Started With Ansible

DZone's Guide to

Getting Started With Ansible

Learn about configuration management with Ansible automation engine, what it can do for you, and how to install and set it up.

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

What Is Configuration Management?

Before starting with Ansible, let's discuss what configuration management is. Configuration Management (CM) is the process of handling changes in any system systematically, and it maintains the consistency of the product. It retains its consistency because it is applied over the entire lifecycle of the system. Configuration Management provides the capability of controlling and monitoring the performance of the system. Using this capability of monitoring we can prevent errors by notifying and controlling the capability to change anything in the system. If any of node in cluster gets failed we can reconfigure it. Also, configuration management keeps the snapshot of all the version of infrastructure.

Why Configuration Management?

The reason why we should use configuration management is to overcome the difficult situation that we face while setting up the cluster. A few of these are:

  • Managing multiple servers
  • Scaling up and scaling down
  • Syncing up with development team and infrastructure team

What Is Ansible?

Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs. It can be used for advanced tasks such as continuous deployments or zero downtime rolling updates. Ansible is a push-based configuration management tool; it means we can push configuration onto the node machine directly without having any central node. It communicates with remote machines over SSH. The main goals of Ansible are ease of use and simplicity.  

Features of Ansible

  • Simple and easy to use
  • Agentless
  • YAML-based playbook

Installation

Ansible communicates with other node using SSH protocol. It does not require any database installation or any running process. You only need to install it on one machine; it can even be your local machine. You just need Python installed on your system. However, Windows is not supported for the control machine.

Ubuntu:

sudo apt install ansible


CentOS/Fedora :

sudo dnf install ansible
yum install ansible

 

Arch Linux-based :

sudo pacman -S ansible


FreeBSD :

sudo pkg install ansible

 

PIP :

sudo pip install ansible


Ansible Inventory

Ansible can work for multiple systems at a time. It achieves this by selecting portions of systems listed in Ansible’s inventory, which is by default saved in the location /etc/ansible/hosts. You can specify a different inventory file using the -i <path> option on command line.

The inventory file can be in one of many formats, depending on the inventory plugins you have. For this example, the format for /etc/ansible/hosts is an INI-like and looks like this:

[mailservers]
mail.example.com

[webservers]
foo.example.com
bar.example.com

[dbservers]
one.example.com
two.example.com
three.example.com


A YAML version would look like this:

all:
  hosts:
    mail.example.com
  children:
    webservers:
      hosts:
        foo.example.com:
        bar.example.com:
    dbservers:
      hosts:
        one.example.com:
        two.example.com:
        three.example.com:


It is easy to assign variables to hosts that will be used in playbooks:

[testservers]
host1 http_port=80 maxRequestsPerChild=808
host2 http_port=303 maxRequestsPerChild=909


We can also define variables that can be applied to an entire group:

[testservers]
host1
host2

[testserver:vars]
ntp_server=ntp.testservers.example.com
proxy=proxy.atlanta.example.com


In Ansible inventory, we can create groups of groups and can set a variable for those groups of groups:

[india]
host1
host2

[japan]
host3
host4

[asia:children]
India
Japan

[asia:vars]
ansible _user=value

[world:children]
asia
europe


There are two default groups: all and ungrouped. all contains every host and ungrouped contains all the hosts that do not have a group aside from all.

Ansible Ad-Hoc Commands

An ad-hoc command is something that you might type in to do something rapidly, but don’t want to save for later. Just like executing a command in the shell instead of creating the shell script for that. An ad-hoc command contains two different parameters; the host group on which task is going to run and the module to run. If you want to ping each host with a single command, you can do it using the following:

ansible host_group -m ping

Similarly, you can perform many other operations using ansible like copying a file, managing packages, gathering facts, etc.

Ad-hoc commands are a powerful yet straightforward feature of Ansible.

Ansible Playbook and Modules

Playbooks are a completely different way to use Ansible than in ad-hoc task execution mode and are particularly powerful. There is a way to send commands to the remote node using the script, like a shell script that contains the set of command. Ansible Playbooks are written in the YAML format. YAML is a data serialization language.

In every Playbook, there are one or more "plays" in a list. The goal of the play is to map hosts with a certain function. Ansible does it through the task, which is nothing more than a call to an Ansible module.

Example of a playbook:

---
- hosts: webservers
  vars:
    http_port: 80
    max_clients: 200
  remote_user: root
  tasks:
  - name: ensure apache is at the latest version
    yum: name=httpd state=latest
  - name: write the apache config file
    template: src=/srv/httpd.j2 dest=/etc/httpd.conf
    notify:
    - restart apache
  - name: ensure apache is running (and enable it at boot)
    service: name=httpd state=started enabled=yes
  handlers:
    - name: restart apache
      service: name=httpd state=restarted


Every playbook starts with three dashes (---) followed by host list, then a variable list, then a task list, and at the end there are handlers.

The host list contains the list of hosts where we want to run the task.

The variable list is to set the properties for the current play.

The task list contains the number of tasks which are going to execute.

The handlers are also tasks; the only difference is that in order to execute handler we need some trigger in the list of task. For example, notify. These ‘notify’ actions are triggered at the end of each block of tasks in a play, and will only be triggered once even if notified by multiple different tasks.

To run a playbook, we can use the following command:

ansible -playbook


Ansible ships with many modules (called the "module library") that can be executed directly on remote hosts or through Playbooks.

Users can also write their own modules. These modules can control system resources like services, packages, or files (anything really), or handle executing system commands.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:
devops ,ansible ,configuration ,managaement

Published at DZone with permission of Prabhat Kashyap, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}