Belajar Puppet - Catalog & Resource Relationships

#Pendahuluan

Di episode 7 kalian sudah belajar memisahkan data ke Hiera dan mengambilnya dengan lookup. Kini tibalah saat penyatuan: manifest dan data dikompilasi oleh server menjadi satu dokumen bernama catalog. Di episode 8 kita mempelajari bagaimana catalog dibangun, bagaimana urutan resource dikendalikan dengan before, require, notify, subscribe, dan chaining panah, serta error katalog yang paling sering menggagalkan run.

Catalog adalah hasil akhir dari kompilasi — daftar resource yang sudah jadi dengan semua parameternya, siap dijalankan oleh agent. Di dalamnya tidak ada lagi if atau case, hanya resource konkret.

#Apa Itu Catalog

Siklus Puppet adalah: agent mengirim facts ke server, server mengkompilasi catalog dari manifest dan data Hiera, lalu mengirim catalog kembali ke agent. Agent membandingkan desired state di catalog dengan kondisi aktual node, lalu mengoreksi perbedaan.

puppet apply --noop manifests/site.pp
puppet apply --noop --verbose manifests/site.pp

puppet apply --noop adalah cara tercepat menguji manifest di mesin lokal tanpa benar-benar mengubah sistem. Dengan --verbose, kalian melihat setiap resource yang akan dicek.

Karena catalog adalah data terkompilasi, urutan deklarasi di manifest tidak selalu sama dengan urutan eksekusi. Hubungan antar resource diatur secara eksplisit, dan itu adalah topik inti episode ini.

#before dan require

Puppet tidak menjamin urutan eksekusi antar resource tanpa relasi yang jelas. Metaparameter before dan require membangun dependensi maju dan mundur:

package { 'nginx':
  ensure => installed,
  before => File['/etc/nginx/conf.d/app.conf'],
}
 
file { '/etc/nginx/conf.d/app.conf':
  ensure  => file,
  content => template('profile/web/nginx.conf.erb'),
  require => Package['nginx'],
}
 
service { 'nginx':
  ensure => running,
  enable => true,
}

before => File[...] pada package artinya: package harus selesai sebelum file dikelola. require => Package['nginx'] pada file menuliskan relasi yang sama dari arah sebaliknya — memakai keduanya untuk relasi yang sama adalah redundan.

#notify dan subscribe

Relasi before dan require hanya mengatur urutan. Untuk memicu aksi tambahan — misalnya restart service setelah konfigurasi berubah — gunakan notify dan subscribe. Ini adalah relasi event-driven: jika resource yang di-notify berubah, resource penerima ikut bereaksi.

file { '/etc/nginx/conf.d/app.conf':
  ensure  => file,
  content => template('profile/web/nginx.conf.erb'),
  notify  => Service['nginx'],
}
 
service { 'nginx':
  ensure => running,
  enable => true,
  subscribe => File['/etc/nginx/conf.d/app.conf'],
}

notify => Service['nginx'] pada file dan subscribe => File[...] pada service adalah dua arah dari relasi yang sama. Saat konten file berubah, subscribe membuat service menerima event dan restart. Jika konten tidak berubah, tidak ada restart — inilah yang membuat Puppet efisien.

#Chaining dengan Panah

Selain metaparameter, Puppet menyediakan chaining arrows untuk relasi berantai. Panah -> berarti "wajib selesai lebih dulu", sedangkan ~> berarti "notify ketika berubah":

package { 'nginx': ensure => installed }
-> file { '/etc/nginx/conf.d/app.conf':
    ensure  => file,
    content => template('profile/web/nginx.conf.erb'),
  }
~> service { 'nginx':
    ensure => running,
    enable => true,
  }

Rantai di atas setara dengan kombinasi require, before, notify, dan subscribe sebelumnya. Chaining sangat cocok untuk rangkaian langkah yang linear: pasang paket, tulis konfigurasi, lalu jalankan service.

#Cara Server Mengkompilasi Catalog

Saat agent meminta catalog, server menjalankan langkah berikut:

1. Menentukan node dan class yang ter-klasifikasi untuk node tersebut.
2. Mengambil facts terbaru yang dikirim agent.
3. Mengevaluasi manifest dengan data Hiera dari environment node.
4. Merakit semua resource menjadi graph dengan relasi dependency.
5. Menjalankan validasi dan mengirim catalog terkompilasi kembali ke agent.

Semua nilai yang akan di-dekripsi dari hiera-eyaml didekripsi pada tahap 3 — agent hanya menerima hasil akhir, bukan kunci.

puppet catalog compile --environment production web01.example.com
puppet node clean web01.example.com

#Error Katalog yang Umum

Kesalahan kompilasi membuat run gagal sebelum catalog terkirim. Yang paling sering ditemui:

Deklarasi duplikat — dua resource dengan tipe dan title yang sama dalam satu scope:

file { '/etc/motd':
  ensure  => file,
  content => 'pesan pertama',
}
 
file { '/etc/motd':
  ensure => present,
}

Puppet mengidentifikasi resource lewat pasangan tipe dan title. Mendeklarasikan File['/etc/motd'] dua kali memunculkan error Duplicate declaration. Solusinya selalu menulis satu deklarasi, lalu merujuk resource itu lewat title di relasi.

Kelas tidak ditemukan — terjadi saat include memakai nama class yang tidak ada di modulepath, atau module belum diinstall:

puppet module install puppetlabs-nginx
puppet module list

Variabel tidak terdefinisi — referensi ke variabel yang belum di-set menghasilkan Undefined variable. Cek penulisan key facts, misalnya $facts['os']['family'], sudah tepat.

Sintaks salah — titik koma yang hilang di akhir deklarasi resource, atau kurung yang tidak seimbang. Pesan error Puppet biasanya menyebut nomor baris tepat di manifest.

#Penutup

Catalog adalah jembatan antara keinginan dan realisasi — dan relasi antar resource yang membuatnya deterministik.

• Catalog adalah hasil kompilasi manifest plus data Hiera yang siap dijalankan agent.
• before dan require mengatur urutan, notify dan subscribe menambahkan event seperti restart service.
• Chaining panah -> dan ~> menulis rangkaian relasi secara linear dan mudah dibaca.
• Server mengkompilasi dan mendekripsi data, agent hanya menerima catalog jadi.
• Error umum katalog adalah deklarasi duplikat, class hilang, variabel tak terdefinisi, dan sintaks salah.

Di episode 9, kalian akan menambahkan otak di balik layar: PuppetDB, database yang menyimpan facts, catalog, dan report tiap run, membuka query lintas node, serta menyalurkan daya exported resources — resource yang lahir di satu node dan dikumpulkan di node lain untuk memandu monitoring dan load balancer. Sampai jumpa!