Belajar Puppet - Ekosistem Alternatif & Refleksi Akhir

#Pendahuluan

Inilah episode terakhir. Selama 21 episode sebelumnya kalian berjalan dari nol: memahami mengapa configuration management ada, menulis manifests dan modules, memanfaatkan Hiera dan PuppetDB, mengamankan komunikasi dengan SSL, hingga merakit arsitektur yang siap produksi. Episode 21 menutup materi teknis dengan arsitektur production-ready — Puppet Server dengan high availability, PuppetDB di atas PostgreSQL, Code Manager, pipeline CI/CD, dan strategi backup.

Episode 22 bukan lagi soal fitur baru; ia tentang melihat keluar dan ke depan. Kita akan menempatkan Puppet dalam peta configuration management dan membandingkannya dengan Ansible, Chef, SaltStack, serta Terraform dan Pulumi — lalu merangkum seluruh perjalanan dari episode 0 hingga 21, meninggalkan checklist untuk infrastruktur production-grade, dan menunjuk referensi serta arah masa depan untuk terus bertumbuh.

#Puppet dalam Peta Configuration Management

Puppet bukan satu-satunya pemain di lapangan. Setiap tool mengambil keputusan desain yang berbeda — bahasa, model push atau pull, kehadiran agent, dan kebutuhan server pusat — dan keputusan itulah yang menentukan kapan tool tersebut tepat dipakai. Mari lihat peta lengkapnya.

#Puppet: Declarative, Pull-Based, Agent

Puppet menggunakan Puppet DSL yang sangat declarative, model pull-based (agent di node yang menarik catalog dari server), dan membutuhkan server pusat — Puppet Server atau Puppet Enterprise. Keunggulannya ada pada desired state yang tegas, resource graph dengan dependency antar resource, reporting dan compliance bawaan lewat PuppetDB, serta dukungan enterprise penuh. Kelemahannya: DSL yang lebih kaku dibanding Ruby atau Python, dan kompleksitas operasional server yang tidak bisa dihindari.

#Ansible: YAML, Push-Based, Tanpa Agent

Ansible mendeklarasikan state dalam YAML dan menerapkannya dengan model push: dari satu control node, SSH menuju target. Tanpa agent dan tanpa server pusat, Ansible unggul dalam kesederhanaan dan onboarding — tim kecil bisa produktif dalam hitungan menit. Kelemahannya: tidak ada state yang dipertahankan antar run, sangat bergantung pada koneksi SSH yang stabil, dan konvergensi terjadwal harus dijadwalkan dari luar.

#Chef: Ruby, Cookbook, Server Pusat

Chef memakai Ruby DSL dengan unit yang disebut cookbook, model pull-based dengan agent (chef-client) yang menarik kebijakan dari Infra Server. Fleksibilitas Ruby membuat Chef sangat ekspresif untuk logika konfigurasi, dan ekosistemnya lengkap lewat InSpec serta Chef Automate. Kelemahannya: kurva belajar Ruby dan kompleksitas mengoperasikan server pusat, mirip dengan Puppet.

#SaltStack: Python, Hybrid, Cepat

SaltStack (Salt) menawarkan model hybrid: minion bisa di-push maupun di-pull, ditulis dalam Python, dengan targeting yang sangat fleksibel dan eksekusi paralel yang cepat. Salt kuat untuk orkestrasi ad-hoc berskala besar dan lingkungan yang butuh respon cepat. Kelemahannya: ekosistem dan dokumentasinya lebih kecil serta kadang tertinggal dibanding pemain utama.

#Terraform dan Pulumi: Bukan Configuration Management

Terraform dan Pulumi bukan configuration management — mereka adalah Infrastructure as Code untuk provisioning: mendeklarasikan infrastruktur (instance, network, storage) melalui provider cloud, bukan konfigurasi di dalam mesin. Terraform memakai HCL, sedangkan Pulumi memakai bahasa pemrograman umum seperti TypeScript, Python, atau Go. Keduanya bekerja bersama Puppet, bukan menggantikannya — misalnya Terraform membuat instance, lalu Puppet mengkonfigurasinya.

#Perbandingan Langsung dalam Kode

Cara terbaik memahami perbedaan filosofi adalah melihat intent yang sama ditulis dalam dua tool. Berikut instalasi nginx yang sama: sekali dalam playbook Ansible, sekali dalam class Puppet.

- hosts: web
  become: true
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
    - name: Ensure nginx running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

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

Perbedaan paling mencolok: playbook Ansible adalah urutan langkah yang di-push dari control node melalui SSH, sedangkan class Puppet adalah pernyataan desired state yang ditarik agent dari server. Eksekusi Ansible dilakukan dengan ansible-playbook site.yml, sedangkan Puppet menunggu agent menjalankan puppet apply --test pada interval terjadwal — dan hasilnya selalu dikonvergensikan ulang bila melenceng.

#Tabel Perbandingan

#Kapan Memilih Masing-masing

Tidak ada tool yang menang di semua dimensi — ada tool yang tepat untuk setiap konteks:

• Pilih Puppet ketika organisasi sangat enterprise, butuh reporting dan compliance bawaan dari PuppetDB, dan menginginkan DSL yang sangat declarative dengan konvergensi terjadwal di ribuan node.
• Pilih Ansible ketika tim lebih kecil, infrastruktur bersifat sementara atau eksperimental, dan kalian ingin memulai dalam hitungan menit tanpa agent maupun server.
• Pilih Chef ketika tim sudah nyaman dengan Ruby, butuh cookbook yang sangat ekspresif, dan ingin kebijakan compliance yang bisa diaudit dengan InSpec.
• Pilih SaltStack ketika kalian butuh eksekusi paralel massal dan fleksibilitas push-pull pada infrastruktur besar.
• Pilih Terraform atau Pulumi untuk lapisan provisioning — membangun dan menghancurkan infrastruktur — dan gabungkan dengan Puppet untuk lapisan konfigurasi di dalamnya.

#Rekapitulasi Perjalanan 0-21

Mari kita lirik peta yang sudah kalian tempuh:

• Episode 0-2: fondasi — prasyarat skill dan setup environment, sejarah configuration management, serta konsep dasar dan arsitektur utama client-server.
• Episode 3-5: mulai menyentuh kode — setup dan instalasi, manifests dan resource types, lalu classes, modules dan roles/profiles.
• Episode 6-8: data dan relasi — facts, variables dan Facter; Hiera sebagai hierarki data; catalog dan resource relationships.
• Episode 9-11: skala dan otomasi — PuppetDB, Puppet Enterprise console dan orchestration, serta Bolt untuk menjalankan perintah lintas node.
• Episode 12-14: alur produksi — Code Manager dan r10k untuk deploy kode, authentication dan security dengan SSL serta hiera-eyaml, dan modules dari Forge.
• Episode 15-17: kedalaman — best practice, custom resources, functions dan providers, serta PuppetDB query dan exported resources lanjutan.
• Episode 18-19: kualitas — testing dengan rspec-puppet dan Beaker, lalu performance tuning dan troubleshooting.
• Episode 20-21: kedewasaan — fitur stabil terbaru di Puppet 8 dan PE 2025, lalu arsitektur production-ready dengan high availability.

Perhatikan pola di balik urutan itu: setiap episode mengunci kemampuan sebelumnya. Kalian tidak bisa merancang arsitektur production tanpa memahami catalog, dan tidak bisa memahami catalog tanpa paham manifests. Inilah kurikulum yang sengaja dirancang agar setiap skill berdiri di atas skill lain.

#Checklist IaC Production-Grade

Sebagai pemantapan, berikut checklist yang merangkum seluruh pelajaran — gunakan ini sebagai standar minimum setiap kali kalian membangun infrastruktur:

• Semua state sebagai kode — manifests, hiera, dan Puppetfile berada di version control, di-review, dan dirilis lewat pipeline.
• Idempotency ketat — setiap resource aman dijalankan berulang kali; noop run bersih dan tidak menampilkan perubahan pada state yang sudah benar.
• Data terpisah dari kode — hiera memegang data environment, dan rahasia dienkripsi dengan hiera-eyaml; tidak ada secret di manifest.
• Testing berjenjang — puppet-lint untuk gaya, rspec-puppet untuk unit test, dan acceptance test untuk mesin nyata, semuanya berjalan di CI.
• Kode mengalir dari Git — tidak ada yang meng-edit langsung di server; semua lewat Puppetfile dan r10k atau Code Manager, dengan rilis dan rollback satu perintah.
• Monitoring dan reporting — report di PuppetDB dipantau, alert aktif untuk node failed atau corrective changes yang tak terduga.
• Backup lalu uji backup — kunci CA dan database PuppetDB wajib di-backup dan rutin diuji restorasinya.

Satu hal yang mengikat semuanya: kebiasaan. Checklist ini hanya bermakna jika menjadi bagian dari cara kerja tim kalian. Sebelum mulai proyek baru, pastikan tooling di lingkungan kalian konsisten — verifikasi versi dengan puppet --version dan puppetserver --version:

puppet --version
puppetserver --version
pdk --version
bolt --version
r10k --version
puppet-lint --version

#Masa Depan Puppet

Ke mana Puppet bergerak? Tiga arah yang perlu kalian ikuti:

• Puppet Enterprise — SCM (Server Configuration Management), manajemen node berbasis peran, dan security compliance terus menjadi pusat gravitasi untuk organisasi enterprise; PE 2023.8 LTS tetap tersedia gratis hingga sepuluh node.
• Puppet open source 8.x — rilis reguler dengan Ruby 3.3 dan modernisasi tooling terus berlanjut; Puppet OSS tetap jalan yang valid untuk tim tanpa anggaran enterprise.
• Cloud-native — integrasi dengan Kubernetes dan provider cloud semakin dalam, dengan Puppet menjadi lapisan konfigurasi di dalam ekosistem yang lebih luas, bukan pengganti container orchestration.

#Referensi untuk Terus Belajar

Curiosity adalah aset terbesar. Berikut titik awal untuk melanjutkan perjalanan:

• puppet.com/docs — dokumentasi resmi untuk Puppet Server, Agent, PuppetDB, Bolt, Puppet Enterprise, dan Code Manager.
• GitHub puppetlabs — source code dan issue tracker; tempat terbaik melihat perkembangan dan berkontribusi.
• Forge — katalog module komunitas di forge.puppet.com untuk mempelajari praktik nyata.
• PDK — pdk new module untuk menulis module dengan struktur dan linting bawaan.
• puppet-lint — puppet-lint modules/nginx/manifests/init.pp untuk menegakkan gaya kode.
• rspec-puppet — unit test untuk manifest, dipasangkan dengan puppetlabs_spec_helper.
• hiera-eyaml — eyaml encrypt -l db_password untuk mengenkripsi hiera.
• Bolt dan r10k — bolt command run uptime --nodes web1.example.net untuk orkestrasi, r10k deploy environment production untuk deployment environment.

Jangan berhenti di dokumentasi — baca module populer di Forge, ikuti release notes, dan bangun sesuatu. Keterampilan yang kalian bangun akan terus berguna selama kalian mempraktikkannya.

#Penutup

Dan di sinilah perjalanan 23 episode (0 hingga 22) Belajar Puppet berakhir. Kalian telah menyusuri setiap lapisan: dari prasyarat dan sejarah, konsep dan arsitektur, manifests dan resource types, modules dan roles/profiles, facts dan Hiera, catalog dan PuppetDB, konsol dan orkestrasi, Code Manager dan keamanan, pengujian dan troubleshooting, hingga fitur terbaru dan arsitektur production — dan sekarang ekosistem serta refleksi.

Inti yang harus dibawa pulang:

• Desired state adalah cara berpikir — setiap node adalah janji yang harus dijaga, setiap run adalah pembuktian, dan setiap manifest adalah dokumen yang hidup.
• Data terpisah dari kode — Hiera memegang variasi, hiera-eyaml melindungi rahasia, dan manifest tetap bersih dari data lingkungan.
• Idempotency adalah naluri — resource yang aman dijalankan ulang adalah fondasi seluruh ekosistem Puppet.
• Testing sebelum deploy — puppet-lint, rspec-puppet, dan acceptance test berjenjang adalah harga masuk untuk produksi yang tenang.
• Kebiasaan mengalahkan alat — tool yang baik tanpa disiplin review, pengujian, dan monitoring hanyalah kode yang berjalan.

Keterampilan yang kalian bangun tidak terikat pada satu tool — ia membuat kalian menjadi engineer yang lebih baik di tool mana pun. Terima kasih sudah bertahan sampai episode terakhir. Praktikkan checklist-nya, bagikan module kalian, dan jadikan idempotency sebagai naluri. Selamat membangun infrastruktur yang bisa dipercaya!