Ansible Fundamentals Beyond the First Playbook

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

• 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