Apa itu Playbook? #

Apabila inventaris (inventory) mendefinisikan siapa yang kita kelola di dalam infrastruktur, maka Playbook (Buku Panduan) adalah komponen yang mendefinisikan apa tindakan otomatisasi yang harus kita lakukan terhadap mereka. Playbook bertindak sebagai jantung dari ekosistem otomatisasi Ansible. Ditulis menggunakan bahasa penanda YAML yang deklaratif, playbook memungkinkan kita mendokumentasikan serangkaian alur kerja terurut—mulai dari instalasi paket sistem, penyuntingan konfigurasi, hingga pengelolaan siklus hidup layanan—untuk dieksekusi secara berulang dengan hasil yang konsisten. Artikel ini membahas konsep dasar otomatisasi deklaratif, menyandingkan perintah ad-hoc dengan playbook, membedah anatomi berkas playbook, menjelaskan komponen utama blok play, hingga memandu cara eksekusi dan penelusuran laporan hasil.

Konsep Dasar Deklaratif #

Satu pilar filosofi penulisan playbook Ansible yang membedakannya dengan skrip bash tradisional adalah pendekatan Deklaratif (Declarative Approach). Dalam pemrograman imperatif (seperti skrip shell), kita menuliskan bagaimana (how) langkah-langkah teknis harus dijalankan secara prosedural. Kita harus mengecek apakah direktori sudah ada, menulis logika if-else untuk mengecek status paket, dan menangani error secara manual.

Sebaliknya, pendekatan deklaratif di playbook Ansible menuntut kita untuk fokus mendefinisikan status akhir yang diinginkan (desired state atau what), bukan prosedur teknis mencapainya.

Berikut adalah visualisasi alur bagaimana Ansible memproses status deklaratif playbook dari berkas fisik hingga eksekusi runtime di target server:

flowchart TD
    A["YAML Playbook (site.yml)"] -->|"1. Parse & Sintaks Validasi"| B["Ansible Playbook Executor"]
    B -->|"2. Baca Inventaris (hosts.ini)"| C["Host Mapping (webservers, dbservers)"]
    C -->|"3. Rakit Variabel & Precedence"| D["HostVars Database (Memori)"]
    D -->|"4. Eksekusi Play 1 (Linear)"| E["Managed Node Batch 1"]
    D -->|"5. Eksekusi Play 2 (Linear)"| F["Managed Node Batch 2"]
    E -->|"6. Kumpulkan Output & Recap"| G["Laporan Hasil di Terminal (PLAY RECAP)"]
    F -->|"6. Kumpulkan Output & Recap"| G

Ansible Engine secara cerdas akan mendeteksi status aktual target server saat ini (actual state), membandingkannya dengan status akhir yang kita inginkan di playbook, lalu hanya akan melakukan tindakan perubahan jika status aktual tidak sesuai dengan status akhir. Prinsip inilah yang mewujudkan keandalan sifat Idempotensi (Idempotency).

Perbandingan Ad-hoc Command dan Playbook #

Ansible menyediakan dua metode eksekusi: Ad-hoc Commands (Perintah Cepat) dan Playbooks. Kita harus memilih metode yang paling efisien berdasarkan konteks tugas operasional kita.

1. Ad-hoc Commands (Perintah Satu Aksi) #

Merupakan perintah tunggal yang dijalankan langsung dari terminal baris perintah tanpa disimpan ke dalam berkas otomatisasi. Metode ini sangat baik untuk tugas pemeliharaan cepat sekali jalan (quick, one-time tasks).

• Kasus Penggunaan: Memeriksa kapasitas memori target server, melakukan reboot cepat, atau menyalin satu berkas darurat ke managed node.
• Contoh Perintah:

  # Memeriksa kapasitas disk server di grup webservers
  ansible webservers -m command -a "df -h" -u ubuntu
  
  # Menginstal paket curl di seluruh managed node secara paralel
  ansible all -m apt -a "name=curl state=present" --become
  

2. Playbooks (Buku Panduan Terstruktur) #

Merupakan berkas teks berformat YAML yang menyimpan seluruh rangkaian alur kerja otomatisasi yang kompleks secara terstruktur.

• Kasus Penggunaan: Proses provisioning server baru dari nol, deployment rilis aplikasi multi-tier, konfigurasi kluster database, atau pengerasan keamanan (security hardening) server.
• Contoh Perintah:

  # Menjalankan seluruh alur konfigurasi terstruktur
  ansible-playbook -i inventory/production/hosts.ini playbooks/site.yml
  

Tabel di bawah ini merangkum perbandingan komparatif antara Ad-hoc dan Playbook:

Anatomi Struktur Berkas Playbook #

Sebuah berkas playbook terdiri dari satu atau beberapa blok Play (Skenario). Satu Play berfungsi untuk memetakan sekumpulan server target (dari inventaris) dengan rangkaian tugas (Tasks) yang akan dijalankan oleh modul-modul Ansible.

Berikut adalah anatomi visual dari berkas playbook standar industri:

# File: playbooks/setup-webserver.yml
---
# Tanda tiga strip menandai dimulainya dokumen YAML

# ==================== PLAY 1: Web Tier Setup ====================
- name: Konfigurasikan Web Server Nginx
  hosts: webservers
  become: true
  
  vars:
    http_port: 80
    app_directory: /var/www/my-app

  tasks:
    - name: Pasang paket Nginx
      apt:
        name: nginx
        state: present

    - name: Salin file konfigurasi virtual host
      template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/sites-available/default
      notify: Memicu Restart Nginx

    - name: Pastikan layanan Nginx aktif dan berjalan saat booting
      systemd:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Memicu Restart Nginx
      systemd:
        name: nginx
        state: restarted

# ==================== PLAY 2: Database Tier Setup ====================
- name: Konfigurasikan Server Database PostgreSQL
  hosts: dbservers
  become: true

  tasks:
    - name: Pasang paket PostgreSQL
      apt:
        name: postgresql
        state: present

Penjelasan Elemen Struktural: #

1. - name: (Tingkat Play): Label penjelas skenario global. Output teks ini akan muncul di konsol terminal kita untuk memudahkan peninjauan alur kerja.
2. hosts:: Menunjuk sasaran server target (dalam contoh di atas grup webservers pada Play 1 dan grup dbservers pada Play 2).
3. tasks:: Daftar instruksi kerja deklaratif yang akan dieksekusi secara berurutan dari atas ke bawah.
4. handlers:: Tugas khusus yang bertindak sebagai penerima sinyal (event listener). Tugas ini tidak akan berjalan kecuali ada tugas di bagian tasks: yang menghasilkan status perubahan (changed) dan mengirimkan sinyal notify: yang namanya cocok dengan handler tersebut.

Komponen Utama Blok Play #

Saat menyusun sebuah blok Play, kita dapat menggunakan parameter kendali bawaan Ansible untuk mengatur jalannya otomatisasi:

1. hosts (Penyaringan Target) #

Menentukan sasaran server eksekusi. Kita dapat menggunakan pola penulisan yang fleksibel:

hosts: webservers:dbservers   # Gabungan grup (webservers ATAU dbservers)
hosts: webservers:&jakarta     # Irisan grup (webservers yang juga anggota grup jakarta)
hosts: all:!bastion            # Semua server di inventaris KECUALI server bastion

2. become (Eskalasi Privilege) #

Mengatur apakah Ansible harus menjalankan seluruh tugas di bawah play ini menggunakan hak akses administratif (root):

become: true                  # Aktifkan eskalasi
become_method: sudo           # Menggunakan perintah sudo (default Linux)
become_user: root             # Menjadi user root (default)

3. vars (Variabel Lokal Play) #

Mendefinisikan parameter konfigurasi lokal yang hanya berlaku di dalam cakupan blok play ini saja. Variabel ini memiliki prioritas precedence lebih tinggi daripada variabel di inventaris group_vars/all.yml.

4. gather_facts (Pengumpulan Data Target) #

Secara default, sebelum menjalankan tugas pertama, Ansible akan menjalankan tugas implisit bernama Gathering Facts untuk mendeteksi informasi detail server target (seperti alamat IP, tipe OS, sisa RAM, kapasitas disk).

gather_facts: false

Jika playbook kita sama sekali tidak membutuhkan variabel informasi hardware target (misalnya playbook kita hanya bertugas memicu API eksternal atau melakukan reboot), kita sangat direkomendasikan untuk mengatur gather_facts: false guna memangkas durasi eksekusi playbook secara signifikan (menghemat waktu jabat tangan SSH negosiasi data).

Panduan Lengkap Eksekusi CLI #

Kita menggunakan perintah biner ansible-playbook untuk menjalankan berkas skenario playbook kita. Ansible menyediakan argumen CLI tingkat lanjut untuk membantu kontrol eksekusi yang aman.

Berikut adalah daftar perintah eksekusi yang wajib dikuasai oleh pengembang otomatisasi:

1. Menjalankan Playbook Standar #

ansible-playbook -i inventory/production/hosts.ini playbooks/setup-webserver.yml

2. Membatasi Target Secara Dinamis (Limit) #

Jika di dalam playbook tertulis hosts: webservers, namun kita hanya ingin menguji eksekusi ke server prod-web-01 saja tanpa merubah kode playbook fisik:

ansible-playbook -i inventory/production/hosts.ini playbooks/setup-webserver.yml --limit "prod-web-01.unisbadri.com"

3. Melakukan Uji Coba Simulasi (Dry Run) #

Menggunakan opsi --check (atau dry run) membuat Ansible memproses alur playbook dan membandingkan status sistem tanpa mengirimkan perintah modifikasi apa pun ke target server. Sangat penting dilakukan sebelum menerapkan perubahan di server produksi:

ansible-playbook -i inventory/production/hosts.ini playbooks/setup-webserver.yml --check

4. Menampilkan Detail Perubahan Kode (Diff Mode) #

Opsi --diff akan menampilkan output perubahan file konfigurasi sistem secara visual (mirip git diff) sebelum dan sesudah eksekusi. Sangat baik jika digabungkan dengan mode check:

ansible-playbook -i inventory/production/hosts.ini playbooks/setup-webserver.yml --check --diff

5. Resume Eksekusi dari Task Tertentu #

Jika eksekusi playbook kita mengalami kegagalan di tengah jalan pada task nomor 10 akibat masalah jaringan, setelah kita memperbaiki masalah tersebut, kita dapat melanjutkan eksekusi langsung dari task yang gagal tanpa mengulangi task 1 sampai 9:

ansible-playbook -i inventory/production/hosts.ini playbooks/setup-webserver.yml --start-at-task "Salin file konfigurasi virtual host"

Membedah Hasil Laporan dan Play Recap #

Ketika playbook dieksekusi, Ansible akan mencetak laporan interaktif ke layar terminal. Pada bagian akhir eksekusi, Ansible menyajikan laporan ringkas berupa PLAY RECAP:

PLAY RECAP *****************************************************************************************
prod-web-01.unisbadri.com  : ok=4  changed=1  unreachable=0  failed=0    skipped=0    rescued=0
prod-web-02.unisbadri.com  : ok=3  changed=0  unreachable=0  failed=0    skipped=1    rescued=0
prod-db-01.unisbadri.com   : ok=2  changed=0  unreachable=1  failed=0    skipped=0    rescued=0

Penjelasan Status Laporan: #

• ok: Jumlah tugas yang berhasil dijalankan tanpa memerlukan tindakan modifikasi karena target server sudah berada dalam status akhir yang diinginkan (idempotensi terpenuhi).
• changed: Jumlah tugas yang berhasil melakukan perubahan modifikasi sistem target agar sesuai dengan status akhir yang diinginkan.
• unreachable: Menunjukkan bahwa Ansible gagal menginisiasi koneksi SSH ke target server (masalah jaringan, user salah, port tertutup, atau private key ditolak).
• failed: Jumlah tugas yang gagal dieksekusi (skrip crash, argumen modul salah, dependensi paket kurang). Jika sebuah host mengalami status failed, Ansible secara default akan menghentikan seluruh tugas berikutnya khusus untuk host tersebut.
• skipped: Jumlah tugas yang dilewati karena tidak memenuhi parameter kondisional when.

Playbook sebagai Dokumentasi Hidup #

Di era rekayasa infrastruktur modern, salah satu nilai tambah utama dari playbook adalah fungsinya sebagai Dokumentasi yang Dapat Dieksekusi (Executable Documentation).

Dalam administrasi server konvensional, panduan instalasi server dicatat di dalam berkas teks statis atau halaman wiki internal perusahaan. Wiki tersebut sering kali tidak akurat karena seiring berjalannya waktu, konfigurasi sistem di server aktual terus berubah tanpa ada yang memperbarui catatan wiki.

Playbook Ansible memecahkan masalah ini. Karena playbook ditulis dalam bahasa YAML deklaratif dengan parameter deskriptif - name: yang komunikatif, playbook secara otomatis merepresentasikan blueprint aktual dari infrastruktur kita yang dapat dibaca oleh siapa saja, sekaligus dapat dijalankan kapan saja untuk memastikan kesesuaian status server.

# File: playbooks/audit-hardening.yml
# Berkas ini bertindak sebagai berkas audit sekaligus penegak kepatuhan keamanan
---
- name: Audit dan Penegakan Kepatuhan Keamanan SSH
  hosts: all
  become: true
  
  tasks:
    - name: Pastikan akses SSH root ditutup
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: "^PermitRootLogin"
        line: "PermitRootLogin no"
        state: present
      notify: Restart Layanan SSH

    - name: Pastikan autentikasi password SSH dinonaktifkan
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: "^PasswordAuthentication"
        line: "PasswordAuthentication no"
        state: present
      notify: Restart Layanan SSH
      
  handlers:
    - name: Restart Layanan SSH
      systemd:
        name: sshd
        state: restarted

Membagikan file ini ke repositori Git perusahaan memungkinkan tim audit keamanan untuk meninjau status keamanan SSH seluruh server cukup dengan membaca kode di atas, tanpa harus melakukan login manual ke ratusan server.

Ringkasan #

• Status Akhir Deklaratif — Playbook Ansible berfokus pada pendefinisian status akhir yang kita inginkan (desired state), membiarkan mesin engine yang menangani detail alur kerja idempoten secara otomatis.
• Efisiensi Kerja — Gunakan perintah ad-hoc hanya untuk tindakan diagnosa cepat sekali jalan; gunakan playbook untuk otomatisasi konfigurasi yang terstruktur dan dapat digunakan kembali.
• Anatomi Terpusat — Playbook tersusun atas blok Play yang bertugas memetakan target server (inventory) dengan instruksi otomatisasi (tasks) dan pemicu aksi lanjutan (handlers).
• Penghematan Waktu gather_facts — Nonaktifkan pencarian fakta target (gather_facts: false) jika alur playbook kita tidak memerlukan pembacaan parameter hardware server.
• Kontrol CLI Tingkat Lanjut — Biasakan melakukan simulasi check mode (--check --diff) sebelum menjalankan rilis otomatisasi ke lingkungan produksi untuk mendeteksi potensi konflik.
• Evaluasi PLAY RECAP — Pantau output rekap akhir secara disiplin untuk melacak status kesehatan host target, khususnya jika terdeteksi indikator failed atau unreachable.
• Dokumentasi Terintegrasi — Tulis parameter nama tugas (- name:) secara deskriptif yang menjelaskan tujuan fungsional tugas tersebut, bukan sekadar perintah terminal yang dijalankan.

← Sebelumnya: Best Practice   Berikutnya: Struktur →