Belajar Ansible - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Setelah di episode 1 sebelumnya kita membahas sejarah, latar belakang, dan alasan mengapa Ansible menjadi pilihan utama di dunia otomasi — mulai dari evolusi shell scripting, konsep agentless, hingga perbandingannya dengan Puppet, Chef, dan Terraform — pada episode kali ini kita akan menarik tirai dan membedah apa yang sebenarnya terjadi di balik layar setiap kali kita menjalankan perintah Ansible.

Mengapa kita perlu memahami arsitektur ini? Ada pepatah dalam dunia engineering: "kalian tidak bisa memperbaiki apa yang tidak kalian pahami". Ketika playbook kalian error di production, ketika eksekusi tiba-tiba lambat, atau ketika kalian harus mendesain strategi pengelolaan ratusan server — pemahaman arsitektur inilah yang menjadi pembeda antara engineer yang cuma menebak-nebak dan engineer yang mampu diagnose dengan tepat. Episode ini adalah fondasi mental model kalian tentang Ansible.

#Arsitektur Ansible Secara Umum

Sebelum membahas komponen detail, mari kita lihat gambaran besar arsitektur Ansible terlebih dahulu.

                     +------------------------------+
                     |        CONTROL NODE          |
                     |                              |
                     |  +------------------------+  |
                     |  |    ANSIBLE ENGINE       |  |
                     |  |  (playbook, modules,    |  |
                     |  |   inventory, config)    |  |
                     |  +------------+-----------+  |
                     +---------------|--------------+
                                     |  SSH (port 22)
                 +-------------------+------------------+
                 |                   |                  |
        +--------+---------+ +------+--------+ +--------+---------+
        |  MANAGED NODE 1  | | MANAGED NODE 2 | | MANAGED NODE 3  |
        |  Python 3        | | Python 3       | | Python 3        |
        |  (Ubuntu Server) | | (Rocky Linux)  | | (Debian Server) |
        +------------------+ +-----------------+ +-----------------+

Sekilas gambaran di atas mungkin terlihat sederhana, tapi di dalamnya tersembunyi keputusan desain yang sangat elegan. Ada dua peran besar dalam arsitektur ini:

1. Control Node — satu-satunya mesin tempat Ansible diinstall dan semua perintah dieksekusi.
2. Managed Nodes — server-server target yang dikelola, cukup dengan Python dan SSH server.

#Control Node

Control Node adalah otak dari seluruh operasi Ansible. Inilah mesin tempat kalian menjalankan ansible, ansible-playbook, ansible-galaxy, dan seluruh tooling Ansible lainnya. Karakteristiknya:

• Hanya satu Control Node yang dibutuhkan untuk mengelola ribuan server.
• Semua file penting — inventory, playbook, roles, ansible.cfg — berada di sini.
• Tidak ada daemon yang harus berjalan; Ansible bekerja secara push-based — mengirim perintah kapan pun kita mau.

#Managed Nodes

Managed Nodes adalah target dari semua pekerjaan Ansible — bisa berupa server Linux, perangkat jaringan (switch/router), server Windows, hingga container. Syaratnya sangat ringan:

• SSH server aktif (untuk koneksi) dan IP yang terjangkau dari Control Node.
• Python 3 tersedia (untuk mengeksekusi modul-modul Ansible).
• Tidak perlu menginstall agent, daemon, atau library Ansible apa pun.

Inilah keindahan agentless yang kita bahas di episode 1: biaya untuk "memasukkan" sebuah server ke dalam manajemen Ansible hampir nol.

#Alur Kerja Eksekusi Ansible Under the Hood

Pertanyaan besar yang sering muncul: "Lalu apa yang sebenarnya terjadi ketika Ansible mengirim perintah?" Mari kita bedah alur eksekusinya langkah demi langkah.

1. Control Node membaca inventory untuk mengetahui daftar managed nodes dan variabel-variabel terkait.
2. Ansible memvalidasi playbook, meng-expand variabel & template (Jinja2), lalu membangun daftar task untuk tiap host.
3. Ansible membuka koneksi SSH ke setiap managed node.
4. Ansible mengirimkan modul (program Python sementara) beserta argumennya ke managed node — biasanya ke direktori temporary di sisi target.
5. Managed node mengeksekusi modul Python tersebut.
6. Modul menjalankan logika idempotent-nya (mengecek state, lalu mengubah bila diperlukan).
7. Setelah selesai, skrip sementara tersebut dihapus dari managed node.
8. Hasil eksekusi dikembalikan ke Control Node dalam format JSON, lalu ditampilkan dalam bentuk yang manusiawi oleh callback plugin.

Control Node                        Managed Node
    |                                    |
    | 1. Baca inventory & validasi playbook |
    |----------------------------------->|
    | 2. Buka koneksi SSH               |
    |----------------------------------->|
    | 3. Kirim modul Python + argumen   |
    |----------------------------------->|
    |                                    | 4. Eksekusi modul (cek state)
    |                                    | 5. Terapkan perubahan bila perlu
    |                                    | 6. Hapus script sementara
    | 7. Kembalikan hasil JSON          |
    |<-----------------------------------|
    | 8. Render output ke terminal      |

Mari kita lihat bukti nyata alur ini dengan menjalankan modul ping dan mengamati output JSON-nya:

ansible -i inventory.ini all -m ping -v

Using /home/devops/lab-ansible/ansible.cfg as config file
 
PLAY [all] *****************************************************************
 
TASK [ping] *****************************************************************
ok: [10.0.0.11] => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}
 
PLAY RECAP ******************************************************************
10.0.0.11              : ok=1    changed=0    unreachable=0    failed=0

Perhatikan "ping": "pong" — ini bukan ICMP ping, melainkan bukti bahwa Control Node berhasil: (1) terhubung via SSH, (2) mengirim modul Python ping.py ke target, (3) mengeksekusinya, dan (4) menerima hasil JSON kembali. Seluruh siklus agentless tadi terjadi dalam hitungan detik.

#Komponen-Komponen Kunci Ansible

Sekarang kita masuk ke komponen-komponen yang membentuk "kosa kata" Ansible. Ini adalah istilah-istilah yang akan kalian pakai setiap hari.

#Inventory

Inventory adalah daftar managed nodes yang dikenal Ansible, beserta variabel yang melekat padanya. Formatnya bisa INI (klasik) atau YAML (modern), dan bisa bersifat static (file) atau dynamic (dihasilkan dari API cloud).

[webservers]
web01 ansible_host=10.0.0.11 ansible_user=devops
web02 ansible_host=10.0.0.12 ansible_user=devops
 
[dbservers]
db01 ansible_host=10.0.0.13 ansible_user=devops
 
[all:vars]
ansible_port=22
ansible_ssh_private_key_file=~/.ssh/id_ed25519

all:
  children:
    webservers:
      hosts:
        web01:
          ansible_host: 10.0.0.11
          ansible_user: devops
        web02:
          ansible_host: 10.0.0.12
          ansible_user: devops
    dbservers:
      hosts:
        db01:
          ansible_host: 10.0.0.13
          ansible_user: devops

#Playbook & Play

Playbook adalah file YAML yang berisi instruksi deklaratif — "apa yang harus dilakukan terhadap server mana". Playbook berisi satu atau lebih Play. Setiap Play mendefinisikan:

• hosts — pola host mana yang dikenai perintah (target).
• become — apakah perlu privilege escalation (sudo).
• tasks — daftar task yang dijalankan terhadap host-host tersebut.

---
- name: Konfigurasi dasar semua web server   # <- Play 1
  hosts: webservers
  become: true
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
 
- name: Konfigurasi dasar semua db server     # <- Play 2
  hosts: dbservers
  tasks:
    - name: Install postgresql
      ansible.builtin.apt:
        name: postgresql
        state: present

Cara membaca hierarkinya: Playbook berisi Play, Play berisi Tasks, dan Task menggunakan Modules. Seperti membaca buku: buku (playbook) terdiri dari bab (play), bab terdiri dari paragraf (task), dan paragraf menggunakan kata-kata (module).

#Tasks & Modules

Task adalah unit eksekusi terkecil dalam playbook — satu instruksi yang dijalankan terhadap host. Sedangkan Module adalah kode (umumnya Python) yang benar-benar melakukan pekerjaan di managed node.

Ansible memiliki ratusan module yang dikelompokkan dalam Collections (misalnya ansible.builtin, community.general, amazon.aws). Berikut beberapa module yang paling sering dipakai:

Mari kita lihat dua module yang paling mendasar: ping dan setup.

# Tampilkan semua fakta sistem target (output sangat panjang)
ansible -i inventory.ini web01 -m setup
 
# Filter fakta spesifik (misal OS family & total memori)
ansible -i inventory.ini web01 -m setup -a "filter=ansible_os_family"
ansible -i inventory.ini web01 -m setup -a "filter=ansible_memtotal_mb"

10.0.0.11 | SUCCESS => {
    "ansible_facts": {
        "ansible_os_family": "Debian",
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false
}

#Ansible Config (ansible.cfg)

Seluruh perilaku default Ansible diatur dalam file konfigurasi ansible.cfg. Urutan prioritas pencariannya (dari yang paling diutamakan):

1. Variabel environment (ANSIBLE_CONFIG).
2. File ansible.cfg di direktori kerja saat ini.
3. File ~/.ansible.cfg di home user.
4. File /etc/ansible/ansible.cfg (default sistem).

[defaults]
inventory = ./inventory.yml
forks = 10
host_key_checking = False
remote_user = devops
private_key_file = ~/.ssh/id_ed25519
timeout = 30
retry_files_enabled = False
 
[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

Mari kita bahas opsi yang paling penting pada contoh di atas:

• inventory: menentukan file inventory default, sehingga kita tidak perlu terus mengetik -i inventory.yml.
• forks: jumlah koneksi paralel ke managed nodes sekaligus. Default 5, diatur lebih tinggi untuk mempercepat eksekusi pada banyak server.
• host_key_checking: pada lab, diset False agar tidak prompt konfirmasi fingerprint. Di production, biarkan aktif atau kelola known_hosts dengan benar.
• remote_user & private_key_file: kredensial default SSH yang dipakai semua host (bisa di-override per host di inventory).
• [privilege_escalation]: default untuk become/sudo, sehingga tidak perlu menulis become: true di tiap task (tapi tetap boleh di-override).

Untuk melihat konfigurasi aktif beserta sumbernya, gunakan perintah ansible-config dump atau ansible-config list:

# Lihat semua nilai konfigurasi + dari mana asalnya
ansible-config dump
 
# Lihat hanya opsi tertentu
ansible-config dump | grep -i forks

#Rangkuman Mental Model

Sebelum kita tutup, mari kita susun kembali seluruh konsep episode ini menjadi satu mental model utuh:

ansible.cfg  (konfigurasi default)
      |
inventory.yml  (daftar managed nodes)
      |
playbook.yml   (Play -> Tasks -> Modules)
      |
Control Node --SSH--> Managed Node (Python 3)
      |                              |
      +--- kirim modul ------------> |
      |                              +--- eksekusi & cek state
      +--- terima hasil JSON <-----  |

Singkatnya: ansible.cfg mengatur cara, inventory menentukan ke mana, dan playbook menentukan apa yang harus dilakukan — semuanya dieksekusi dari Control Node ke Managed Nodes melalui SSH dengan alur kirim modul, eksekusi, hapus, dan kembalikan JSON.

#Penutup

Di episode 2 ini kita telah membedah arsitektur dan komponen inti Ansible. Kita belajar bahwa Ansible bekerja dengan dua peran — Control Node sebagai otak dan Managed Nodes sebagai target — dengan alur eksekusi yang elegan dan agentless: mengirim modul Python via SSH, mengeksekusinya di target, menghapus script sementara, lalu mengembalikan hasil dalam format JSON.

Poin penting yang harus kalian bawa:

• Control Node adalah satu-satunya tempat Ansible diinstall; managed node cukup punya Python + SSH.
• Alur eksekusi: SSH -> Kirim modul -> Eksekusi -> Hapus -> Kembalikan JSON.
• Inventory mendaftarkan server; Playbook berisi Play; Play berisi Tasks; Task memakai Modules.
• ansible.cfg mengatur perilaku default (inventory, forks, SSH, privilege escalation).
• Modul ping dan setup adalah alat debugging pertama yang wajib dikuasai.

Bagaimana episode 2 kali ini? Semoga arsitektur Ansible yang tadinya tampak "magis" kini terasa lebih transparan dan bisa dinalar. Percayalah, pemahaman fondasi seperti inilah yang membuat kalian percaya diri saat menghadapi error di playbook nanti.

Nah, untuk melanjutkan perjalanan kita, di episode 3 selanjutnya kita akan membahas Mengelola Inventory (Static & Dynamic) — dari format INI vs YAML, pengelompokan host, host patterns, hingga pengenalan dynamic inventory untuk era cloud yang auto-scaling. Pastikan tetap semangat, karena mulai episode berikutnya kita akan semakin sering bergelut dengan file konfigurasi dan perintah nyata! 😄