Ansible– Modules

Ansible – Modules

Modules in Ansible are idempotent. From a RESTful service standpoint, for 
an operation (or service call) to be idempotent, clients can make that 
same call repeatedly while producing the same result. In other 
words, making multiple identical requests has the same effect as making a single request.

There are different types of modules in Ansible

• Core modules
• extras modules

Core Modules

These are modules that the core Ansible team maintains and will 
always ship with Ansible itself. They will also receive slightly higher
 priority for all requests than those in the “extras” repos.

The source of these modules is hosted by Ansible on GitHub in the 
Ansible-modules-core.

Extras Modules

These modules are currently shipped with Ansible, but might be shipped 
separately in the future. They are also mostly maintained by the Ansible
 community. Non-core modules are still fully usable, but may receive slightly 
lower response rates for issues and pull requests.

Popular “extras” modules may be promoted to core modules over time.

The source for these modules is hosted by Ansible on GitHub in the 
Ansible-modules-extras.

E.g: The one of the extras module in Remote Management Modules 
is ipmi_power module, which is a power manger for the remote machines. 
It requires python 2.6 or later and pyghmi to run.

You can use this module by writing an adhoc command like the one I have written below:

ipmi_power : name ="test.domain.com" user="localhost" password="xyz" state="on"

Ansible  – Return Values

Ansible modules normally return a data structure that can be registered into a variable, or seen directly when output by the Ansible program. Each module can optionally 
document its own unique return values.

Some examples of return values are:

• changed: returns with a boolean value whenever the task makes any change.
• failed: returns a boolean value, if the task is failed
• msg: it returns a string with a generic message relayed to the user.

Ansible – AdHoc Commands

Adhoc commands are simple one line command to perform some action. 
Running modules with Ansible commands are adhoc commands.

E.g: 

ansible host -m netscaler -a "nsc_host=nsc.example.com user=apiuser password=apipass"

The above adhoc command uses the netscaler module to disable the server. There are hundreds of modules available in Ansible from where you can refer to and write adhoc commands.

Well, enough with all the theoretical explanations, let me explain you Ansible with some hands on.

Let’s begin :)

Step 1: Connect to your hosts using SSH. For that, you need to generate a public SSH key.

Use the command below:

ssh-keygen

As you can see in the snapshot above, the command ssh-keygen generated
 a public SSH key.

Step 2: Your next task is to copy the public SSH key on your hosts. In order to
 do that, use the command below:

ssh-copy-id -i root@<IP address of your host>

The snapshot above shows the SSH key being copied to the hosts.

Step 3: List the IP addresses of your hosts/nodes in your inventory. 

Use the following command:

vi /etc/ansible/hosts

This will open a vi editor where you can list down the IP addresses of your hosts. This is now your inventory.

Step 4: Let’s ping to ensure a connection has been established.

The snapshot above confirms that connection has been made between your control machine and host.

Step 5: Let us now write a playbook to install Nginx on the host machine. You can write your playbook in the vi editor. For that, simply create your playbook, using the command:

vi <name of your file>.yml

The below snapshot shows my playbook to install Nginx written in YAML format

The tasks of a playbook are defined in YAML as a list of dictionaries and executed 
from top to bottom. If we have several hosts, then each task is tried for each host before 
moving on to the next one. Each task is defined as a dictionary that can have several keys, 
such as “name” or “sudo” which signify the name of the task and whether it 
requires sudo privileges. 

A variable server_port is set that listens on TCP port 8080 for incoming requests.

Here, the first task is to get the necessary package for installation of Nginx and then install it. Internally, Ansible will check if the directory exists and create it if it’s not, otherwise it will do nothing.

The next task is to configure Nginx. In Nginx, contexts contain configuration details.

Here, the template is a file you can deploy on hosts. However, 
template files also include some reference variables which are pulled from variables defined as part of an Ansible playbook or facts gathered from the hosts. 
Facts containing the configuration details are being pulled from a source directory and being copied to a destination directory.

Handlers here define the action to be performed only upon notification of tasks or state changes. In this playbook, we defined, notify: restart Nginx handler which
 will restart Nginx once the files and templates are copied to hosts.

Now, save the file and exit.

Step 6: Now let’s run this playbook, using the command below:

ansible-playbook <name of your file>.yml

We can see in the screenshot above that our task is getting executed; Nginx being installed.

Step 7: Let’s check if Nginx is installed on my host machine. Use the command below:

ps waux | grep nginx

now the screenshot above, that different process ids 3555 and 103316 are running which ensures that Nginx is running on your host machines.

deployed Nginx on your host using Ansible playbooks. 

Hosts And Users:

For each play in a playbook, you get to choose which machines in your infrastructure to target and which remote user to complete the tasks. To include hosts in Ansible inventory, we will be using the IP addresses of the host machines.

Generally the hosts are a list one or more groups or host patterns, separated by colons. The remote user is just the name of the user account.

Variables:

Ansible uses variables which are defined previously to enable more flexibility in playbooks and roles. They can be used to loop through a set of given values, access various information like the host name of a system and replace certain strings in templates with specific values.

Ansible already defines a rich set of variables, individual for each system. Whenever Ansible will run on a system, all facts and information about the system are gathered and set as variables.

But there is a rule for naming variables. Variable names should be letters, numbers, and underscores. Variables should always start with a letter. E.g. wamp_21, port5 is valid variable names, whereas 01_port, _server are invalid.

Tasks:

Tasks allow you to break up bits of configuration policy into smaller files. Task includes pull from other files. Tasks in Ansible go with pretty much the English meaning of it.

E.g: Install <package_name>, update <software_name> etc.

Handlers:

Handlers are just like regular tasks in an Ansible playbook, but are only run if the Task contains a notify directive and also indicates that it changed something. For example, if a config file is changed, then the task referencing the config file may notify a service restart handler.

let me give you an example of a playbook which will start the Apache httpd server program:

---
- 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

how to install Ansible on Ubuntu

ppa:ansible/ansible repository 

sudapt-add-repository -y ppa:ansible/ansible
sudapt-get update
sudapt-get install -y ansible 

This installs Ansible globally.

Virtualenv's
This is my preferred way to install Ansible.

We can also use Pip to install virtualenv, which lets us install Python libraries in their own little environment that won't affect others (nor force us to install tools globally).

Here's how:

# Install python2.7 (Ubuntu 16.04 comes with python 3 out of the box) and Pip
sudo apt-get install -y python2.7 python-pip

## Use Pip to install virtualenv
### -U updates it if the package is already installed
sudo pip install -U virtualenv
Once we have pip and virtualenv installed globally, we can get Ansible inside of a virtual environment:

# Go to my user's home directory, 
# make a directory to play with ansible
cd ~/
mkdir ansible-play
cd ansible-play

# Create a python virtual environment
virtualenv .venv
# Enable the virtual environment
source .venv/bin/activate

# Then anything we intall with pip will be
# inside that virtual environment
pip install ansible
Those commands will install the latest stable Ansible 2 (as of this writing).

Later, when you're done, you can deactivate the virtualenv via the deactivate command
At any time, you can update ansible by running:

# Assumes the virtualenv is active - `source .venv/bin/activate`
# Assuming the virtualenv is active
pip install -U ansible

Remote Connection Information-Ansible

Before we get started, it’s important to understand how Ansible communicates with remote machines over SSH.

By default, Ansible will try to use native OpenSSH for remote communication when possible. This enables ControlPersist (a performance feature), Kerberos, and options in ~/.ssh/config such as Jump Host setup. However, when using Enterprise Linux 6 operating systems as the control machine (Red Hat Enterprise Linux and derivatives such as CentOS), the version of OpenSSH may be too old to support ControlPersist. On these operating systems, Ansible will fallback into using a high-quality Python implementation of OpenSSH called ‘paramiko’. If you wish to use features like Kerberized SSH and more, consider using Fedora, OS X, or Ubuntu as your control machine until a newer version of OpenSSH is available for your platform.

Occasionally you’ll encounter a device that doesn’t support SFTP. This is rare, but should it occur, you can switch to SCP mode in Configuring Ansible.

When speaking with remote machines, Ansible by default assumes you are using SSH keys. SSH keys are encouraged but password authentication can also be used where needed by supplying the option --ask-pass. If using sudo features and when sudo requires a password, also supply --ask-become-pass (previously --ask-sudo-pass which has been deprecated).

While it may be common sense, it is worth sharing: Any management system benefits from being run near the machines being managed. If you are running Ansible in a cloud, consider running it from a machine inside that cloud. In most cases this will work better than on the open Internet.

As an advanced topic, Ansible doesn’t just have to connect remotely over SSH. The transports are pluggable, and there are options for managing things locally, as well as managing chroot, lxc, and jail containers. A mode called ‘ansible-pull’ can also invert the system and have systems ‘phone home’ via scheduled git checkouts to pull configuration directives from a central repository.

Ansible - Introduction

Ansible is simple open source IT engine which automates application deployment, intra service orchestration, cloud provisioning and many other IT tools.

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 (It’s a human-readable data serialization language & is commonly used for configuration files, but could be used in many applications where data is being stored)which is very easy for humans to understand, read and write. Hence the advantage is that even the IT infrastructure support guys can read and understand the playbook and debug if needed (YAML – It is in human readable form).

Ansible is designed for multi-tier deployment. Ansible does not manage one system at time, it models IT infrastructure by describing all of your systems are interrelated. Ansible is completely agentless which means Ansible works by connecting your nodes through ssh(by default). But if you want other method for connection like Kerberos, Ansible gives that option to you.

After connecting to your nodes, Ansible pushes small programs called as “Ansible Modules”. Ansible runs that modules on your nodes and removes them when finished. Ansible manages your inventory in simple text files (These are the hosts file). Ansible uses the hosts file where one can group the hosts and can control the actions on a specific group in the playbooks.

For Ansible, nearly every YAML file starts with a list. Each item in the list is a list of key/value pairs, commonly called a “hash” or a “dictionary”. So, we need to know how to write lists and dictionaries in YAML.

All members of a list are lines beginning at the same indentation level starting with a “- ” (dash and space). More complicated data structures are possible, such as lists of dictionaries or mixed dictionaries whose values are lists or a mix of both.

e.g. For a list of departments:

departments:
- marketing
- sales
- solutions

Now let me give you an example of a dictionary:

-USA
-continent: North America
-capital: Washington DC
-population: 319 million