Ansible

Ansible is an open-source software provisioning, configuration management, and application-deployment tool enabling infrastructure as code.
It runs on many Unix-like systems, and can configure both Unix-like systems as well as Microsoft Windows.
It includes its own declarative language to describe system configuration.
Ansible was written by Michael DeHaan and acquired by Red Hat in 2015.
Ansible is agentless, temporarily connecting remotely via SSH or Windows Remote Management (allowing remote PowerShell execution) to do its tasks.

Advantages

1) Provisioning of servers
The applications that should be installed on server can be done very quickly from a single centralized location.

2) Idempotent
Configuration management tools are used to bring the server to a particular state, called as desired state. If a server already in the desired state, configuration management tools will not reconfigure that server.
They can be used only for managing the applications on top of the OS.
Configutaion management tools - Ansible, chef, puppet, salt etc

Installation Python2 on node machines

Ubuntu machines default come with Python3
Ansible supports Python2
We need to downgrade the machines from python3 to Python2

Connect to machine
Check the version

$ python3 –version

To Install Python2
$ sudo apt-get update
$ sudo apt-get dist-upgrade ( It will point to older apt repository where python2 is available)

$ sudo apt-get install -y python2.7 python-pip

Now check the version of python
$ python –version

Establish password less ssh connection

$ sudo passwd ubuntu ( lets give the password anything you want only )

$ sudo vim /etc/ssh/sshd_config

change
PasswordAuthentication yes
Save and QUIT
$ sudo service ssh restart
$ exit
** we need to generate ssh keys in conroller machine and copy the key into nodes which ever we have created.
** ssh-copy-id node_machine_name@private_ip of_node machines

Installing Ansible on controller machine

$ sudo apt-get install software-properties-common ( software-properties-common , is a base package which is required to install ansible )

$ sudo apt-add-repository ppa:ansible/ansible

$ sudo apt-get update

$ sudo apt-get install -y ansible

+++++++++++++++++
To check the version of ansible

$ ansible –version

Adding the ip address of nodes in the inventory file

$ sudo vim /etc/ansible/hosts
insert the private ip addresss of 3 servers, save and quit

Ansible performs remote configurations in 2 ways

1) using adhoc commands
2) using play books

Common syntx of adhoc commands

$ ansible all/group_name/ipaddress -i path_of_inventory_file -m modulename -a ‘arguments’
Notes
===> we can create our own inventory file if we need and can add the private ip address of the wanted node machines
===> The defualt inventory file is /etc/ansible/hosts and when using this inventory file, we need not use -i option
===> If we do not mention the inventory file, it takes default inventory file
===> command module is the default module in ansible

Adhoc commands

===> Important modules in ansible
1) command - This module is used for executing basic linux commands on managed nodes.
2) shell - This module is used to execute commands which involved redirection and piping and to execute shell scripts on managed nodes.
3) ping – This module is used to check if the remote server is pingable or not.
4) user – This module is used for user management like create user, setting password, assign home directory etc
5) copy – This module is used to copy the files and folders from controller to managed nodes.
6) fetch – This module is used to copy files and folder from managed nodes to controller.
7) file – This module is used for creating or deleting files and folders on managed nodes.
8) stat – Used to capture detailed information about files and folders present in managed nodes.
9) debug – Used to display output of any module.
10) apt – Used for performing package management on managed nodes ie installing softwares / upgrading repositories etc . It works on ubuntu, debain flavours of linux.
11) yum – similar to apt module. It works on Red hat linux, centos etc
12) git – used to perform git version controlling on managed nodes
13) replace – This is used to replace specific text in configuration file with some other text.
14) service – used for starting / stoping / restarting services on managed nodes.
15) include – Used for calling child play books from parent play book.
16) uri – useful in checking if remote url is reachable or not.
17) docker_container – used to execute docker commands related to container management on managed nodes.
18) docker_image – used to execute commands related to docker images on managed nodes.
19) docker_login – used to login to docker hub from managed nodes.
20) setup – used to capturing system information related to the managed nodes.
++++++++++++++++++++++++++++++++++++++++++++++++
If you want to create users in all node machines
$ ansible all -m user -a ‘name=ria password=daya’
If we run the above command we will get error ( permission denied )
$ ansible all -m user -a ‘name=ria password=daya’ -b ( become , for higher privileges on managed nodes )
++++++++++++++++++++++++++++++++++++++++++++++++
Command to create user and set home directory, user id, default working shell etc
Another example
$ ansible all -m user -a ‘name=Ravi password=freefree uid=1234 comment=”A regular user” home=/home/ubuntu/Ravi shell=/bin/bash’ -b
To check for the new user in node machine
$ ssh 172.31.44.218(private_ip of_node machine) $ vim /etc/passwd
+++++++++++++++++++++++++++++++++++++++++++++++
apt module – This is used for package management
$ ansible all -m apt -a ‘name=git state=present’ -b
—> state=present is for installation
—> state=latest is for upgradation
—> state=absent is for uninstallation

Play books

Adhoc commands are capable of working only on one module and one set of arguments.When we want to perform complex configuration management activities, adhoc commands will be difficult to manage.
In such scenarios, we use play books.Play book is combination of plays. Each play is designed to do some activity on the managed nodes. These plays are created to work on single host or a group of hosts or all the hosts.
The main advantage of play books is reusability.
Play books are created using yaml files.
++++++++++++++++++++++++++++++++++++++++++++
$ mkdir playbooks
$ cd playbooks
$ vim playbook1.yml

playbook.txt

To check the syntax:
$ ansible-playbook playbook1.yml –syntax-check

note —-> ( Do not use tab when creating yml file )

To run the playbook
$ ansible-playbook playbook1.yml -b
+++++++++++++++++++++++++++++++++++++++++

Creating reusable playbooks using variables

Three types of variables
1) Global scope variables ( highest priority ) - we pass values from command prompt
2) Host scope variables
3) play scope variables ( least priority )

Ex of Global scope variables
playbook2.txt

To run the playbook by passing values to the variables
$ ansible-playbook playbookname.yml –extra-vars “a=git b=absent c=no” -b

( The above command will uninstall git from all nodes )

Run the same playbook with diffrent values
$ ansible-playbook playbookname.yml –extra-vars “a=tree b=present c=no” -b
Playscope variables are definined within the playbook and they can effect only in one single play
play_scope_variables.txt
$ ansible-playbook play_scope_variables.yml -b

We can run by using extra vars from command line
$ ansible-playbook playbook_name.yml –extra-vars “a=tree b=present c=no” -b

The above command will install tree because global scope variables have higher priority

Notes: Playscope variables are definied at level of individual plays and they can effect only one play.
—> The above playbook works like a template, who’s default behaviour is to install tomcat8 but, we can by pass that behaviour and make it work in some other software by passing the variables as extra vars
Host scope variables These variables are classified into 2 types
1) Variables to work on group of hosts
2) Variables to work on single hosts
Variables to work on group of hosts These variables are designed to work on group of hosts.
They are definined in a folder called group_vars.
This group_vars folder should be presnent in the same folder where all the playbooks are present.
In this group_vars folder, we should create a file who’s name is same as group_name in Inventory file.
In this file we create variables.
Varibles which work in group of hosts are divided into two types
1) Variables which work in group of machines
2) Variables which work on one machine
Variables which work in group of machines
We can do grouping using [groupname]
To do grouping
$ sudo vim hosts
[webserver]
172.31.11.96
172.31.6.207
[appserver]
172.31.12.138
[dbserver]
172.31.31.161
note: those are private ips of the node machines which we are using
$ mkdir group_vars
$ cd group_vars
$ vim webserver
a: Prakash
b: logiclabs
c: /home/Prakash
d: 67809
e: /bin/bash

Save and Quit

$ cd ..
playbooks$ vim playbook8.yml

playbook3.txt

save and quit
TO run the playbook
$ ansible-playbook playbook8.yml -b ( It runs on two machines)
Variables to work on single hosts
These variables are designed on single machine.
Thet are created in folder called host_wars
This host_wars folder should be created in the same location of where the playbooks are present.

playbooks$ mkdir host_vars
$ cd host_vars
$ vim 172.31.6.241 ( 172.31.6.241 private Ip of node)

a: firewalld
b: present
c: yes

save and quit
$ cd ..
$ vim playbook4.yml

playbook4.txt

save and quit

$ ansible-playbook playbook4.yml -b

Implemneting loops

Modules in ansible can be executed multiple times using loops $ vim playbook5.yml playbook5.txt
$ ansible-playbook playbook11.yml -b

Handlers

Handler is a piece of code which is executed, if some other module is executed successfully and it has made some changes.
Handlers are always executed only after all the tasks are executed.
Handlers are executed in the order that are mentioned in the handler section, and not in the order they are called in the tasks section.
Even if handler is called multiple times in the tasks section, it will be executed only once.
$ vim playbook6.yml
playbook6.txt
$ ansible-playbook playbook6.yml -b
Note:
—> As editing the index.html file is successfull, handler is executed.
—> If you re run the playbook, handler is not executed.

Error Handling

If any module fails in ansible,the execution of the playbook terminates over there.
When we know that certain module might fail, and still we want to continue playbook execution, we can use error handling.
The section of code which might generate an error should be given in block section.
If it generates an error, the control comes to rescue section.
Always section is executed every time, irespective of whether the block is successfull or failure.

$ vim playbook7.yml
playbook7.txt

$ ansible-playbook playbook7.yml -b