Belajar Ansible - Mengelola Inventory (Static & Dynamic Inventory)

#Pendahuluan

Setelah di episode 2 sebelumnya kita membahas arsitektur utama Ansible — mulai dari peran control node sebagai "otak" yang menjalankan semua perintah, managed nodes sebagai server-server yang dikelola, sampai alur kerja eksekusi modul Python lewat SSH — pada episode kali ini kita akan membedah salah satu komponen yang paling sering kita pegang sehari-hari: Inventory.

Kalau diibaratkan, inventory adalah buku alamat milik Ansible. Playbook dan perintah ad-hoc hanyalah "surat" yang berisi instruksi; tanpa buku alamat yang benar, surat tersebut tidak akan pernah sampai ke tujuan. Di dunia nyata, sistem yang dikelola tidak pernah hanya satu server. Bisa puluhan bahkan ribuan VM, tersebar di beberapa environment (staging, production), dengan role yang berbeda-beda (web server, database, worker). Inventory adalah peta yang memetakan semuanya, dan di episode ini kalian akan belajar membuat peta tersebut dengan benar.

Kita juga akan melihat mengapa di era cloud yang serba auto-scaling, file inventory statis saja tidak cukup — dan bagaimana dynamic inventory hadir untuk menyelesaikan masalah tersebut.

#Pembahasan Utama

#Apa Itu Inventory dan Kenapa Bentuknya Menentukan Kualitas Automasi?

Inventory adalah file atau sumber data yang mendaftarkan semua managed nodes yang bisa dikelola Ansible. Setiap entri biasanya berisi nama host (atau IP) dan informasi koneksi seperti user SSH, port, dan kunci privat.

#Format Inventory: INI vs YAML

Ansible mendukung dua format penulisan inventory statis: INI (format warisan dari zaman awal Ansible) dan YAML (format modern yang direkomendasikan). Keduanya valid dan menghasilkan perilaku yang sama. Perbedaannya terletak pada ekspresivitas dan keterbacaan saat struktur data semakin kompleks.

[webservers]
web-01.prod.example.com
web-02.prod.example.com
web-01.staging.example.com
 
[dbservers]
db-01.prod.example.com
db-01.staging.example.com
 
[prod:children]
webservers
dbservers
 
[staging:children]
webservers
dbservers
 
[prod:vars]
ansible_user=deploy

all:
  children:
    webservers:
      hosts:
        web-01.prod.example.com:
        web-02.prod.example.com:
        web-01.staging.example.com:
    dbservers:
      hosts:
        db-01.prod.example.com:
        db-01.staging.example.com:
    prod:
      children:
        webservers:
        dbservers:
      vars:
        ansible_user: deploy
    staging:
      children:
        webservers:
        dbservers:

Dari contoh di atas, kalian bisa melihat keduanya mendefinisikan hal yang sama. Namun ada beberapa alasan mengapa YAML menjadi rekomendasi modern:

1. Struktur hierarkis yang lebih jelas — hubungan parent/child antar grup terlihat lebih eksplisit.
2. Fleksibel — YAML memungkinkan struktur bersarang yang lebih dalam, termasuk menggabungkan hosts, children, dan vars dalam satu blok yang rapi.
3. Konsisten dengan playbook — karena playbook juga ditulis dalam YAML, tim kalian tidak perlu menguasai dua sintaks sekaligus.

#Mengelompokkan Host: Host Groups & Grouping Hierarchy

Sistem riil hampir tidak pernah "flat". Kalian punya web server, database server, cache, dan worker — masing-masing dengan kebutuhan perlakuan berbeda. Ansible menyelesaikan ini dengan host groups, yaitu label yang memuat sekumpulan host.

Ada dua konsep kunci yang wajib dipahami:

• Host Groups — label langsung pada host, misalnya webservers atau dbservers.
• Child Groups — grup yang anggotanya adalah grup lain, membentuk hierarki seperti struktur organisasi perusahaan.

Perhatikan pola hierarki pada contoh inventory di atas: grup prod dan staging adalah child groups yang menaungi webservers dan dbservers. Dengan struktur ini, satu perintah ansible prod -m ping otomatis menjangkau seluruh server di environment production — tanpa harus menyebutkan satu per satu.

Setiap inventory juga memiliki dua grup implisit yang selalu ada:

• all — berisi semua host yang terdaftar.
• ungrouped — host yang tidak masuk ke grup mana pun.

#Host Variables: Cara Ansible Menghubungi Server

Inventory yang baik tidak cukup hanya berisi nama host. Ansible perlu tahu bagaimana menghubungi server tersebut. Di sinilah peran host variables — variabel yang nilainya berlaku khusus untuk satu host.

Empat variabel koneksi yang paling sering dipakai:

all:
  hosts:
    webserver-prod:
      ansible_host: 10.0.1.10
      ansible_user: deploy
      ansible_port: 22
      ansible_ssh_private_key_file: ~/.ssh/id_rsa_prod
    webserver-staging:
      ansible_host: 10.0.2.10
      ansible_user: devops
      ansible_ssh_private_key_file: ~/.ssh/id_rsa_staging
  children:
    dbservers:
      hosts:
        db-server:
          ansible_host: 10.0.1.20
      vars:
        ansible_user: postgres

Perhatikan contoh di atas:

• Key inventory (webserver-prod) hanyalah nama logis. IP asli didefinisikan lewat ansible_host. Ini sangat berguna ketika IP server berubah tapi nama logis tetap — playbook kalian tidak perlu diubah.
• vars di level grup (ansible_user: postgres untuk semua dbservers) memungkinkan satu pengaturan berlaku untuk banyak host sekaligus. Ini contoh nyata prinsip DRY (Don't Repeat Yourself) dalam inventory.
• Setiap environment dapat memakai user dan kunci SSH yang berbeda — pemisahan akses antar environment adalah praktik keamanan yang wajib.

#Pola Matching Host (Host Patterns)

Setelah inventory terdefinisi, bagaimana caranya menargetkan subset host tertentu? Jawabannya adalah host patterns — bahasa untuk memilih host berdasarkan grup dan operator.

Contoh kombinasi praktis yang sangat berguna dalam operasional harian — misalnya ingin menargetkan semua web server di production kecuali satu yang sedang bermasalah:

ansible 'webservers:&production:!web-02.prod.example.com' -m ping

#Memverifikasi Inventory dengan ansible-inventory

Semakin besar infrastruktur, semakin mudah salah menulis inventory. Untungnya Ansible menyediakan utilitas ansible-inventory untuk memvalidasi dan mengintrospeksi struktur inventory:

ansible-inventory -i inventory.yml --graph

@all:
  |--@ungrouped:
  |--@webservers:
  |  |--web-01.prod.example.com
  |  |--web-01.staging.example.com
  |  |--web-02.prod.example.com
  |--@dbservers:
  |  |--db-01.prod.example.com
  |  |--db-01.staging.example.com
  |--@prod:
  |  |--@webservers:
  |  |  |--web-01.prod.example.com
  |  |  |--web-02.prod.example.com
  |  |--@dbservers:
  |  |  |--db-01.prod.example.com
  |--@staging:
  |  |--@webservers:
  |  |  |--web-01.staging.example.com
  |  |--@dbservers:
  |  |  |--db-01.staging.example.com

Bentuk --graph memperlihatkan hierarki grup dengan sangat jelas. Kalau kalian butuh detail variabel per host, gunakan --list (bisa dikombinasikan dengan --yaml agar output lebih terbaca):

ansible-inventory -i inventory.yml --list --yaml

all:
  children:
    dbservers:
      hosts:
        db-server:
          ansible_host: 10.0.1.20
          ansible_user: postgres
    webservers:
      hosts:
        webserver-prod:
          ansible_host: 10.0.1.10
          ansible_port: 22
          ansible_ssh_private_key_file: ~/.ssh/id_rsa_prod
          ansible_user: deploy
        webserver-staging:
          ansible_host: 10.0.2.10
          ansible_ssh_private_key_file: ~/.ssh/id_rsa_staging
          ansible_user: devops

Perintah lain yang sering dipakai untuk validasi cepat:

ansible all -i inventory.yml --list-hosts

#Pengenalan Dynamic Inventory

Semua contoh di atas adalah static inventory — data ditulis manual dalam file. Ini cukup selama jumlah server stabil dan dikenal sebelumnya. Tetapi bagaimana di era cloud auto-scaling?

Bayangkan sebuah Auto Scaling Group di AWS yang bisa menambah 5 instance EC2 di pagi hari saat traffic naik dan menguranginya di malam hari. Mengikuti perubahan itu dengan menulis inventory manual adalah pekerjaan yang mustahil, lambat, dan rawan salah. Inilah kenapa dynamic inventory lahir.

Mekanismenya sederhana: alih-alih menunjuk ke file statis, data inventory dinamis diambil saat eksekusi berlangsung. Ini membuat daftar server selalu up-to-date mengikuti kondisi nyata di cloud — persis seperti menghubungi directory service alih-alih mengandalkan kartu alamat lama.

#Inventory Plugins: aws_ec2 dan gcp_compute

Di Ansible modern, mekanisme dynamic inventory diimplementasikan lewat inventory plugins. Plugin adalah komponen yang mengetahui cara berkomunikasi dengan penyedia tertentu. Dua yang paling populer adalah amazon.aws.aws_ec2 (AWS EC2) dan google.gcp.gcp_compute (Google Cloud Compute Engine).

Konfigurasi plugin cukup didefinisikan dalam file YAML, lalu file itu dipakai sebagai argumen -i:

plugin: amazon.aws.aws_ec2
regions:
  - ap-southeast-1
filters:
  instance-state-name: running
  tag:Environment: production
keyed_groups:
  - key: tags.Name
    prefix: tag
  - key: tags.Role
    prefix: role
compose:
  ansible_host: public_ip_address

plugin: google.gcp.gcp_compute
projects:
  - my-project-id
zones:
  - asia-southeast1-a
auth_kind: serviceaccount
service_account_file: /home/deploy/sa.json
keyed_groups:
  - key: labels.role
    prefix: role
  - key: labels.env
    prefix: env

ansible-inventory -i aws_ec2.yml --graph
ansible 'role_web' -i aws_ec2.yml -m ping
ansible-playbook -i aws_ec2.yml deploy.yml

Beberapa poin penting dari konfigurasi di atas:

• filters — menyaring instance yang masuk inventory, misalnya hanya yang running dan di environment production. Ini mencegah Ansible mencoba menghubungi instance yang mati.
• keyed_groups — mengelompokkan host otomatis berdasarkan metadata cloud (tags/labels). Instance dengan tag Role: web otomatis masuk grup role_web tanpa perlu menulis satu baris pun.
• compose — memetakan variabel dari data cloud. Contohnya ansible_host diambil dari public IP instance.

Untuk kebutuhan kredensial, plugin membaca dari variable environment standar cloud (misalnya AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) atau file service account. Sama seperti host variables, jangan pernah menyimpan kredensial di dalam file konfigurasi plugin yang masuk Git.

#Kesalahan Umum dalam Mengelola Inventory

Mari kita tutup dengan daftar kesalahan yang paling sering membuat praktisi terjebak:

#Penutup

Pada episode 3 ini, kita telah membahas inventory secara menyeluruh: format INI vs YAML, hierarki host groups, host variables untuk mengatur koneksi SSH, host patterns untuk menargetkan server secara presisi, verifikasi dengan ansible-inventory, hingga pengenalan dynamic inventory untuk infrastruktur cloud yang bergerak dinamis.

Inti dari episode ini sederhana namun sangat menentukan: inventory adalah peta infrastruktur kalian, dan seluruh skill automasi selanjutnya — ad-hoc command, playbook, handler, hingga roles — selalu berjalan di atas inventory.

Di episode 4 selanjutnya, kita akan menggunakan inventory ini untuk praktik nyata: Ad-Hoc Commands untuk keperluan operasional harian, seperti cek status server, mengelola file, install package, hingga restart layanan — semuanya dari satu command line. Pastikan tetap semangat!