Belajar Ansible - Ad-Hoc Commands untuk Operational Harian

#Pendahuluan

Setelah di episode 3 sebelumnya kita membahas cara mengelola inventory — mulai dari format INI dan YAML, pengelompokkan host, host patterns, hingga dynamic inventory — pada episode kali ini kita akan mempraktikkan penggunaan inventory tersebut untuk melakukan pekerjaan nyata: Ad-Hoc Commands.

Ad-hoc command adalah mode Ansible yang paling cepat dan ringkas. Kalau kalian tipe orang yang "lebih dulu bertanya daripada menulis", ad-hoc adalah jawabannya: cukup satu baris perintah, dan puluhan server langsung merespons. Dalam operasional harian, momen seperti ini sangat sering terjadi — misalnya jam 2 pagi ada alert server disk penuh, dan kalian hanya perlu mengecek 40 server sekaligus tanpa menulis playbook.

Namun perlu diingat: ad-hoc bukan pengganti playbook. Ia adalah pisau saku — cepat untuk tugas sekali jalan, tapi bukan alat untuk pekerjaan berulang yang harus terdokumentasi. Di akhir episode kita akan melihat kapan harus berpindah ke playbook.

#Pembahasan Utama

#Apa Itu Ad-Hoc Command?

Secara sederhana, ad-hoc command adalah perintah Ansible yang dijalankan langsung dari terminal tanpa file playbook. Ia memanfaatkan inventory yang sudah kalian siapkan di episode 3, lalu mengeksekusi satu module ke host yang ditargetkan.

#Sintaks Dasar Ad-Hoc Command

Struktur dasar perintah ad-hoc adalah:

ansible <host-pattern> -m <module_name> -a "<module_args>"

Mari kita bedah tiap bagiannya:

• <host-pattern> — target server, persis seperti host pattern yang kita bahas di episode 3 (all, webservers, webservers:&staging, dan seterusnya).
• -m <module_name> — menentukan modul yang dipakai. Modul adalah "senjata" yang menentukan apa yang dilakukan Ansible di server target.
• -a "<module_args>" — argumen modul, berisi parameter spesifik sesuai modul yang dipilih.

Ada juga flag umum yang akan sangat sering kalian pakai:

Contoh paling sederhana: menguji koneksi ke semua host dalam inventory.

ansible all -i inventory.yml -m ansible.builtin.ping

web-01.prod.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
db-01.prod.example.com | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

Setiap host menjawab pong — artinya koneksi SSH, autentikasi, dan interpreter Python semuanya berfungsi. Perhatikan bahwa output berbentuk JSON, karena ini adalah format standar hasil eksekusi modul Ansible.

#Modul Ad-Hoc Favorit untuk Operasional Harian

Ada sekumpulan modul yang hampir pasti kalian pakai setiap hari. Mari kita bahas satu per satu.

#Modul Ping & System Status

Selain ansible.builtin.ping yang sudah dicoba di atas, modul lain yang wajib dikenal adalah ansible.builtin.setup — modul yang mengumpulkan facts (informasi sistem) dari setiap host.

ansible all -i inventory.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"

web-01.prod.example.com | SUCCESS => {
    "ansible_facts": {
        "ansible_distribution": "Ubuntu",
        "ansible_distribution_file_parsed": true,
        "ansible_distribution_major_version": "24",
        "ansible_distribution_release": "noble",
        "ansible_distribution_version": "24.04",
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false
}

Tanpa filter, output setup sangat panjang (berisi CPU, RAM, semua interface jaringan, mounts, dan lainnya) — itu normal, karena modul ini mengumpulkan segalanya. Parameter filter membantu mempersempit output saat kalian hanya butuh bagian tertentu.

#Command vs Shell vs Raw

Ini adalah trio modul yang paling sering disalahpahami. Ketiganya untuk mengeksekusi perintah, tetapi dengan cara yang berbeda:

Contoh nyata ketiganya:

ansible all -i inventory.yml -m ansible.builtin.command -a "uptime"

ansible all -i inventory.yml -m ansible.builtin.shell -a "uptime | awk '{print \$3, \$4}'"

ansible all -i inventory.yml -m ansible.builtin.raw -a "uname -a"

#Modul File & Directory

Untuk membuat direktori, menyentuh file, atau mengatur permission, gunakan ansible.builtin.file:

ansible all -i inventory.yml -b -m ansible.builtin.file -a "path=/var/www/blog state=directory owner=deploy group=www-data mode=0755"

Argumen state menentukan hasil yang diinginkan:

Untuk mendorong file dari control node ke server target, gunakan ansible.builtin.copy:

ansible all -i inventory.yml -b -m ansible.builtin.copy -a "src=/etc/nginx/sites-available/blog.conf dest=/etc/nginx/sites-available/blog.conf owner=root group=root mode=0644"

Skenario ini sangat berguna saat kalian ingin menyebar file konfigurasi yang sama ke banyak server sekaligus.

#Modul Package Management

Memasang, memperbarui, atau menghapus package adalah tugas harian yang paling umum. Modulnya tergantung distro: ansible.builtin.apt untuk Debian/Ubuntu, ansible.builtin.dnf untuk RHEL/Rocky/Alma, dan ansible.builtin.yum untuk RHEL lama.

ansible all -i inventory.yml -b -m ansible.builtin.apt -a "name=nginx state=present update_cache=yes"

ansible all -i inventory.yml -b -m ansible.builtin.dnf -a "name=nginx state=present"

Nilai state pada modul package:

#Modul Service Management

Mengelola layanan (start, stop, restart) menggunakan ansible.builtin.systemd_service untuk sistem modern yang memakai systemd:

ansible web -i inventory.yml -b -m ansible.builtin.systemd_service -a "name=nginx state=restarted"

Parameter state pada modul service: started, stopped, restarted, reloaded. Parameter enabled: true/false mengontrol apakah layanan menyala otomatis saat boot.

#Skenario Praktis Operasional Harian

Sekarang mari kita gabungkan semuanya dalam skenario yang benar-benar terjadi di lapangan.

1. Cek uptime seluruh server

Malam hari, tim ops ingin memastikan tidak ada server yang baru saja reboot sendiri:

ansible all -i inventory.yml -m ansible.builtin.command -a "uptime"

web-01.prod.example.com | SUCCESS | rc=0 >>
 11:24:35 up 42 days,  3:12,  1 user,  load average: 0.31, 0.45, 0.52
web-02.prod.example.com | SUCCESS | rc=0 >>
 11:24:35 up 3 min,  1 user,  load average: 1.10, 1.00, 0.90
db-01.prod.example.com | SUCCESS | rc=0 >>
 11:24:35 up 42 days,  3:12,  1 user,  load average: 0.10, 0.12, 0.11

Perhatikan web-02 baru up 3 menit — sinyal bahwa ada yang tidak beres di server itu. Dengan satu perintah, kalian sudah menemukan anomali yang harus diselidiki. Bandingkan jika harus ssh ke 3 server satu per satu.

2. Reboot serentak

Ketika ada update kernel atau perubahan config yang butuh restart, lakukan rolling reboot. Meskipun bisa pakai command: reboot, ada modul khusus yang lebih baik: ansible.builtin.reboot. Modul ini melakukan reboot, lalu menunggu host kembali online dan SSH siap — sehingga kalian tahu persis kapan aman lanjut ke server berikutnya.

ansible 'webservers:!web-01.prod.example.com' -i inventory.yml -b -m ansible.builtin.reboot

web-02.prod.example.com | CHANGED => {
    "changed": true,
    "elapsed": 42,
    "rebooted": true
}

3. Push SSH key darurat

Ada anggota tim baru yang butuh akses ke semua server sekarang juga. Modul ansible.builtin.authorized_key menyelesaikannya dengan aman — key ditambahkan ke authorized_keys tanpa mengubah file lain:

ansible all -i inventory.yml -b -m ansible.builtin.authorized_key \
  -a "user=deploy state=present key='{{ lookup(\"file\", \"/home/budi/.ssh/id_ed25519.pub\") }}'"

#Mengenal Mode --check (Dry Run)

Sebelum menjalankan perintah yang mengubah sistem (seperti install package atau restart service), sangat disarankan mencoba mode --check terlebih dahulu. Mode ini membuat Ansible tidak benar-benar mengubah apa pun di target — ia hanya menghitung dan melaporkan apa yang akan terjadi.

ansible all -i inventory.yml -b -m ansible.builtin.apt -a "name=nginx state=present" --check

web-01.prod.example.com | SUCCESS => {
    "changed": false,
    "msg": "OK"
}
db-01.prod.example.com | SUCCESS => {
    "changed": true,
    "msg": "If state is 'present', package 'nginx' would be installed"
}

Perhatikan dua hal:

• Host yang sudah terinstall nginx melaporkan changed: false — tidak ada yang akan berubah.
• Host yang belum terinstall melaporkan changed: true dengan pesan "would be installed" — Ansible memberitahu perubahan yang akan terjadi tanpa benar-benar melakukannya.

#Kesalahan Umum dalam Menggunakan Ad-Hoc Command

#Penutup

Pada episode 4 ini, kita telah belajar bahwa ad-hoc command adalah pisau saku Ansible untuk operasional harian. Kalian kini mengenal sintaks ansible <pattern> -m <module> -a "<args>", menguasai modul favorit seperti ping, setup, file, copy, apt/dnf, systemd_service, dan memahami kapan harus memakai command, shell, atau raw. Kita juga sudah mempraktikkan skenario nyata — cek uptime, reboot serentak, dan push SSH key darurat — plus mode --check sebagai sabuk pengaman.

Namun ada satu keterbatasan mendasar dari ad-hoc: ia tidak terdokumentasi dan tidak otomatis idempoten. Perintah yang kalian jalankan jam 2 pagi tidak bisa diulang dengan mudah oleh rekan tim lain.

Di episode 5 selanjutnya, kita akan mengatasi keterbatasan ini dengan mempelajari Penulisan Playbook Pertama & Structure Playbook — mengubah perintah-perintah ad-hoc menjadi file YAML yang dapat dijalankan berulang kali, didokumentasikan, dan menghasilkan status OK, CHANGED, hingga FAILED yang bisa dibaca siapa saja. Pastikan tetap semangat!