Belajar Puppet - Production-Ready Architecture

#Pendahuluan

Di episode 20 kalian sudah mengenal fitur terbaru di Puppet 8 dan Puppet Enterprise 2025.1, termasuk Security Compliance Management dan manajemen node berbasis peran. Sekarang waktunya menyatukan semuanya ke dalam satu gambaran besar: bagaimana arsitektur Puppet yang sebenarnya di lingkungan produksi berskala ribuan node.

Di lab lokal, satu server Puppet yang melayani beberapa node terasa sederhana. Di produksi, ada banyak pertanyaan baru: bagaimana menjaga server tetap tersedia saat salah satu mati? Bagaimana memastikan kode yang di-deploy selalu konsisten di semua compiler? Bagaimana mencegah agent run yang lambat membebani seluruh pipeline? Episode ini menjawab pertanyaan-pertanyaan itu.

Kita akan membahas arsitektur produksi Puppet — Puppet Server dengan high availability, PuppetDB di atas PostgreSQL, Code Manager dan r10k, serta reporting terpusat — lalu menyambungkannya dengan pipeline CI/CD lengkap dari PDK dan rspec-puppet hingga canary environment, dan menutup dengan praktik monitoring serta backup yang menjaga seluruh sistem tetap sehat.

#Peta Arsitektur Produksi

Arsitektur Puppet produksi yang matang terdiri dari beberapa komponen yang masing-masing punya peran:

Alur logisnya kira-kira seperti ini: agent berbicara ke Puppet Server, server memanggil hiera dan classifier untuk kompilasi, hasilnya dikirim ke agent, agent menerapkan lalu mengirim report, report masuk ke PuppetDB, dan console serta dashboard membaca dari PuppetDB.

#High Availability untuk Puppet Server

Komponen yang paling kritis adalah Puppet Server. Jika ia down, seluruh node kehilangan kemampuan melakukan run. Strategi HA yang umum adalah menempatkan replica sebagai compiler cadangan: environment, modul, dan hiera di-sync dari primary ke replica secara berkala.

Agar agent otomatis pindah ke replica saat primary gagal, gunakan pengaturan server_list pada agent:

puppet config set server puppet-primary.example.net
puppet config set server_list puppet-primary.example.net:8140,puppet-replica.example.net:8140

Dengan server_list, agent mencoba server pertama, lalu berpindah ke server berikutnya jika gagal. Ini jauh lebih tahan banting daripada hanya mengandalkan satu alamat server. Ingat bahwa Certificate Authority sebaiknya tetap berada di primary agar proses signing sertifikat tidak terpecah.

#PuppetDB dan PostgreSQL

PuppetDB menyimpan semua data operasional: facts, catalog, dan report. Semuanya disimpan di PostgreSQL. Karena volume datanya besar, ada beberapa praktik penting:

• Pisahkan server — jangan menaruh PuppetDB di mesin yang sama dengan compiler beban berat.
• Atur TTL — report-ttl, node-ttl, dan node-purge-ttl membatasi pertumbuhan data seperti pada episode 19.
• Monitor pertumbuhan — pantau ukuran database secara rutin agar tidak kehabisan disk.

Query cepat untuk mengecek ukuran database:

SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database ORDER BY pg_database_size(datname) DESC;

PostgreSQL yang sehat membuat query PQL dan dashboard console tetap responsif. Jika antrean pemrosesan report di PuppetDB menumpuk, tambah thread atau pisahkan database ke mesin tersendiri.

#Code Manager dan r10k: Sumber Kode Tunggal

Di produksi, kode tidak boleh di-edit langsung di server. Alur yang benar: kode hidup di Git, lalu didistribusikan oleh r10k atau Code Manager ke environment Puppet. Struktur control repository yang umum:

production/
  hieradata/
  manifests/
  modules/
  site/
Puppetfile

Puppetfile mendeklarasikan module dari Forge atau Git dengan versi yang di-pin:

forge 'https://forge.puppet.com'
 
mod 'puppetlabs/stdlib', '9.4.0'
mod 'puppetlabs/nginx', '5.2.0'
mod 'company-role-web',
    git: 'https://git.company.net/puppet/role-web.git',
    ref: 'main'

Deployment dilakukan lewat perintah berikut, dan Code Manager menjaga reproduktibilitas dengan men-deploy ke commit tertentu:

puppet code deploy production --wait
puppet code deploy production --version <commit-sha> --wait

#CI/CD: Dari PDK Menuju Canary

Pipeline produksi yang sehat menghubungkan pengujian dari episode 18 dengan deployment. Alurnya kira-kira seperti ini:

feature branch -> pdk validate + lint + unit test -> pull request -> main
main -> puppet code deploy production -> canary group -> full rollout

Tahapannya:

1. PDK dan rspec-puppet — setiap branch melewati lint, validate, dan unit test di CI sebelum di-merge.
2. Puppetfile dan Code Manager — setelah merge ke main, Code Manager menarik kode dan mendistribusikannya ke environment production.
3. Canary environment — sekelompok kecil node, misalnya 5-10 persen dari fleet, menjalankan kode baru lebih dulu. Jika report menunjukkan error atau perubahan tak terduga, rollback dilakukan ke commit sebelumnya:

puppet code deploy production --version <commit-sebelumnya> --wait

Prinsip canary penting karena catalog yang lolos unit test belum tentu benar di produksi — hiera production, facts nyata, dan kondisi jaringan hanya bisa diuji pada node asli.

#Reporting Terpusat dan Monitoring

Semua report agent berkumpul di PuppetDB, dan dari sana dikonsumsi oleh berbagai konsumen: dashboard untuk melihat persentase node yang noop, unchanged, failed, atau corrective; sistem alerting untuk metrik kunci; dan Grafana yang membaca metrik PuppetDB.

Praktik monitoring minimum yang perlu dijaga:

#Backup dan Recovery

Backup adalah separuh dari arsitektur produksi. Komponen yang wajib di-backup:

tar -czf puppetserver-backup.tar.gz \
  /etc/puppetlabs/puppet/ssl \
  /etc/puppetlabs/code \
  /etc/puppetlabs/puppetserver/conf.d
pg_dump -Fc puppetdb > puppetdb.dump

Isi backup minimum: kunci dan sertifikat CA di /etc/puppetlabs/puppet/ssl, control repo dan hiera di /etc/puppetlabs/code, konfigurasi server, dan dump database PuppetDB. Simpan backup di lokasi terpisah dan uji restorasi secara berkala — backup yang tidak pernah diuji adalah backup yang tidak ada.

#Penutup

Pada episode ini kita merancang arsitektur Puppet yang siap produksi: Puppet Server dengan high availability dan failover melalui server_list, PuppetDB di atas PostgreSQL dengan pengelolaan TTL, Code Manager dan r10k sebagai sumber kode tunggal, agent di ribuan node, serta reporting dan monitoring terpusat. Kita juga menyusun pipeline CI/CD dari PDK dan rspec-puppet menuju canary environment, dan memastikan backup PuppetDB serta kunci CA tidak terlupakan.

Inti yang harus dibawa pulang:

• Komponen dipisahkan — compiler, PuppetDB, PostgreSQL, dan Code Manager punya beban dan kebutuhan tuning masing-masing.
• Kode mengalir dari Git — tidak ada yang meng-edit langsung di server; semua lewat Puppetfile dan Code Manager.
• Canary sebelum skala penuh — verifikasi di node nyata sebelum kode menyebar ke seluruh fleet.
• Pantau dan alert — metrik kompilasi, antrean, dan PuppetDB adalah penanda awal masalah.
• Backup, lalu uji backup — kunci CA dan database PuppetDB wajib di-backup dan rutin diuji restorasinya.

Di episode 22 — episode terakhir seri ini — kita akan mundur sejenak melihat ekosistem: membandingkan Puppet dengan Ansible, Chef, SaltStack, dan Pulumi/Terraform, lalu merangkum seluruh perjalanan dari episode 0 hingga 21. Sampai jumpa!