Facts #

Dalam mengelola puluhan hingga ribuan server yang memiliki spesifikasi beragam, otomatisasi tidak dapat dilakukan secara buta. Kita tidak bisa menggunakan satu file konfigurasi yang sama persis untuk server yang memiliki RAM 2GB dengan server yang memiliki RAM 64GB. Kita juga tidak bisa mengeksekusi perintah manajemen paket yang sama pada server CentOS dan server Ubuntu. Agar playbook kita dapat berjalan secara cerdas dan adaptif, Ansible harus mengetahui karakteristik fisik dan logika dari managed node secara real-time.

Ansible menyelesaikan kebutuhan penemuan sistem (system discovery) ini melalui mekanisme facts. Facts adalah variabel sistem otomatis yang dikumpulkan langsung oleh Ansible dari server target di awal setiap eksekusi play. Artikel ini akan membedah secara mendalam bagaimana facts dikumpulkan, menyajikan tabel referensi facts yang paling populer digunakan, memperkenalkan pembacaan variabel lingkungan sistem (ansible_env), memandu cara mengakses facts lintas server target, membuat custom facts aplikasi kita sendiri, serta mengonfigurasi optimasi performa melalui penonaktifan dan caching facts di lingkungan skala besar.

Bagaimana Facts Dikumpulkan #

Secara default, di awal setiap eksekusi play, Ansible akan menyisipkan sebuah tugas implisit di terminal output kita yang bernama TASK [Gathering Facts]. Di balik layar, tugas ini mengeksekusi sebuah modul khusus bernama setup di server target.

Modul setup melakukan investigasi menyeluruh ke dalam sistem operasi target: membaca file di direktori /proc, memanggil perintah utilitas sistem seperti ip, df, lshw, serta mendeteksi status virtualisasi. Seluruh data temuan tersebut kemudian dikompresi menjadi struktur data JSON terstruktur dan dikirimkan kembali ke Control Node, di mana ia disimpan sebagai variabel dinamis berawalan ansible_*.

Kita dapat mencoba memanggil modul setup secara manual dari terminal CLI untuk memeriksa seluruh facts yang tersedia pada suatu host target menggunakan perintah ad-hoc:

# Mengumpulkan dan menampilkan seluruh facts dari web-01 dalam format JSON
ansible -i inventory/ hosts.ini web-01 -m setup

Karena data JSON yang dikembalikan sangat besar (bisa mencapai ribuan haris), kita bisa menyaring output menggunakan argumen filter:

# Hanya menampilkan data yang berkaitan dengan sistem operasi
ansible -i inventory/ hosts.ini web-01 -m setup -a "filter=ansible_distribution*"

# Hanya menampilkan data yang berkaitan dengan alokasi memori
ansible -i inventory/ hosts.ini web-01 -m setup -a "filter=ansible_memory*"

Tabel Facts Populer untuk Kondisional Playbook #

Facts yang dikumpulkan oleh modul setup dikelompokkan ke dalam beberapa kategori utama. Berikut adalah tabel referensi data facts yang paling sering kita gunakan sebagai parameter penentu logika otomatisasi di playbook:

1. Informasi Sistem Operasi (OS Facts) #

2. Informasi Perangkat Keras (Hardware Facts) #

3. Informasi Jaringan (Network Facts) #

4. Informasi Tanggal & Waktu (Time Facts) #

Berikut adalah contoh praktis penulisan task yang memanfaatkan tabel facts di atas untuk menyesuaikan file template konfigurasi aplikasi:

# Menyesuaikan jumlah worker threads server web Apache secara otomatis
- name: Menerapkan konfigurasi Apache HTTPD
  template:
    src: httpd.conf.j2
    dest: /etc/httpd/conf/httpd.conf
  vars:
    # Mengalokasikan 2 thread per CPU logis, dengan batas minimum 2 threads
    max_workers: "{{ [2, (ansible_processor_vcpus | int * 2)] | max }}"

Membaca Variabel Lingkungan Sistem dengan ansible_env #

Selain informasi hardware dan OS, Ansible juga menangkap seluruh variabel lingkungan (environment variables) yang aktif untuk user SSH yang digunakan untuk mengeksekusi perintah di managed node. Variabel-variabel ini disimpan di dalam dictionary ansible_env.

Kita dapat memanfaatkan ansible_env untuk mendeteksi variabel sistem penting seperti jalur direktori home, konfigurasi proxy HTTP, atau path executable sistem.

# Membaca variabel lingkungan sistem target
- name: Membuat direktori unduhan di home user target
  file:
    path: "{{ ansible_env.HOME }}/downloads"
    state: directory
    mode: '0755'

- name: Menggunakan binary dari custom PATH target jika ada
  command: my-custom-tool --version
  environment:
    PATH: "{{ ansible_env.PATH }}:/opt/custom/bin"

Mengakses Facts Host Lain (hostvars) #

Secara default, variabel facts hanya tersedia di dalam thread eksekusi host yang bersangkutan. Namun, dalam orkestrasi kluster produksi, kita sering kali membutuhkan informasi dari server lain.

Sebagai contoh, ketika kita mengonfigurasi server web proxy depan (Nginx), kita perlu mengetahui IP address default dari beberapa server backend aplikasi (PHP-FPM atau NodeJS) untuk dimasukkan ke dalam blok upstream Nginx.

Ansible memecahkan kebutuhan ini melalui variabel global hostvars. Dengan hostvars, kita dapat menembus batasan isolasi host dan membaca facts dari server mana pun yang terdaftar dalam inventaris kita, selama server target tersebut berada dalam run play yang sama atau datanya telah disimpan dalam cache.

# BERKAS: playbook.yml
- name: Konfigurasi Load Balancer Proxy
  hosts: loadbalancers
  tasks:
    - name: Mengonfigurasi Nginx Upstream proxy
      template:
        src: upstream.conf.j2
        dest: /etc/nginx/conf.d/upstream.conf
      notify: Restart Nginx

# BERKAS: templates/upstream.conf.j2
# Upstream configuration menggunakan IP address dinamis server backend
upstream backend_app {
  {% for host in groups['webservers'] %}
  # ✓ Mengambil IP default milik masing-masing server di grup webservers
  server {{ hostvars[host]['ansible_default_ipv4']['address'] }}:8080;
  {% endfor %}
}

[!WARNING] Penggunaan hostvars mensyaratkan server target yang datanya ingin kita ambil harus sudah mengeksekusi tahap Gathering Facts terlebih dahulu pada play yang sama atau play sebelumnya. Jika host tersebut dilewati (skipped) atau dikecualikan dari target play, Ansible akan mengembalikan error Undefined Variable. Untuk mengatasinya, kita bisa mengaktifkan fitur Fact Caching.

Implementasi Custom Facts #

Selain facts bawaan sistem yang dikumpulkan oleh modul setup, kita juga bisa mendefinisikan fakta kustom (custom facts) kita sendiri pada managed node. Custom facts sangat berguna untuk menyimpan status spesifik aplikasi yang dikelola oleh tim developer (misalnya versi rilis microservice, status replikasi database, atau pemilik penanggung jawab server).

Custom facts harus disimpan di server target di dalam direktori /etc/ansible/facts.d/ dalam bentuk file yang memiliki ekstensi .fact. File ini dapat berupa:

• Berkas statis berformat INI
• Berkas statis berformat JSON
• Berkas skrip yang dapat dieksekusi (executable script seperti Bash atau Python) yang menghasilkan output JSON standar ke stdout.

1. Contoh Custom Fact Statis (JSON) #

Kita dapat mendeploy berkas konfigurasi metadata statis menggunakan Ansible:

// /etc/ansible/facts.d/app_info.fact
{
  "metadata": {
    "aplikasi": "payment-api",
    "versi": "1.4.2",
    "owner": "tim-fintech"
  }
}

2. Contoh Custom Fact Dinamis (Executable Script) #

Jika kita ingin agar fakta tersebut bersifat dinamis (misalnya memeriksa sisa space backup secara dinamis), kita bisa meletakkan sebuah shell script yang mengembalikan output JSON:

#!/bin/bash
# /etc/ansible/facts.d/system_health.fact
# Script executable wajib mengembalikan format JSON valid ke stdout
FREE_SPACE=$(df -h / | awk 'NR==2 {print $4}')
echo "{\"disk_root_free\": \"$FREE_SPACE\"}"

Skenario Playbook Deployment Custom Facts: #

Berikut adalah playbook untuk memasang direktori, menyalin custom facts, dan memicu reload facts sistem:

# 1. Menyiapkan direktori penyimpanan custom facts di managed node
- name: Memastikan direktori facts.d tersedia
  file:
    path: /etc/ansible/facts.d
    state: directory
    owner: root
    group: root
    mode: '0755'

# 2. Menyalin berkas data fakta kustom ke server target
- name: Deploy custom fact statis
  copy:
    src: files/app_info.fact
    dest: /etc/ansible/facts.d/app_info.fact
    owner: root
    group: root
    mode: '0644'
  notify: Perbarui Facts Sistem

# 3. Pemicuan update agar Ansible membaca variabel baru saat itu juga
handlers:
  - name: Perbarui Facts Sistem
    setup:
      filter: ansible_local
    # ✓ Modul setup dijalankan kembali secara khusus untuk memuat variabel ansible_local

Setelah file .fact tersebut terpasang, Ansible akan membacanya secara otomatis di bawah namespace ansible_local. Kita dapat mengakses nilainya di dalam task playbook seperti ini:

- name: Tampilkan metadata aplikasi dari custom facts
  debug:
    msg: "Aplikasi {{ ansible_local.app_info.metadata.aplikasi }} versi {{ ansible_local.app_info.metadata.versi }}"

Optimasi Performa: Menonaktifkan Gathering Facts #

Meskipun facts sangat berguna, proses pengumpulan facts memakan waktu yang cukup lama. Untuk setiap host target, Ansible harus melakukan koneksi SSH, mentransfer modul setup, mengeksekusinya, dan menunggu payload JSON dikirimkan kembali. Proses ini rata-rata memerlukan waktu 1 hingga 3 detik per server.

Jika kita memiliki playbook yang hanya bertugas melakukan tugas-tugas sederhana (seperti mendistribusikan file statis atau memicu restart service) tanpa membutuhkan evaluasi kondisi OS atau memori, kita sangat disarankan untuk menonaktifkan proses gathering facts demi menghemat waktu eksekusi.

Kita dapat menonaktifkan pengumpulan fakta ini dengan menambahkan parameter gather_facts: false di tingkat play:

# Playbook dengan optimasi kecepatan tinggi tanpa pengumpulan facts
- name: Deployment Cepat Aset Gambar Statis
  hosts: static_servers
  gather_facts: false  # ✓ Menonaktifkan Gathering Facts (Menghemat waktu SSH awal)
  tasks:
    - name: Menyalin file banner promosi
      copy:
        src: files/promo.png
        dest: /var/www/html/assets/promo.png

Di lingkungan produksi berskala besar dengan ratusan hingga ribuan server, menuliskan gather_facts: false dapat memangkas total waktu tunggu eksekusi playbook hingga beberapa menit.

Konfigurasi Fact Caching di ansible.cfg #

Jika kita tetap membutuhkan data facts untuk orkestrasi yang rumit tetapi ingin playbook kita berjalan secepat kilat tanpa overhead koneksi SSH berulang kali, solusi terbaik adalah mengaktifkan Fact Caching.

Dengan Fact Caching, Ansible akan menyimpan data facts yang telah dikumpulkan pada eksekusi pertama ke dalam media penyimpanan eksternal. Di eksekusi berikutnya, Ansible akan membaca facts langsung dari cache tersebut tanpa melakukan kueri ke server target.

Pilihan Backend Caching #

1. jsonfile: Menyimpan berkas-berkas JSON statis pada folder lokal di Control Node. Mudah dikonfigurasi, tidak butuh server dependensi tambahan, sangat cocok untuk tim kecil.
2. redis: Menyimpan data facts di memori server Redis terpusat. Sangat direkomendasikan untuk tim berskala enterprise karena performa baca-tulis memori yang luar biasa cepat dan konsistensi data yang tinggi lintas runner.
3. memcached: Backend alternatif berbasis memori terdistribusi untuk manajemen session caching.

Berikut adalah diagram alir visualisasi pengambilan keputusan pembacaan facts menggunakan caching sistem:

flowchart TD
    Start(["Mulai Playbook Run"]) --> CheckSmart{"Aturan: gathering = smart?"}
    
    CheckSmart -- "Ya" --> CheckCache{"Apakah Cache Host X Tersedia & Valid?"}
    CheckSmart -- "Tidak (gathering = implicit)" --> RunSetup["Jalankan Modul setup via SSH (Lambat)"]
    
    CheckCache -- "Ya (Belum Expired)" --> LoadCache["Muat Facts dari Cache (Sangat Cepat)"]
    CheckCache -- "Tidak (Expired / Kosong)" --> RunSetup
    
    RunSetup --> SaveCache["Simpan Payload Facts Baru ke Cache Backend"]
    SaveCache --> RunTasks["Lanjutkan Eksekusi Tasks Playbook"]
    LoadCache --> RunTasks
    RunTasks --> End(["Selesai Playbook Run"])

Untuk mengaktifkan caching berbasis file JSON lokal, kita cukup menambahkan konfigurasi berikut ke dalam file ansible.cfg proyek kita:

# BERKAS: ansible.cfg
[defaults]
# Mengatur pengambilan fakta secara pintar (hanya jika cache kedaluwarsa)
gathering = smart

# Menggunakan backend penyimpanan berbasis berkas JSON lokal
fact_caching = jsonfile

# Menentukan jalur folder penyimpanan cache di Control Node
fact_caching_connection = .ansible_facts_cache

# Menentukan masa berlaku cache (86400 detik = 24 jam)
fact_caching_timeout = 86400

Jika kita ingin bermigrasi ke database Redis terpusat untuk tim besar:

# BERKAS: ansible.cfg (Versi Redis Enterprise)
[defaults]
gathering = smart
fact_caching = redis
# Format koneksi: host:port:db_index:password (opsional)
fact_caching_connection = redis-server.internal.net:6379:0
fact_caching_timeout = 86400

Ringkasan #

• System Discovery: Facts adalah variabel temuan sistem otomatis yang dikumpulkan oleh modul setup di awal setiap play di bawah namespace ansible_*.
• Modul Setup Manual: Kita dapat menyelidiki facts yang tersedia pada server target dari command line menggunakan perintah ad-hoc ansible <host> -m setup.
• Variabel Lintas Host: Gunakan sintaksis hostvars['nama_host']['fact_name'] untuk mengakses data facts milik server lain demi kebutuhan integrasi upstream/kluster.
• Variabel Lingkungan: Dictionary ansible_env menyediakan akses langsung ke seluruh variabel lingkungan (seperti HOME, PATH) milik user SSH di managed node.
• Custom Facts: Kita dapat mendeploy file berekstensi .fact ke direktori /etc/ansible/facts.d/ untuk mendefinisikan metadata kustom di bawah namespace ansible_local.
• Optimasi Performa: Gunakan parameter gather_facts: false pada playbook yang tidak membutuhkan evaluasi sistem untuk menghemat waktu handshake SSH.
• Fact Caching: Aktifkan fitur caching (jsonfile atau redis) di dalam ansible.cfg untuk menghindari pemanggilan modul setup berulang-ulang pada server target yang sama.

← Sebelumnya: Scope & Precedence   Berikutnya: Debugging →