Manual Infrastructure #

Sebelum memahami mengapa Ansible diperlukan, kamu perlu memahami apa yang terjadi tanpa Ansible. Bukan untuk nostalgia — tapi karena memahami masalahnya membuat solusinya jauh lebih masuk akal. Bagian ini membahas pendekatan manual dalam mengelola infrastruktur, di mana letak masalahnya, dan mengapa masalah itu semakin besar seiring skala yang tumbuh.

Pendekatan Manual: SSH dan Perintah Langsung #

Pendekatan paling dasar adalah masuk ke setiap server via SSH dan menjalankan perintah secara langsung. Untuk satu server, ini cukup. Prosesnya mudah diikuti, hasilnya langsung terlihat.

# Admin masuk ke server, lalu menjalankan perintah satu per satu
ssh admin@web-01
sudo apt update
sudo apt install -y nginx
sudo systemctl enable nginx
sudo systemctl start nginx

Masalah mulai muncul saat server kedua, ketiga, dan seterusnya perlu dikonfigurasi dengan cara yang sama. Admin harus masuk ke setiap server, menjalankan perintah yang sama, dan berharap tidak ada yang terlewat.

Masalah Konsistensi #

Manusia tidak sempurna dalam menjalankan tugas berulang. Saat mengkonfigurasi server ke-7 dari 10 server, kemungkinan besar ada satu langkah yang terlewat — mungkin lupa mengaktifkan service, atau menggunakan versi paket yang berbeda.

# Di web-01: admin menggunakan versi spesifik
sudo apt install -y nginx=1.24.0

# Di web-02: admin lupa pin versi, menginstal versi terbaru
sudo apt install -y nginx

# Hasilnya: dua server dengan versi nginx berbeda
# Bug yang hanya muncul di salah satu server adalah mimpi buruk debugging

Kondisi di mana server-server yang seharusnya identik ternyata berbeda disebut configuration drift. Ini adalah masalah yang diam-diam tumbuh dan baru ketahuan saat ada insiden produksi.

Configuration drift adalah salah satu penyebab paling umum dari bug yang sulit direproduksi — sesuatu bekerja di satu server tapi tidak di server lain, padahal “seharusnya sama”.

Masalah Dokumentasi #

Konfigurasi yang dilakukan secara manual sering tidak terdokumentasi. Siapa yang tahu bahwa tiga bulan lalu ada admin yang menambahkan cron job khusus di web-03? Atau bahwa ada file konfigurasi yang diedit langsung tanpa dicatat?

Kondisi nyata di banyak tim:
  ✗ "Tidak ada yang tahu mengapa service ini ada di sini"
  ✗ "Server ini beda konfigurasinya, tapi tidak ada yang ingat kenapa"
  ✗ "Jangan restart server itu — sesuatu akan rusak, tapi kami tidak tahu apa"
  ✗ "Hanya Pak Budi yang tahu cara setup server ini"

Ini yang sering disebut snowflake server — server yang begitu unik dan tidak terdokumentasi sehingga tidak ada yang berani menyentuhnya. Jika server ini rusak, tidak ada cara untuk mereplikasinya.

Skrip Shell sebagai Solusi Parsial #

Langkah evolusi berikutnya adalah menulis skrip shell. Logikanya masuk akal: otomasi perintah-perintah yang diulang, simpan dalam file, jalankan di setiap server.

#!/bin/bash
# setup-webserver.sh

set -e

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

# Copy config
cp /tmp/nginx.conf /etc/nginx/nginx.conf
systemctl reload nginx

echo "Setup selesai!"

Ini lebih baik dari perintah manual. Tapi skrip shell punya batasan yang serius saat digunakan untuk configuration management.

# ANTI-PATTERN: skrip shell tidak idempoten
apt install -y nginx   # Aman diulang, karena apt menangani ini

systemctl start nginx  # Jika nginx sudah berjalan, ini tidak masalah

# Tapi bagaimana dengan ini?
useradd deployuser     # Akan error jika user sudah ada!
mkdir /opt/app         # Akan error jika direktori sudah ada!

# Kamu harus tambahkan pengecekan manual:
id -u deployuser &>/dev/null || useradd deployuser
[ -d /opt/app ] || mkdir /opt/app
# Skrip jadi panjang dan penuh kondisi edge case

Setiap operasi di skrip shell perlu ditangani secara manual untuk membuatnya aman dijalankan berulang. Skrip yang “aman” dijalankan di server yang sudah dikonfigurasi berbeda dengan skrip yang “aman” dijalankan di server baru.

Masalah Skalabilitas #

Bahkan dengan skrip shell, kamu masih harus mendistribusikan dan menjalankannya secara manual ke setiap server. Untuk 50 server, kamu mungkin menggunakan loop:

# Mendistribusikan skrip ke banyak server
for server in web-01 web-02 web-03 ... web-50; do
  scp setup-webserver.sh admin@$server:/tmp/
  ssh admin@$server "bash /tmp/setup-webserver.sh"
done

Ini memunculkan pertanyaan baru: bagaimana jika satu server gagal di tengah eksekusi? Bagaimana kamu tahu server mana yang berhasil dan mana yang tidak? Bagaimana jika kamu perlu menjalankan langkah berbeda untuk server database dibanding server web?

Kompleksitas yang tumbuh:
  Server web     → skrip A
  Server DB      → skrip B
  Server cache   → skrip C
  Server baru    → skrip A + langkah onboarding tambahan
  Update config  → skrip D yang harus tahu kondisi sebelumnya

Skrip shell yang awalnya sederhana berevolusi menjadi kumpulan skrip yang saling bergantung, sulit di-debug, dan hampir tidak ada yang benar-benar memahami keseluruhannya.

Ringkasan #

Pendekatan manual via SSH tidak skalabel dan rentan terhadap kesalahan manusia saat jumlah server bertambah.
Configuration drift terjadi saat server yang seharusnya identik punya kondisi berbeda karena proses manual yang tidak konsisten.
Snowflake server adalah server yang tidak terdokumentasi dan tidak bisa direplikasi — tanda kegagalan manajemen infrastruktur manual.
Skrip shell lebih baik dari manual, tapi tidak menyelesaikan masalah idempotency, distribusi, error handling, dan dokumentasi secara menyeluruh.
Semua masalah ini semakin parah seiring pertumbuhan jumlah server — itulah mengapa tool seperti Ansible diperlukan.

← Sebelumnya: Apa itu Ansible Berikutnya: Alternatives →