Inventory

Inventory #

Sebelum Ansible dapat melakukan tindakan otomatisasi apa pun pada infrastruktur kita, ia perlu mengetahui ke mana harus terhubung dan server mana yang menjadi target eksekusi. Sumber informasi ini didefinisikan di dalam inventory (inventori). Inventori bukan sekadar daftar alamat IP atau nama server (hostname), melainkan sebuah peta logis terstruktur yang menentukan bagaimana server dikelompokkan, variabel konfigurasi apa saja yang melekat pada masing-masing entitas, serta bagaimana alur hubungan hierarkis antar-server dibangun. Pemahaman yang matang mengenai inventori membantu kita menghindari utang teknis manajemen konfigurasi sejak awal.

Definisikan Kamus Server Target #

Secara esensial, inventori bertindak sebagai kamus database server target untuk Ansible. Ketika kita menjalankan perintah eksekusi playbook, kita menentukan parameter sasaran (seperti hosts: webservers). Ansible kemudian akan mencocokkan kata kunci tersebut dengan file inventori untuk mendapatkan alamat koneksi SSH dan kredensial yang tepat dari Managed Node terkait.

Tanpa inventori yang terstruktur, otomatisasi kita akan kehilangan arah dan tidak dapat berjalan secara modular. Inventori memungkinkan kita memisahkan definisi infrastruktur fisik dari logika tugas playbook, sehingga kode otomatisasi kita dapat digunakan kembali (reusable) secara lintas lingkungan (misalnya dari dev, staging, hingga produksi).


Perbandingan Format INI dan YAML #

Ansible secara asli mendukung dua format penulisan file inventori statis: INI dan YAML. Kedua format ini memiliki kegunaan yang berbeda tergantung pada kompleksitas infrastruktur yang kita kelola.

Format INI memiliki struktur yang sangat ringkas, mudah dibaca secara cepat, dan banyak digunakan untuk proyek berskala kecil hingga menengah. Format YAML lebih ekspresif, terstruktur dengan indentasi ketat, serta sangat cocok digunakan untuk infrastruktur berskala besar yang membutuhkan penulisan variabel bersarang (nested variables).

Mari kita bandingkan penulisan inventori siap produksi menggunakan kedua format tersebut:

1. Contoh File Inventori Statis (Format INI) #

# /etc/ansible/hosts atau production.ini
[webservers]
web-prod-01 ansible_host=192.168.10.11 ansible_user=ubuntu
web-prod-02 ansible_host=192.168.10.12 ansible_user=ubuntu

[dbservers]
db-prod-01 ansible_host=192.168.10.20 ansible_user=admin db_port=5432
db-prod-02 ansible_host=192.168.10.21 ansible_user=admin db_port=5432

[production:children]
webservers
dbservers

[production:vars]
env=production
ansible_connection=ssh

2. Contoh File Inventori Statis (Format YAML) #

# production.yaml
all:
  children:
    webservers:
      hosts:
        web-prod-01:
          ansible_host: 192.168.10.11
          ansible_user: ubuntu
        web-prod-02:
          ansible_host: 192.168.10.12
          ansible_user: ubuntu
    dbservers:
      hosts:
        db-prod-01:
          ansible_host: 192.168.10.20
          ansible_user: admin
          db_port: 5432
        db-prod-02:
          ansible_host: 192.168.10.21
          ansible_user: admin
          db_port: 5432
      vars:
        db_version: 15.2
  vars:
    env: production
    ansible_connection: ssh

Struktur Pengelompokan Hierarkis (:children) #

Kekuatan utama inventori Ansible terletak pada kemampuannya untuk mengelompokkan server secara fleksibel. Pengelompokan (grouping) membantu kita mengklasifikasikan server berdasarkan fungsi fungsionalnya (seperti [webservers], [dbservers]) atau berdasarkan lokasi geografisnya (seperti [jakarta], [singapore]).

Kita dapat menyusun hierarki kelompok menggunakan parameter children. Hal ini memungkinkan grup induk (parent group) untuk mewarisi seluruh anggota dan variabel dari grup anak (child group).

[web-jakarta]
web-jkt-01.example.com
web-jkt-02.example.com

[web-singapore]
web-sgp-01.example.com

# Grup induk menggabungkan kedua wilayah
[webservers:children]
web-jakarta
web-singapore

Dengan struktur di atas, jika kita menjalankan perintah dengan target hosts: webservers, Ansible akan mengeksekusi tugas secara paralel ke ketiga server di Jakarta dan Singapore. Namun, jika kita ingin melakukan pemeliharaan khusus wilayah Jakarta, kita cukup membatasi target dengan memanggil hosts: web-jakarta.

Kita juga dapat menggunakan operator irisan logis di baris perintah untuk memfilter target secara dinamis:

# Mengeksekusi playbook hanya ke server yang masuk ke grup webservers DAN berada di wilayah jakarta
ansible-playbook -i inventory.ini site.yml --limit "webservers:&web-jakarta"

Pengelolaan Variabel di Inventory: Praktek Terbaik #

Inventori memungkinkan kita untuk mendefinisikan variabel khusus yang melekat pada host tertentu (Host Variables) atau pada grup tertentu (Group Variables). Variabel ini sering digunakan untuk menyimpan port kustom, path direktori aplikasi, atau parameter konfigurasi OS.

Anti-Pattern: Menulis Variabel Langsung di File Inventory #

Sangat mudah bagi kita untuk menulis variabel langsung di samping nama host seperti contoh format INI di atas (db-prod-01 ansible_host=... db_port=5432). Namun, seiring bertambahnya jumlah variabel (misalnya kredensial, API key, flag fitur), file inventori kita akan menjadi sangat panjang, sulit dibaca, dan rentan terhadap kesalahan format.

Solusi Praktis: Menggunakan Direktori group_vars dan host_vars #

Rekomendasi praktik terbaik (best practice) dari Ansible adalah memisahkan penulisan variabel dari file inventori fisik ke dalam folder terstruktur bernama group_vars/ dan host_vars/. Folder-folder ini diletakkan di direktori yang sama dengan file inventori atau file playbook kita.

Berikut adalah tata letak struktur direktori proyek Ansible yang direkomendasikan:

proyek-ansible/
  ├── production-inventory.ini
  ├── site.yml
  ├── group_vars/
  │     ├── all.yml           # Variabel yang berlaku untuk semua host
  │     ├── webservers.yml    # Variabel khusus untuk grup webservers
  │     └── dbservers.yml     # Variabel khusus untuk grup dbservers
  └── host_vars/
        ├── web-prod-01.yml   # Variabel khusus untuk host web-prod-01 saja
        └── db-prod-01.yml    # Variabel khusus untuk host db-prod-01 saja

Di dalam file yml tersebut, kita menulis variabel menggunakan format YAML standar yang bersih:

# group_vars/webservers.yml
---
http_port: 80
nginx_max_clients: 1024
nginx_worker_processes: auto

Ansible secara otomatis akan membaca direktori folder ini berdasarkan pencocokan nama grup atau nama host yang terdaftar di file inventori kita.


Cara Kerja Dynamic Inventory #

Di era cloud computing modern di mana infrastruktur bersifat elastis, penggunaan inventori statis memiliki keterbatasan besar. Server virtual (VM) dapat dibuat dan dihancurkan secara otomatis oleh sistem autoscaling berdasarkan beban traffic data. Memperbarui file inventori secara manual setiap kali terjadi perubahan IP address adalah pekerjaan yang mustahil.

Untuk memecahkan masalah ini, Ansible menyediakan fitur Dynamic Inventory (Inventori Dinamis). Alih-alih membaca file teks statis, Ansible menggunakan plugin inventori khusus yang menghubungi API cloud provider secara real-time untuk menyusun daftar server target beserta variabelnya secara otomatis.

Berikut diagram alur kerja inventori dinamis:

flowchart TD
    Run["1. Kita menjalankan perintah ansible-playbook"] --> Plugin["2. Plugin Inventory diaktifkan (misal: aws_ec2)"]
    Plugin --> API["3. Melakukan request API terenkripsi ke Cloud Provider"]
    API --> Respond["4. Cloud Provider mengembalikan metadata seluruh VM yang aktif"]
    Respond --> Parse["5. Plugin menyusun JSON inventori dan memetakan grup berdasarkan Tag Cloud"]
    Parse --> Exec["6. Ansible mengeksekusi playbook ke server-server dinamis tersebut"]

Contoh Konfigurasi Plugin Inventory AWS EC2: #

Kita menggunakan file konfigurasi berakhiran aws_ec2.yml untuk memicu pemanggilan inventori dinamis AWS:

# demo_aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - ap-southeast-3 # Region Jakarta
filters:
  # Hanya mengambil VM yang memiliki status 'running'
  instance-state-name: [ running ]
keyed_groups:
  # Membuat grup otomatis berdasarkan Tag 'Role' yang ada di EC2 console
  - key: tags.Role
    prefix: role
  # Membuat grup berdasarkan Availability Zone
  - key: placement.availability_zone
    prefix: zone

Ketika kita menjalankan playbook, Ansible akan secara otomatis membuat grup seperti role_web atau zone_ap_southeast_3a berdasarkan metadata nyata yang ditarik dari AWS console.


Grup Otomatis Bawaan: all dan ungrouped #

Setiap kali kita memicu perintah Ansible, sistem secara implisit akan selalu membuat dua grup bawaan utama yang tidak perlu kita deklarasikan secara fisik di file inventori:

  1. all: Grup penampung global yang berisi seluruh server yang terdaftar di dalam inventori kita. Kita dapat menggunakan kata kunci hosts: all di dalam playbook jika ingin menerapkan konfigurasi dasar (seperti penyelarasan zona waktu atau instalasi utility) ke seluruh server tanpa kecuali.
  2. ungrouped: Grup khusus yang menampung server-server yang kita daftarkan di inventori tanpa dimasukkan ke dalam klasifikasi grup manapun.

Perintah Pengelolaan dan Verifikasi Inventory #

Untuk memastikan struktur inventori statis atau dinamis kita bebas dari kesalahan parser sebelum menjalankan skenario playbook yang sesungguhnya, kita dapat memanfaatkan beberapa perintah CLI verifikasi Ansible berikut:

1. Menampilkan Grafik Hubungan Grup #

Perintah --graph sangat berguna untuk memvisualisasikan hierarki grup anak dan grup induk secara terstruktur di terminal:

ansible-inventory -i production-inventory.ini --graph

Output grafik yang dihasilkan akan tampak seperti ini:

@all:
  |--@production:
  |  |--@webservers:
  |  |  |--web-prod-01
  |  |  |--web-prod-02
  |  |--@dbservers:
  |  |  |--db-prod-01
  |  |  |--db-prod-02
  |--@ungrouped:

2. Mengekspor Daftar Server ke Format JSON #

Perintah --list digunakan untuk melihat seluruh daftar server beserta variabel host/group terkait dalam format JSON lengkap:

ansible-inventory -i production-inventory.ini --list

Ringkasan #

  • Inventori bertindak sebagai peta target — Berisi daftar Managed Node, pengelompokan logis, serta variabel spesifik yang menjadi sasaran otomatisasi Ansible.
  • Format INI vs YAML — Format INI ringkas dan mudah dipahami untuk skala kecil, sementara format YAML ideal untuk struktur bersarang (nested group) skala besar.
  • Hierarki Grup (:children) — Memudahkan pewarisan variabel dan penggabungan beberapa grup anak ke dalam satu grup induk terpadu.
  • Pemisahan Variabel (Best Practice) — Hindari menulis variabel langsung di file inventori; pisahkan ke dalam folder group_vars/ dan host_vars/.
  • Dynamic Inventory — Solusi otomatisasi mutlak untuk infrastruktur cloud dinamis dengan memanggil API provider secara real-time melalui plugin inventori.

← Sebelumnya: Node   Berikutnya: Module →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact