Learn Ansible - Introduction and Explanation of Variables & Facts

#Introduction

After episode 6, where we covered handlers — the mechanism that ensures a service only restarts when its configuration changes. You now have playbooks that are idempotent and production-safe. But let's be honest: the playbooks from previous episodes are still hardcoded. Port numbers, user names, directory paths — everything is written directly inside the file. Imagine having to manage 50 servers with different configurations; rewriting a playbook for every server certainly isn't a sensible option.

In episode 7, we'll cover two foundations that will fundamentally change how you write playbooks: Variables and Facts.

Variables let us separate data (port values, server names, etc.) from logic (the instructions being executed). This is the same principle as separation of concerns in programming: you don't write magic numbers directly into the code, but in separate configuration.

Meanwhile, Facts are data that Ansible collects from every managed node automatically, from OS family, CPU architecture, total RAM, to IP addresses. Think of facts as the biodata of every server. With facts, one identical playbook can behave differently on Ubuntu and Rocky Linux without writing a separate playbook for each OS.

This material isn't just theory. Understanding variable precedence and facts will prevent subtle bugs that are very hard to trace in production, like variables that "refuse to change" even after their value has been replaced.

#Main Discussion

#What Is a Variable in Ansible?

A variable is a value holder that can be filled with any data: strings, numbers, booleans, lists, or dictionaries. In Ansible, variables are written in the typical YAML key: value format and called inside playbooks using the templating syntax {{ nama_variable }}.

The simplest analogy: a playbook is a recipe, and variables are the ingredients. The recipe stays the same, but if we swap the ingredients (say, sugar for stevia), the result changes. Same with playbooks: the task logic stays, but the values can be swapped per environment (development, staging, production).

The most commonly used variable call is the ansible.builtin.debug module to print a variable's value:

---
- name: Menampilkan nilai variable
  hosts: localhost
  gather_facts: false
  vars:
    app_name: blog
    app_port: 8080
  tasks:
    - name: Tampilkan kombinasi variable
      ansible.builtin.debug:
        msg: "Aplikasi {{ app_name }} berjalan di port {{ app_port }}"

The output looks roughly like this:

TASK [Tampilkan kombinasi variable] *******************************************
ok: [localhost] => {
    "msg": "Aplikasi blog berjalan di port 8080"
}

Notice variables are called with {{ ... }}. This is the expression syntax of Jinja2, the templating engine we'll cover in depth in episode 8. For this episode, just remember: anything inside {{ }} is evaluated and its result is inserted into the string.

#How to Create Variables

Ansible offers many ways to define variables. Let's go through them one by one from the most commonly used, starting with the broadest scope down to the most specific.

#1. Variables at the Play Level

The simplest way is to define variables directly in the play using the vars: keyword. These variables apply to every task in that play.

---
- name: Install aplikasi dengan variable play
  hosts: webservers
  become: true
  vars:
    app_user: devops
    app_port: 8080
    app_workers: 4
  tasks:
    - name: Install paket yang dibutuhkan
      ansible.builtin.apt:
        name: "{{ app_user }}"
        state: present

#2. Variables at the Inventory Level

Variables can also be defined directly in the inventory file, either per host or per group. Examples are the connection variables like ansible_host, ansible_user, and ansible_ssh_private_key_file you already know from episode 3.

---
all:
  children:
    webservers:
      hosts:
        web01:
          ansible_host: 10.10.10.11
          ansible_port: 22
        web02:
          ansible_host: 10.10.10.12
      vars:
        ansible_user: devops
        ansible_ssh_private_key_file: ~/.ssh/id_ed25519

#3. Extra Vars (Variables from the Command Line)

The most "urgent" way to fill variables is via the command line using the --extra-vars option (or its short form -e). This kind of variable always wins over all other methods, as we'll discuss in the precedence section.

ansible-playbook -i inventory.yml playbook.yml -e "app_port=9090"

ansible-playbook -i inventory.yml playbook.yml --extra-vars "app_user=root app_port=9090"

ansible-playbook -i inventory.yml playbook.yml -e @extra_vars.json

The most realistic use case for extra vars is when you want to override a specific value for just one execution without changing files — for example, doing maintenance with a different user, or deploying to a different environment with the same parameters.

#4. Variables in group_vars and host_vars

This approach is the best practice recommended for real projects. Ansible automatically reads YAML files from the group_vars/ and host_vars/ directories located near the inventory file, and applies them to hosts based on their group names or host names.

#Best Practice: Storing Variables in group_vars and host_vars

Why is this practice recommended? Because it applies the "broad defaults, specific exceptions" principle. Common variables like the NTP server, timezone, and SSH user go into group_vars/all, group-specific variables into group_vars/<nama_group>, and single-host variables into host_vars/<nama_host>.

Here's an example of a commonly used directory layout:

inventory/
├── production/
│   ├── inventory.yml
│   ├── group_vars/
│   │   ├── all.yml           # berlaku untuk semua host di production
│   │   └── webservers.yml    # berlaku khusus group webservers
│   └── host_vars/
│       └── web01.yml         # berlaku khusus host web01
└── staging/
    ├── inventory.yml
    ├── group_vars/
    │   └── all.yml
    └── host_vars/
        └── web01.yml

inventory/
├── inventory.yml
├── group_vars/
│   ├── all.yml
│   └── webservers.yml
└── host_vars/
    └── web01.yml

Now let's fill those files with real examples:

---
ntp_server: pool.ntp.org
timezone: Asia/Jakarta
ansible_user: devops
ansible_ssh_private_key_file: ~/.ssh/id_ed25519

---
nginx_port: 8080
docroot: /var/www/html
enable_https: true

---
domain: web01.example.com
server_ip: 10.10.10.11
nginx_worker_processes: 4

The benefit is strongly felt when the number of servers grows. You don't need to touch the playbook at all to adjust per-server configuration — just edit the relevant YAML file.

#Variable Precedence: Priority Order from Weakest to Strongest

Now we get to the concept that most often confuses people: variable precedence. When the same variable is defined in many places, Ansible must decide which value to use. Ansible uses a fixed hierarchy rule: values from sources with higher priority override sources with lower priority.

Ansible actually documents more than 20 precedence levels. For practical daily needs, the following table summarizes the order from weakest (easiest to override) to strongest (hardest to override):

Let's practice with a case study. For example, the app_port variable is defined in several places at once:

# group_vars/all.yml        →  app_port: 8080
# group_vars/webservers.yml →  app_port: 8081
# host_vars/web01.yml       →  app_port: 9090
# playbook.yml (vars:)      →  app_port: 9099
 
ansible-playbook -i inventory.yml playbook.yml           # hasil: 9099 (play vars menang)
ansible-playbook -i inventory.yml playbook.yml -e app_port=7070   # hasil: 7070 (-e selalu menang)

To verify which variable value Ansible actually uses, you can use the debug module with the var= syntax:

  tasks:
    - name: Periksa nilai app_port yang terpakai
      ansible.builtin.debug:
        var: app_port

#Ansible Facts: System Data Collected Automatically

Now we get to the second part of this episode: Ansible Facts. Facts are a collection of information about a managed node that Ansible gathers automatically before running tasks. This collection process is called gathering facts, and its results are stored in a special variable named ansible_facts.

Facts are collected using the ansible.builtin.setup module. This module gathers hundreds of data points: OS name, kernel version, CPU count, total RAM, IP addresses, architecture, even the hostname. You can run it manually to see the raw data:

ansible -i inventory.yml webservers -m setup

The output is very long, but here's a relevant excerpt for us:

web01 | SUCCESS => {
    "ansible_facts": {
        "ansible_distribution": "Ubuntu",
        "ansible_distribution_version": "24.04",
        "ansible_os_family": "Debian",
        "ansible_default_ipv4": {
            "address": "10.10.10.11",
            "netmask": "255.255.255.0"
        },
        "ansible_memtotal_mb": 2048,
        "ansible_processor_vcpus": 2,
        "ansible_hostname": "web01",
        "ansible_architecture": "x86_64"
    },
    "changed": false
}

To narrow down the huge output, you can use the filter parameter:

ansible -i inventory.yml webservers -m setup -a "filter=ansible_memtotal_mb"
ansible -i inventory.yml webservers -m setup -a "filter=ansible_default_ipv4"

Facts are accessed inside playbooks using the ansible_facts['nama_fact'] syntax. Here's a table of the most commonly used facts in the real world:

#Leveraging Facts in Playbooks

Now let's see the power of facts: one playbook, many operating systems. This playbook installs NGINX but chooses the package manager based on os_family, while also printing server info:

---
- name: Menggunakan ansible facts di playbook
  hosts: all
  become: true
 
  tasks:
    - name: Install NGINX di keluarga Debian
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
      when: ansible_facts['os_family'] == "Debian"
 
    - name: Install NGINX di keluarga RedHat
      ansible.builtin.dnf:
        name: nginx
        state: present
      when: ansible_facts['os_family'] == "RedHat"
 
    - name: Tampilkan profil server
      ansible.builtin.debug:
        msg: "{{ ansible_facts['hostname'] }} dengan IP {{ ansible_facts['default_ipv4']['address'] }}, RAM {{ ansible_facts['memtotal_mb'] }} MB, {{ ansible_facts['processor_vcpus'] }} CPU, OS {{ ansible_facts['distribution'] }}"

Facts can also be combined with regular variables for very dynamic configuration. A real example: generating NGINX worker processes based on the server's CPU count. We'll explore this further in episode 8 on templating.

#Optimizing Execution Time with gather_facts: false

Collecting facts isn't a free process. Every time a playbook runs, Ansible sends the setup module to every host and waits for the results, which consumes time and resources. For many servers and lightweight playbooks, this cost is quite significant.

If your playbook doesn't need facts at all, turn off fact gathering with the gather_facts: false keyword:

---
- name: Playbook ringan tanpa gathering facts
  hosts: all
  gather_facts: false
 
  tasks:
    - name: Cek konektivitas
      ansible.builtin.ping:

Notice that gather_facts: false makes the playbook run faster, and this is strongly felt when running against hundreds of hosts at once.

As an illustration, let's compare:

---
- name: Playbook biasa dengan facts
  hosts: all
  # gather_facts default = true, akan ada TASK [Gathering Facts]
  tasks:
    - name: Cek konektivitas
      ansible.builtin.ping:

---
- name: Playbook tanpa facts
  hosts: all
  gather_facts: false
  # TASK [Gathering Facts] hilang, eksekusi lebih cepat
  tasks:
    - name: Cek konektivitas
      ansible.builtin.ping:

If you turn off facts but then need them in just one task, you can manually enable them only for that task using setup:

---
- name: Gathering facts on demand
  hosts: all
  gather_facts: false
 
  tasks:
    - name: Kumpulkan facts dulu
      ansible.builtin.setup:
        filter: "ansible_os_family"
 
    - name: Baru gunakan facts
      ansible.builtin.debug:
        msg: "OS family server ini: {{ ansible_facts['os_family'] }}"

#Conclusion

In episode 7, we covered two important pillars that will make your playbooks truly production-grade: variables and facts. You now understand how to define variables at various levels, from the play, the inventory, to the group_vars/ and host_vars/ best practices. You also understand the precedence table from weakest (role defaults) to strongest (-e / extra vars), plus how to verify which variable value is used. Finally, we explored ansible facts: automatically collected system data, how to leverage them so one playbook runs across operating systems, and the gather_facts: false optimization for lightweight playbooks.

Key takeaways:

• Separate data (variables) from logic (playbook) so it's easy to manage and reuse.
• Put common variables in group_vars/all, group-specific ones in group_vars/<group>, and per-host exceptions in host_vars/<host>.
• -e always wins, host_vars wins over group_vars, and role defaults are the weakest.
• Facts make playbooks adaptive to each server's specs and OS.
• Turn off gather_facts if the playbook doesn't need it.

In episode 8, we'll cover the topic that bridges variables and real configuration: Jinja2 Templating & Filters. We'll learn to create .j2 template files that produce dynamic configuration, combine variables and facts into a complete NGINX configuration file, and leverage built-in filters like default, to_json, to_yaml, and regex_replace. Prepare your mindset, because this is where your playbooks start feeling like real programs. Keep your enthusiasm up!