Agentless #
Salah satu keputusan desain paling fundamental Ansible adalah arsitektur agentless. Ini bukan sekadar fitur — ini adalah filosofi yang memengaruhi cara kamu setup, troubleshoot, dan mengoperasikan Ansible setiap hari. Memahami apa artinya agentless, bagaimana cara kerjanya, dan apa trade-off-nya akan membuat kamu jauh lebih efektif menggunakan Ansible.
Apa Artinya Agentless #
Tool configuration management berbasis agent mengharuskan kamu menginstal sebuah proses (agent) di setiap server yang akan dikelola. Agent ini berjalan di background, terhubung ke server pusat, mengambil instruksi, dan menerapkannya.
Ansible mengambil pendekatan yang berlawanan. Tidak ada software yang perlu diinstal di server target. Ansible terhubung dari control node (komputer atau server tempat Ansible dijalankan) ke managed node (server target) menggunakan SSH — protokol yang sudah pasti tersedia di hampir semua server Linux.
Arsitektur berbasis AGENT (Chef, Puppet):
┌─────────────────┐ ┌──────────────────────┐
│ Chef Server │◄────────►│ Managed Node │
│ (pusat) │ │ [Chef Agent berjalan]│
└─────────────────┘ └──────────────────────┘
Agent harus diinstal, diupdate, dan dipantau
Arsitektur AGENTLESS (Ansible):
┌─────────────────┐ SSH ┌──────────────────────┐
│ Control Node │─────────►│ Managed Node │
│ (Ansible ada │ │ [hanya butuh SSH │
│ di sini) │ │ + Python] │
└─────────────────┘ └──────────────────────┘
Tidak ada yang perlu diinstal di managed node
Cara Kerja Koneksi Ansible #
Saat kamu menjalankan playbook, Ansible melakukan serangkaian langkah berikut untuk setiap task di setiap managed node:
1. Ansible membaca playbook dan inventory
│
2. Ansible membuka koneksi SSH ke managed node
│
3. Ansible men-generate kode Python kecil (module)
│
4. Module dikirim ke managed node via SSH/SFTP
│
5. Module dieksekusi di managed node menggunakan Python
│
6. Hasil eksekusi dikirim kembali ke control node
│
7. Koneksi SSH ditutup
Proses ini terjadi untuk setiap task. Ansible tidak meninggalkan proses yang berjalan di managed node setelah eksekusi selesai.
# Kamu bisa verifikasi ini — tidak ada proses Ansible di managed node
# setelah playbook selesai berjalan
ssh managed-node "ps aux | grep ansible"
# Hasilnya: tidak ada proses Ansible
Persyaratan di Managed Node #
Karena agentless, persyaratan di managed node sangat minimal:
Yang dibutuhkan di managed node:
✓ SSH server (OpenSSH) — hampir selalu sudah ada
✓ Python 3.x — tersedia di hampir semua distribusi Linux modern
✓ User dengan akses SSH dan privilege yang diperlukan
Yang TIDAK dibutuhkan:
✗ Ansible
✗ Agent atau daemon khusus
✗ Port tambahan selain SSH (22)
✗ Koneksi outbound dari managed node ke control node
Ini berarti kamu bisa mulai menggunakan Ansible pada server yang sudah berjalan tanpa perubahan konfigurasi apapun, selama SSH aktif dan Python tersedia.
Untuk server yang belum punya Python (jarang terjadi di distro modern), Ansible menyediakan module raw yang bisa menjalankan perintah shell langsung tanpa membutuhkan Python. Kamu bisa gunakan ini untuk menginstal Python terlebih dahulu.Keuntungan Agentless #
Tidak ada overhead manajemen agent. Dengan tool berbasis agent, kamu punya satu lapisan infrastruktur tambahan yang harus dijaga: agent harus diupdate saat ada versi baru, dipantau agar tidak crash, dan dikonfigurasi dengan benar. Dengan Ansible, semua kompleksitas itu tidak ada.
Keamanan yang lebih sederhana. Agent yang berjalan di server adalah proses tambahan dengan akses ke sistem. Setiap proses tambahan adalah potensi attack surface. Ansible tidak meninggalkan proses apapun, jadi attack surface-nya lebih kecil.
Onboarding server yang cepat. Menambahkan server baru ke inventory Ansible semudah menambahkan IP address ke file inventory. Tidak perlu provisioning agent, tidak perlu registrasi ke server pusat.
Bekerja di lingkungan yang ketat. Di beberapa lingkungan dengan kebijakan keamanan yang ketat, menginstal software tambahan di server membutuhkan proses approval yang panjang. Karena Ansible tidak membutuhkan instalasi di managed node, hambatan ini tidak ada.
Trade-off Agentless #
Pendekatan agentless juga punya kekurangan yang perlu dipahami.
Tidak ada enforcement berkelanjutan. Karena tidak ada agent yang berjalan terus-menerus, Ansible tidak bisa mendeteksi dan memperbaiki configuration drift secara otomatis. Jika seseorang mengubah konfigurasi server secara manual, Ansible tidak akan tahu sampai kamu menjalankan playbook lagi.
Dengan Puppet (agent-based):
Admin ubah config secara manual
│
Puppet agent mendeteksi perubahan (setiap 30 menit)
│
Puppet mengembalikan config ke kondisi yang benar
→ Drift otomatis diperbaiki
Dengan Ansible (agentless):
Admin ubah config secara manual
│
Ansible tidak tahu (tidak ada yang memantau)
│
Drift baru ketahuan saat playbook dijalankan lagi
→ Perlu trigger manual atau scheduled job
Overhead koneksi SSH per task. Setiap task membuka koneksi SSH baru ke setiap managed node. Untuk playbook dengan banyak task di banyak server, ini bisa menambah waktu eksekusi. Ansible mengatasi ini dengan pipelining dan SSH multiplexing, tapi tetap ada trade-off dibanding agent yang selalu terhubung.
Ketergantungan pada SSH. Jika SSH tidak bisa dijangkau — misalnya karena firewall atau konfigurasi jaringan yang ketat — Ansible tidak bisa bekerja. Tool berbasis agent dengan pull model bisa tetap bekerja karena agent yang menginisiasi koneksi dari dalam.
Ringkasan #
- Agentless berarti tidak ada software yang perlu diinstal di managed node — Ansible hanya butuh SSH dan Python.
- Ansible mengirimkan module Python kecil via SSH ke managed node, menjalankannya, lalu mengambil hasilnya — tidak ada proses yang tertinggal.
- Keuntungan utama: tidak ada overhead manajemen agent, onboarding server yang cepat, dan attack surface yang lebih kecil.
- Trade-off utama: tidak ada enforcement otomatis berkelanjutan — Ansible hanya bekerja saat kamu menjalankannya.
- Untuk sebagian besar skenario, agentless adalah keuntungan besar yang memudahkan adopsi dan pengelolaan.