Belajar Puppet - Sejarah, Latar Belakang & Mengapa Membutuhkan Puppet

#Pendahuluan

Di episode 0 sebelumnya kalian sudah menyiapkan prasyarat dan environment — mulai dari skill dasar Linux dan Ruby, hingga instalasi Puppet Server, PDK, dan node uji. Kali ini kita akan menarik napas dari hands-on dan menyelami mengapa Puppet ada. Kita akan menelusuri sejarah configuration management, memahami masalah nyata yang melahirkannya, dan melihat posisi Puppet di antara Chef, Ansible, dan SaltStack.

Mengapa memahami sejarah ini penting? Sebagai engineer, kalian tidak hanya perlu tahu cara menulis manifest, tapi juga alasan Puppet dirancang seperti sekarang — mengapa ia pull-based, mengapa declarative, dan mengapa ekosistemnya begitu lengkap. Tanpa konteks ini, kalian akan kesulitan menilai kapan Puppet adalah pilihan yang tepat dan kapan bukan.

#Era Sebelum Configuration Management

Sebelum ada configuration management, mengelola server adalah pekerjaan yang melelahkan dan rawan kesalahan. Bayangkan mengelola seratus server web: setiap kali ada konfigurasi baru, kalian harus login satu per satu, menjalankan skrip shell atau mengetik perintah manual, lalu berharap tidak ada yang terlewat. Skrip shell sekalipun punya kelemahan besar:

• Tidak idempotent — menjalankan skrip yang sama dua kali bisa menghasilkan keadaan berbeda.
• Tidak ada laporan — tidak ada cara otomatis mengetahui apakah semua server sudah sesuai.
• Drift — server yang satu bisa menyimpang dari yang lain karena perbedaan waktu instalasi atau tangan yang berbeda.

Dari frustrasi itulah lahir generasi tools yang disebut configuration management.

#Evolusi Configuration Management

#CFEngine (1993)

CFEngine karya Mark Burgess adalah tool configuration management pertama. Ia memperkenalkan konsep yang kini menjadi standar industri: mendeskripsikan keadaan yang diinginkan dan membiarkan sistem menjaga dirinya sendiri agar selalu konvergen ke keadaan itu. CFEngine sangat ringan dan efisien, tetapi bahasa konfigurasinya tergolong primitif dan ekosistemnya kecil.

#Puppet (2005)

Luke Kanies membangun Puppet pada tahun 2005 untuk mengatasi keterbatasan CFEngine. Puppet membawa dua terobosan besar:

1. Bahasa declarative tingkat tinggi — manifest Puppet mudah dibaca manusia dan deklaratif, bukan sekadar aturan policy.
2. Model resource — Puppet mengabstraksi sistem menjadi resource type (paket, service, file, user) dengan properti yang jelas.

Puppet juga memperkenalkan ekosistem yang lengkap: server pusat yang menyusun catalog, agent yang berjalan terjadwal, serta reporting terpusat. Inilah yang membuat Puppet menjadi salah satu tools paling dominan di era pertamanya.

#Chef (2009)

Chef hadir dengan filosofi berbeda: kode ditulis dalam Ruby murni dan menganut model client-server dengan arsitektur yang mirip. Pendekatan "infrastructure as code dengan bahasa pemrograman sungguhan" ini memberi fleksibilitas besar, tapi kurva belajarnya lebih curam karena mengharuskan paham Ruby.

#Ansible (2012)

Ansible, karya Michael DeHaan, membalik paradigma: ia push-based dan agentless — tidak ada agent yang berjalan di node, cukup SSH. Pendekatan ini sangat sederhana untuk dipelajari dan cepat diterapkan, sehingga Ansible populer di kalangan yang menginginkan kemudahan.

#Tabel Evolusi

#Model-Driven & Declarative

Puppet adalah sistem model-driven: semua yang dikelola direpresentasikan sebagai model resource dengan properti, bukan sebagai instruksi langkah demi langkah. Manifest Puppet menyatakan bagaimana sistem seharusnya — misalnya nginx terinstall versi tertentu, service berjalan, dan file konfigurasi berisi konten tertentu.

Sistem Puppet juga pull-based: setiap node menjalankan agent-nya secara terjadwal (default 30 menit), agent mengambil catalog dari server, lalu menerapkannya. Model ini berbeda dengan Ansible yang push — perbedaan ini penting untuk dipahami karena memengaruhi cara kalian mendesain lingkungan Puppet.

package { 'nginx':
  ensure => installed,
}
 
service { 'nginx':
  ensure => running,
  enable => true,
}

Perhatikan: kalian tidak menulis "jalankan apt install, lalu jalankan systemctl start". Kalian mendeklarasikan keadaan akhir — Puppet yang menentukan langkah dan mengecek apakah sudah tercapai.

#Masalah yang Diselesaikan Puppet

#Mendefinisikan dan Menjaga Desired State

Masalah inti yang dipecahkan Puppet: mendefinisikan keadaan yang diinginkan untuk tiap server — package, service, file, user — dan menjaganya tetap konvergen. Jika ada orang atau proses lain mengubah file konfigurasi, pada agent run berikutnya Puppet akan mengembalikannya ke keadaan yang dideklarasikan. Inilah arti idempotensi di dunia nyata.

#Skala Besar

Scripting manual tidak akan bertahan untuk ribuan node. Puppet didesain untuk skala itu:

• Agent terjadwal di tiap node berjalan otomatis tanpa campur tangan manusia.
• PuppetDB menyimpan fakta dan laporan semua node, sehingga kalian punya reporting terpusat — bisa tahu node mana yang gagal, node mana yang menyimpang.
• Hiera memisahkan data dari logic, sehingga konfigurasi yang sama bisa diterapkan ke ribuan node dengan data yang berbeda-beda, misalnya per environment dev, staging, dan production.

#Ekosistem Lengkap

Puppet bukan sekadar satu binary — ia satu ekosistem:

#Puppet vs Pendekatan Lain

Perbandingan mendalam akan kita bahas di episode-episode lanjutan; untuk sekarang cukup pahami posisi masing-masing.

#Penutup

Pada episode 1 ini, kita telah menelusuri perjalanan configuration management: dari era scripting manual yang tidak idempotent, lahirnya CFEngine pada 1993, Puppet oleh Luke Kanies pada 2005, hingga Chef dan Ansible yang datang belakangan. Kalian juga sudah memahami model declarative pull-based Puppet serta masalah besar yang dipecahkannya — desired state, konvergensi, skala ribuan node, dan ekosistem yang lengkap.

Inti yang harus dibawa pulang:

• Puppet lahir dari keterbatasan scripting manual dan CFEngine, membawa bahasa declarative dan model resource.
• Puppet pull-based dengan agent terjadwal di tiap node — beda fundamental dengan Ansible yang push.
• Desired state + idempotensi adalah jantung Puppet: sistem menjaga dirinya agar selalu konvergen.
• Ekosistemnya lengkap: Puppet Server, Agent, PuppetDB, Bolt, dan Puppet Enterprise.

Di episode 2 berikutnya kita akan membedah konsep dasar dan arsitektur utama Puppet — alur agent run dari Facter mengumpulkan fakta, autentikasi sertifikat SSL, kompilasi catalog di server, hingga pelaporan ke PuppetDB. Siapkan kopi, karena ini episode paling fundamental untuk memahami cara kerja Puppet dari dalam!