Ansible operates by connecting to what you wish to automate and pushing programmes that perform manual instructions. These applications make use of Ansible modules that are developed depending on the endpoint’s connection, interface, and instructions.
Ansible then runs these modules (through regular SSH by default) and removes them after they’re done (if applicable).
Ansible is the most straightforward method for automating everyday IT activities. It’s intended to be simple, consistent, safe, and dependable, with an incredibly short learning curve for administrators, developers, and IT managers.
Ansible playbooks are an essential feature of Ansible and the foundation of every Ansible setup.
Table of Contents:
Check out this video for more information about Ansible Playbook
What is an Ansible Playbook?
An Ansible playbook is a file in which users create Ansible code, which is a structured collection of scripts that define the work of a server setup. They define a series of stages in a general IT process or a policy that your remote systems must follow.
Playbooks are collections of one or more plays that are performed in a certain order. A play is an ordered sequence of tasks performed against hosts from your inventory. The task to be done is defined by plays. Each play has a list of hosts to configure and responsibilities to complete. There are no standardized plays; each play must be written by an administrator.
YAML, a human-readable data processing language, is used in playbooks. “YAML ” is a sequence acronym that stands for “YAML Ain’t Markup Language.”
How do Ansible Playbooks Work?
Ansible modules carry out tasks. A play may be created by combining one or more Ansible jobs. An Ansible Playbook is made up of two or more plays. Ansible Playbooks are collections of tasks that run automatically against hosts. Your Ansible inventory is made up of groups of hosts.
Each module in an Ansible Playbook is responsible for a certain task. Each module has metadata that indicates when and where a job is performed, as well as which user does it. There are lots of Ansible modules that execute various IT tasks, including:
- Cloud management: oci_vcn creates, deletes, or updates virtual cloud networks in Oracle Cloud Infrastructure environments.
- User management: selogin maps Linux operating system (OS) users to SELinux user and gitlab_user creates, updates, or deletes GitLab users.
- Networking: Dozens of modules handle application programming interfaces (APIs); Cisco IOS, NXOS, and IOS XR devices; as well as F5 BIG-IP services.
- Configuration management: pip manages Python library dependencies while assemble consolidates configuration files from fragments.
- Security: Openssh_cert generates an OpenSSH host or user certificates, and ipa_config manages global FreeIPA configuration settings.
How to Build an Ansible Playbook?
Ansible playbooks have the ability to get pretty massive and sophisticated. But, whether you’re writing a short and sweet playbook or a massive epic, here’s how you do it.
Every playbook is divided into the following standard sections:
- Host: The host section specifies the computers on which the playbook will be executed. This data is derived from the Ansible inventory file. As a result, the host section is a list of devices.
- variable: The variable section is optional and provides any variables required by the script. If at all, it can be as huge or as little as needed.
- Tasks: The task section describes the usage of Modules and identifies the tasks that the target machine must do. Every job is given a name, as well as a brief description of what it accomplishes, and is listed when the playbook is executed.
How to use Ansible Playbooks?
Ansible makes use of the YAML syntax. YAML stands for yet another markup language or YAML ain’t markup language, depending on who you ask (a recursive acronym). YAML file extensions are also varied, but totally acceptable:.yaml or.yml.
Ansible Playbooks can be used in two ways: through the command line interface (CLI) or through the Red Hat Ansible Automation Platform’s push-button deployments.
- From the CLI: To launch Ansible Playbooks, just use the ansible-playbook command after installing the open source Ansible project or the Red Hat Ansible Automation Platform.
- From within the platform:The web-based user interface of the Red Hat Ansible Automation Platform offers push-button Ansible Playbook deployments that are utilised as part of bigger tasks (or job templates). These deployments provide extra precautions that are especially beneficial to users who are new to IT automation or who may not have as much expertise working with the CLI.
What are the Variables Of Ansible Playbooks?
Ansible utilizes variables to assist users in dealing with system variances, as no two systems are exactly the same. Variable names are made up of letters, digits, and underscores, but they must always start with a letter. Variables also never include blank spaces.
Variables may be defined directly in playbooks by using the “vars:” command. Variables can be anything from proper nouns to ports to web servers, or even a specific command.
For example, you may create a playbook in which you greet individuals with “How’s it going, eh?” by defining a variable called “greeting” with the value “How’s it doing, eh?” When the user runs the playbook, the message is shown on the terminals.
Variables are used to store values, and you may build practically any type of variable you require. There are variables for groups and hosts, inventory files, array variables, dictionary variables, and special variables.
Special variables are built-in variables that cannot be changed by the user and are always overridden by Ansible. You may alternatively maintain variables in a separate file and import them as needed with the vars files command.
It is important to note that your playbook does not have to include variables if they are not required. They are completely optional.
Get 100% Hike!
Master Most in Demand Skills Now!
Example of Ansible Playbooks:
Ansible can communicate with a wide range of device types, including cloud-based REST APIs, Linux and Windows systems, networking devices, and much more. This is an example of two Ansible modules that automatically update two different types of servers:
- name: Ansible
hosts: servers
become: yes
become_user: root
tasks:
- name: ensure an apache is at the latest version
yum:
name: httppd
state: updated version
- name: ensure apache is running
service:
name: httpd
state: started
This short ansible-playbook example should be enough to have your Apache installation completed and ready. I sense your frustration since I just provided a text with no explanation of what they do.
I’ve already described what each line does.
name The playbook’s name
hosts A collection of hosts that are often grouped together as a host group and defined in an inventory file.
To tell Ansible, this piece must be performed with higher privileges.
become_user is the user name we wish to switch to, similar to sudo su – user.
tasks a collection of activities to be completed, all tasks would be stated below this
Then we have two jobs with two modules, the first of which is yum and the second of which is service.
The latest variable in the first yum job signifies that the above mentioned package httpd should be installed if it is not already installed (or) updated to the latest version available if it is already installed. If you do not want it to be updated if it is present, modify the state:start.
Conclusion
Ansible believes that you should not require another framework to validate the fundamentals of your system. This is because Ansible is an order-based system that will fail instantly if a host encounters an unhandled error, preventing further setup of that host. This pushes mistakes to the top of the list and displays them in a summary at the conclusion of the Ansible run.
However, considering Ansible is a multi-tier orchestration system, it is quite simple to integrate tests at the conclusion of a playbook run, either via loose tasks or roles. When combined with rolling updates, testing processes can determine whether or not a machine should be returned to a load balanced pool.