Ansible Playbooks

Ansible Playbooks
Techiio-author
Written by Nilima PaulJanuary 17, 2022
12 min read
Ansible
0 VIEWS 0 LIKES 0 DISLIKES SHARE
0 LIKES 0 DISLIKES 0 VIEWS SHARE
Techiio-author
Nilima Paul

Technology Security Analyst

We will know in this article, what's the Ansible Playbooks.

Introduction to Ansible Playbooks

Ansible playbook is a document that contains a bunch of directions or setups that should be applied on a particular server or a gathering of servers. It is written in YAML know at this point Another Markup Language. It depicts the Desired State Configuration of the servers in our current circumstances. We can likewise utilize Ansible Playbook to arrange a portion of our manual arranged cycles. Ansible playbook is more remarkable than the impromptu orders in Ansible as we can run just one undertaking in a specially appointed order, nonetheless, we can compose various plays and run numerous errands under one play in Ansible Playbook. We utilize the ansible-playbook order to execute the playbook.

Attributes of Ansible Playbooks

Let’s understand the attributes of Ansible Playbook using the below playbook (nginx.yml):

---
- hosts: ansible_client.lab.com
vars:
http_port: 80
remote_user: root
tasks:
- name: Install nginx
yum:
name: nginx
state: latest
tags: nginx_service
- name: copy configuration file
template:
src: /root/index.html
dest: /usr/share/nginx/html
notify:
- restart nginx
- name: Check nginx service is running and enabled
service:
name: nginx
state: started
enabled: yes
tags: nginx_service
handlers:
- name: restart nginx
service:
name: nginx
state: restarted

1. hosts: It characterizes a server or a gathering of servers on which we need to run the errands referenced under it. We can utilize an example to characterize the hosts. We can utilize examples to characterize has. We can run assignments against at least one server or at least one gatherings isolated by colons, as host1:host2 or webserver:dbserver. We can utilize trump cards also like 'web*' characterizes all have that beginning with the 'web'. Characterized has should exist in the stock.

Example of some patterns are as below: –

blogpost

If we are running a playbook on all hosts in inventory then we can control the order of the hosts. We can define ‘order’ as inventory, reverse_inventory, sorted, reverse_sorted, and shuffle.

2. vars: It defines variables that we can use in the playbook. Same as the other programming language.

3. remote_user: It characterizes the client under which errands will run on the hosts. We can characterize diverse remote_user to each undertaking if requires. We can utilize the 'become' catchphrase and make it 'yes' to give sudo admittance to the remote_user if the far-off client doesn't root, nonetheless, in the above model, we are running assignments under the 'root' client.

4. tasks: We characterize assignments in a playbook. It characterizes how to treat the referenced hosts. Errands execute in arrangement as characterize in the playbook start to finish. Each errand has one module related with it that lets undertakings know what activity needs to perform on the hosts. The force of the Ansible is modules, there are a ton of pre-fabricated modules accessible in Ansible and we can make our own modules too. For instance, it has a 'yum' module to introduce the bundle on RedHat based OS, 'administration' module to work with administrations, 'document' module to work with records, 'shell' module to execute shell order on the hosts, and so on

5. tags: We can give a tag to the assignment and we can indicate the tag while running the playbook with the goal that main those undertakings will run which has a similar tag. It is valuable assuming there are many undertakings in a similar play, for instance, hardly any assignments are connected with web servers and scarcely any errands are connected with DB servers then we can label the errands connected with web servers with one tag and DB servers with various tag and at whatever point we want to run just errands that are connected with web servers we can utilize the tag related with web servers as well as the other way around.

6. handlers: It characterizes the following activity assuming there is any change made to the host after finishing any assignments that have a 'tell' trait related to them. The controller executes possibly once regardless of whether a similar overseer is advised by various undertakings. It runs toward the end when all errands in the play have been finished. Various overseers can be informed by a solitary undertaking.

We have one controller named 'restart Nginx in the above model and it will be set off by the assignment 'Duplicate arrangement record' as we want to restart the Nginx administration on the off chance that any setup changes have been made.

Let’s run the above playbook using below command and understand the options that we can pass while executing the playbook from the command line: –

Syntax:

ansible-playbook <playbook_name><optional_arguments>

Example:

ansible-playbook nginx.yml

Explanation: –

In the above model, we have run the Ansible playbook 'nginx.yml' with next to no discretionary contentions. There is one play in the playbook. It begins the play and runs a default task called 'Assembling Facts'. After get-together current realities about the host, it runs the primary undertaking from the play for example 'Introduce Nginx and afterward the second errand 'duplicate arrangement record', this assignment additionally triggers the overseer as there are a few changes made to the hosts by this undertaking and afterward the last assignment executes that guarantee Nginx administration is running and it is empowered. Overseer 'restart Nginx runs toward the end once all assignments are finished.

Let’s understand the color code: –

  1. Green – No changes made to the hosts
  2. Yellow – Changes have been made to the hosts
  3. Red – Task failed due to some reason

Arguments of Ansible Playbooks

There are many optional arguments can be passed to the ansible-playbook command, let’s discuss some essential options: –

1. –list-hosts:

It does not change anything on the hosts, just displays the list of hosts on which that play is going to execute.

Example:

ansible-playbook nginx.yml –list-hosts

2. –list-tags: It shows all available tags in the playbook.

Example:

ansible-playbook nginx.yml --list-tags

3. –list-tasks: It shows all available tasks in the playbook and also associated tags with that task: –

Example:

ansible-playbook nginx.yml --list-tasks

4. –skip-tags: We can skip the tasks that is specified with –skip-tags. It will run other tasks that do not match the tag or any tasks that do not have any tags at all. Here, it runs ‘copy configuration file’ as this task does not have any tag specified in the above playbook. Other tasks have tag ‘nginx_service’

Example:

ansible-playbook nginx.yml --skip-tags nginx_service

5. -e: It allows us to set any extra variables as a key=value pair that is used by the playbook. We can also use ‘–extra-var’ or ‘extra-vars’.

Example:

ansible-playbook nginx.yml–e max_client=100

6. -i or –inventory or inventory-file: It is used to provide different inventory file instead of default while running the playbook.

Example:

ansible-playbook  -i inventory.ini nginx.yml

Conclusion

Ansible playbook permits us to reuse the code as we can save the document as a YAML record and run it at whatever point required. It puts together every one of the errands in a document for a better agreement. We can put these playbooks on any SCM(Source Code Management) device and utilize the upside of the SCM apparatus also.

Ansible
Ansible Playbooks
Python
0 VIEWS 0 LIKES 0 DISLIKES SHARE
0 LIKES 0 DISLIKES 0 VIEWS SHARE
Was this blog helpful?
techiio-price-plantechiio-price-plantechiio-price-plantechiio-price-plantechiio-price-plan
You must be Logged in to comment
Code Block
Techiio-author
Nilima Paul
Technology Security Analyst
Techiio-followerTechiio-followerTechiio-follower
201 Blog Posts
0 Discussion Threads
Trending Technologies
15
Software40
DevOps46
Frontend Development24
Backend Development20
Server Administration17
Linux Administration26
Data Center24
Sentry24
Terraform23
Ansible83
Docker70
Penetration Testing16
Kubernetes21
NGINX20
JenkinsX17
Techiio-logo

Techiio is on the journey to build an ocean of technical knowledge, scouring the emerging stars in process and proffering them to the corporate world.

Follow us on:

Subscribe to get latest updates

You can unsubscribe anytime from getting updates from us
Developed and maintained by Wikiance
Developed and maintained by Wikiance