Belajar Ansible - Sejarah, Latar Belakang & Mengapa Membutuhkan Ansible

#Pendahuluan

Setelah di episode 0 sebelumnya kita membahas dan menyiapkan semua prasyarat — mulai dari skill Linux CLI, SSH, YAML, hingga instalasi Ansible di Control Node — pada episode kali ini kita akan menarik napas sejenak dari hands-on dan menyelami mengapa Ansible ada. Kita akan menelusuri sejarahnya, memahami permasalahan nyata yang memicunya, dan melihat kenapa Ansible menjadi salah satu tool paling populer di dunia DevOps dan SRE.

Mengapa memahami sejarah dan latar belakang ini penting? Sebagai engineer, kalian tidak hanya perlu tahu cara mengoperasikan sebuah tool, tapi juga alasan tool tersebut dirancang dengan cara tertentu. Pemahaman ini akan menuntun kalian dalam mengambil keputusan arsitektural di dunia nyata: kapan harus memakai Ansible, kapan harus memakai Terraform, kapan harus menulis skrip shell biasa, dan kapan ketiganya harus bekerja sama. Tanpa konteks ini, kalian hanya akan menjadi tool operator — bukan infrastructure engineer.

#Evolusi Automation: Dari Script Manual ke Infrastructure as Code

Untuk memahami Ansible, kita harus melihat perjalanan panjang bagaimana manusia mengelola server dari zaman ke zaman.

#Era 1: Setup Manual (Satu Per Satu)

Sebelum era otomasi, mengelola server berarti login satu per satu melalui SSH dan mengetik perintah secara manual. Mau install nginx di 5 server? Login ke server 1, install, login server 2, install, dan seterusnya. Belum lagi masalah configuration drift — kondisi di mana setiap server "menyimpang" dari kondisi ideal karena perintah diketik manual dan lupa dicatat. Server 1 mungkin terinstall nginx versi 1.2, sementara server 3 masih versi 1.0 karena lupa di-update.

Masalah utamanya jelas: proses yang tidak terdokumentasi tidak bisa direproduksi, tidak bisa diaudit, dan tidak bisa diskalakan. Satu server masih bisa ditangani, tapi bagaimana dengan 50 server, 500 server, atau ribuan server?

#Era 2: Shell Scripting & SSH Loop

Langkah logis berikutnya adalah otomatisasi parsial menggunakan skrip shell. Daripada mengetik manual, kita tulis skrip bash lalu jalankan di banyak server dengan loop SSH.

#!/bin/bash
# install_nginx.sh - pendekatan lama yang menyakitkan
SERVERS=("10.0.0.11" "10.0.0.12" "10.0.0.13")
 
for server in "${SERVERS[@]}"; do
    echo "=== Processing $server ==="
    ssh devops@"$server" "sudo apt update && sudo apt install -y nginx"
    if [ $? -eq 0 ]; then
        echo "OK: $server"
    else
        echo "FAILED: $server" >> errors.log
    fi
done

Sekilas pendekatan ini tampak berhasil. Namun mari kita bongkar kelemahan-kelemahannya, karena justru dari kelemahan inilah Ansible lahir:

1. Tidak idempotent: menjalankan skrip dua kali akan menginstall nginx dua kali (atau malah error). Kita tidak punya cara untuk menyatakan "pastikan nginx terinstall" secara deklaratif.
2. Tidak ada state tracking: skrip tidak tahu kondisi server saat ini, apakah sudah ada package, apakah service sudah berjalan.
3. Error handling manual: kita harus menulis if [ $? -eq 0 ] di setiap langkah. Semakin panjang skrip, semakin rentan.
4. Berantakan dan sulit di-review: skrip shell yang panjang adalah kode imperatif — sulit dibaca, sulit ditinjau orang lain, dan sulit diuji.
5. Tidak ada abstraksi portability: perintah apt di Ubuntu berbeda dengan dnf di Rocky Linux. Skrip harus bercabang-cabang untuk tiap distro.

#Era 3: Infrastructure as Code (IaC) & Configuration Management

Dari frustrasi itulah lahir paradigma Infrastructure as Code (IaC) — memperlakukan konfigurasi infrastruktur sebagai kode yang bisa di-versioning di Git, di-review, diuji, dan diterapkan ulang secara konsisten. Salah satu manifestasinya adalah Configuration Management (CM) tool: perangkat lunak yang mendeskripsikan keadaan akhir (desired state) dari sebuah server, lalu memastikan server tersebut selalu berada di keadaan itu.

Di era inilah muncul generasi tool seperti CFEngine (1993), Puppet (2005), Chef (2009), SaltStack (2011), dan kemudian Ansible (2012). Masing-masing menawarkan jawaban atas masalah yang sama, tapi dengan filosofi arsitektur yang berbeda — dan di sinilah Ansible menemukan pembedanya.

#Sejarah Ansible: Michael DeHaan dan Pendekatan Berbeda

Ansible diciptakan oleh Michael DeHaan pada tahun 2012. Sebelum Ansible, DeHaan adalah pencipta Cobbler — sebuah tool otomasi Linux provisioning — dan sempat bekerja di Red Hat. Pengalamannya mengelola banyak server dan melihat betapa rumitnya solusi agent-based yang ada saat itu membawanya pada sebuah pertanyaan sederhana namun revolusioner:

"Kenapa kita harus menginstall daemon/agent di setiap server hanya untuk mengelola konfigurasinya? Kenapa kita tidak cukup menggunakan SSH yang memang sudah ada?"

Dari pertanyaan itu lahirlah Ansible dengan arsitektur agentless. Tahun 2015, Ansible resmi diakuisisi oleh Red Hat, yang kemudian mengembangkannya menjadi produk Ansible Automation Platform (AAP). Kehadiran Red Hat membawa bobot enterprise: dukungan resmi, sertifikasi, ekosistem Collection yang luas, hingga interface web (AWX/Tower) untuk skala organisasi besar.

#Mengapa Memilih Ansible?

Setelah memahami sejarahnya, mari kita bahas mengapa Ansible memenangkan hati begitu banyak engineer. Ada tiga pilar utama yang membedakannya.

#1. Agentless: Cukup SSH + Python

Konsep ini adalah pembeda terbesar Ansible. Tool seperti Puppet dan Chef mengharuskan kalian menginstall agent (daemon) di setiap server yang dikelola. Agent tersebut berjalan terus-menerus, berkomunikasi dengan master server, dan menjadi bagian dari sistem yang harus dipelihara, di-update, dan diawasi.

Ansible justru bekerja sebaliknya: tidak ada agent, tidak ada daemon, tidak ada port tambahan yang dibuka. Ansible cukup menggunakan SSH (atau protokol lain yang sudah ada) untuk masuk ke server, mengeksekusi perintah, dan keluar.

Implikasi praktisnya sangat besar:

• Mudah memulai: tidak perlu menginstall apa pun di managed node. Setiap server baru cukup punya Python 3 dan SSH server.
• Jejak keamanan lebih kecil: tidak ada proses tambahan yang berjalan, tidak ada port ekstra yang harus dibuka firewall, tidak ada secret yang disimpan di target.
• Lebih sedikit yang perlu di-maintain: tidak ada agent yang perlu di-upgrade secara berkala di ribuan server.

#2. Idempotency: Hasil yang Sama, Berapa Pun Kali Dijalankan

Idempotency adalah sifat di mana sebuah operasi yang dijalankan berulang kali memberikan hasil akhir yang sama tanpa efek samping tambahan. Ini konsep matematis yang menjadi prinsip inti Configuration Management.

Mari kita bandingkan dengan skrip shell biasa:

useradd devops

Jalankan sekali → berhasil. Jalankan dua kali → error user 'devops' already exists. Skrip imperatif tidak tahu kondisi server, ia hanya mengeksekusi perintah secara membabi buta.

Sekarang bandingkan dengan cara Ansible:

- name: Pastikan user devops ada
  ansible.builtin.user:
    name: devops
    state: present

Modul user Ansible akan mengecek kondisi server terlebih dahulu. Jika user sudah ada, modul melaporkan ok dan tidak melakukan apa-apa. Jika belum ada, modul membuatnya dan melaporkan changed. Hasil akhirnya selalu sama: user devops ada di server.

Idempotency inilah yang menyelesaikan masalah configuration drift yang kita bahas di awal. Jalankan playbook di pagi hari, di malam hari, atau setelah server di-rollback — hasilnya selalu konsisten dengan desired state yang kita tulis.

#3. Human-Readable Declarative YAML

Coba bandingkan dua cara mendeskripsikan "pasang nginx" di bawah ini:

sudo apt update
sudo apt install -y nginx
sudo systemctl enable nginx
sudo systemctl start nginx

- name: Pastikan nginx terinstall dan berjalan
  ansible.builtin.apt:
    name: nginx
    state: present
  ansible.builtin.service:
    name: nginx
    state: started
    enabled: true

YAML mendeskripsikan apa yang ingin kita capai (desired state), bukan bagaimana melakukannya (prosedur langkah demi langkah). Konsekuensinya:

• Mudah dibaca non-programmer: stakeholder teknis, junior, hingga auditor bisa memahami apa yang sedang dikonfigurasi.
• Mudah di-review di pull request: dif-dif konfigurasi menjadi jelas dan bermakna.
• Mudah dikolaborasi: YAML mengurangi "sakralitas" kode — siapa pun bisa berkontribusi pada repositori infrastruktur.

#Perbandingan dengan Tools Lain

Agar kalian bisa memposisikan Ansible dengan tepat, mari bandingkan dengan tool-tool sejenis di ekosistem automation.

#Ansible vs Puppet/Chef: Agentless vs Agent-Based

Pilihan antara agentless dan agent-based adalah keputusan arsitektural fundamental:

• Agentless (Ansible): lebih mudah diadopsi, tidak ada daemon ekstra, cocok untuk environment yang berubah-ubah (ephemeral cloud instances, container) dan untuk pushing konfigurasi sesuai permintaan.
• Agent-based (Puppet/Chef): agent berjalan terus-menerus dan bisa melakukan pulling konfigurasi secara periodik dari master, membentuk sistem self-healing — kalau ada yang menyimpang, agent otomatis memperbaikinya. Cocok untuk lingkungan statis berskala sangat besar yang butuh compliance kontinu.

#Ansible vs Terraform: Config Management vs Provisioning

Ini perbedaan yang wajib dipegang teguh:

• Terraform: mengelola lifecycle infrastruktur — membuat, mengubah, menghapus resource cloud (VPC, EC2, RDS, dll). Ia fokus pada infrastructure provisioning dan menjaga state infrastruktur.
• Ansible: bekerja di atas infrastruktur yang sudah ada — menginstall package, menyalin konfigurasi, mengelola service, men-deploy aplikasi. Ia fokus pada configuration management dan application deployment.

Analoginya: Terraform adalah kontraktor yang membangun rumah (struktur, tembok, plafon), sedangkan Ansible adalah dekorator interior yang mengisi rumah tersebut (furnitur, lampu, dekorasi). Keduanya dibutuhkan untuk menghasilkan rumah yang layak huni.

#Contoh Nyata: Masalah Skrip Manual vs Solusi Ansible

Mari kita tutup dengan studi kasus konkret yang menunjukkan mengapa Ansible unggul. Skenarionya: kita punya 3 server web yang harus selalu memiliki nginx, curl, dan htop terinstall.

Dengan pendekatan SSH loop, setiap kali ada server baru kita harus menjalankan skrip, memantau output, dan berharap tidak ada yang error di tengah jalan. Kini dengan Ansible, kita cukup menulis playbook sekali:

---
- name: Konfigurasi dasar web server
  hosts: webservers
  become: true
  tasks:
    - name: Update apt cache
      ansible.builtin.apt:
        update_cache: true
 
    - name: Install package wajib
      ansible.builtin.apt:
        name: "{{ item }}"
        state: present
      loop:
        - nginx
        - curl
        - htop

Lalu jalankan terhadap semua server sekaligus:

ansible-playbook -i inventory.ini webserver.yml

PLAY RECAP *********************************************************************
10.0.0.11 : ok=4    changed=3    unreachable=0    failed=0    skipped=0
10.0.0.12 : ok=4    changed=3    unreachable=0    failed=0    skipped=0
10.0.0.13 : ok=4    changed=3    unreachable=0    failed=0    skipped=0

Perhatikan beberapa hal yang berubah drastis dibandingkan skrip manual:

1. Satu file untuk semua server — tidak perlu loop manual, Ansible yang mengurus paralelisme.
2. Hasil terstruktur — setiap task dilaporkan statusnya (ok/changed/failed), memudahkan audit.
3. Idempotent — jalankan kembali playbook yang sama, semua task akan menjadi ok tanpa perubahan (changed=0).
4. Termasuk dalam kode — file ini bisa masuk Git, di-review, diuji, dan di-rollback.

Inilah esensi pergeseran paradigma dari imperative scripting ke declarative automation yang dibawa Ansible.

#Penutup

Di episode 1 ini kita telah menelusuri perjalanan dari manual server management, ke shell scripting yang menyakitkan, hingga lahirnya paradigma Infrastructure as Code dan Configuration Management. Kita juga sudah memahami mengapa Ansible — dengan filosofi agentless, idempotency, dan YAML deklaratif — menjadi pilihan yang begitu populer sejak diciptakan Michael DeHaan pada 2012 hingga kini di bawah Red Hat.

Poin penting yang harus kalian bawa dari episode ini:

• Masalah utama otomasi pra-Ansible adalah drift, non-idempotency, dan skrip yang tidak mudah di-review.
• Ansible memilih agentless: cukup SSH + Python di target, tanpa daemon tambahan.
• Idempotency menjamin hasil eksekusi konsisten berapa pun kali dijalankan.
• YAML deklaratif mendeskripsikan desired state, bukan prosedur langkah demi langkah.
• Ansible mengisi ruang configuration management & deployment, sementara Terraform mengisi infrastructure provisioning — keduanya komplementer.

Di episode 2 selanjutnya, kita akan masuk lebih dalam ke jeroan Ansible: konsep dasar dan arsitektur utama. Kita akan membedah bagaimana sebenarnya Ansible bekerja di balik layar, mulai dari Control Node dan Managed Nodes, alur eksekusi modul via SSH, hingga komponen-komponen kunci seperti Inventory, Playbook, Tasks, Modules, dan ansible.cfg. Pastikan tetap semangat, karena mulai episode berikutnya kita akan semakin sering menyentuh baris perintah dan file konfigurasi nyata! 😄