This blog continues from my previous Ansible basics blog. If you haven't gone through it yet, I recommed reading it first, where I explained Ansible fundamentals inventory, playbooks, and how to write your first playbook.
Ansible Fundamentals
Variables - The basic inputs of Ansible
Variables are values that can change and are used to make playbooks flexible and reusable.
Instead of hard coding information inside a playbook, we store it in variables. Variables are important because one playbook works for multiple servers and changes are easy and safe
Think of it like: When you build a house, you first decide:
- How many rooms?
- What color paint?
- What type of flooring?
These details can change from one house to another.
Similarly, in asnible:
Server name can change
Port number can change
Software version can change
These changing values are stored in variables.
How to Define Variables in Ansible
1) Inside a Playbook
---
- name: Example of Ansible Variables
hosts: all
vars:
app_name: "MyApp"
app_port: 8080
tasks:
- name: Print application details
debug:
msg: "Deploying {{ app_name }} on port {{ app_port }}"
Here, vars: defines variables directly in the playbook. You can reference them using {{ variable_name }}.
2) In Inventory File
[webservers]
server1 ansible_host=192.168.1.10 app_port=8080
server2 ansible_host=192.168.1.11 app_port=9090
3) Using vars_files
You can keep variables in a separate file for better organization
# vars.yml
app_name: "MyApp"
app_port: 8080
4) Passing Extra Variables at Runtime
ansible-playbook site.yml --extra-vars "app_name=MyApp app_port=9090"
Ansible Facts
Ansible facts are pieces of information about the target system that Ansible automatically gathers when running a playbook. These include details like:
IP Addresses
Operating system type and version
Hostname
CPU, memory, and disk information
Facts are collected by the setup module and stored in a dictionary called ansible_facts.
How to Gather Facts
By default, Ansible gathers facts at the start of a playbook run. This is controlled by the gather_facts parameter in the playbook:
- name: Example Playbook
hosts: all
gather_facts: yes
tasks:
- name: Print OS family
debug:
msg: "OS Family is {{ ansible_facts['os_family'] }}"
If you set gather_facts: no, Ansible will skip collecting facts, which can speed up execution when facts are not needed.
Ansible roles
Roles in Ansible are a way to organize playbooks into reusable components. Instead of writing large, monolithic playbooks, roles allow you to break them down into smaller, modular pieces.
Benefits of using roles:
Reusability: Use the same code across multiple projects.
Maintainability: Easier to update and manage.
Scalability: Ideal for large environment.
Standardization: Encourages best practices and consistent structure.
Structure of a role
roles/
└── myrole/
├── tasks/ # Main list of tasks to execute
├── handlers/ # Handlers triggered by tasks
├── templates/ # Jinja2 templates for configuration files
├── files/ # Static files to copy
├── vars/ # Variables with higher precedence
├── defaults/ # Default variables (lowest precedence)
└── meta/ # Role metadata (dependencies, author info)
Ansible Galaxy
Ansible Galaxy is a community hub and repository for Ansible content like roles, collections, and plugins. It’s essentially a marketplace where you can download pre-built automation content or share your own. This saves time because you don’t have to write everything from scratch.
1) Install a Role from Galaxy
ansible-galaxy role install geerlingguy.nginx
2) Use Installed Roles in Playbooks
---
- hosts: webservers
roles:
- geerlingguy.nginx
3) Create your own role
ansible-galaxy init roles/webserver
This creates the folder we need:
roles/
└── webserver/
├── defaults/
│ └── main.yml
├── files/
├── handlers/
│ └── main.yml
├── meta/
│ └── main.yml
├── tasks/
│ └── main.yml
├── templates/
├── vars/
│ └── main.yml
└── README.md
Converting a Simple Playbook into a Role
Original Playbook:
- hosts: webservers
tasks:
- name: Install Apache
yum:
name: httpd
state: present
- name: Start Apache
service:
name: httpd
state: started
Converted into Role:
# roles/webserver/tasks/main.yml
- name: Install Apache
yum:
name: httpd
state: present
- name: Start Apache
service:
name: httpd
state: started
Playbook using role:
- hosts: webservers
roles:
- apache