Belajar Puppet - PuppetDB

#Pendahuluan

Di episode 8 kalian melihat bagaimana catalog dikompilasi dan diterapkan. Tapi semua informasi itu — facts, catalog, dan report tiap run — mengalir begitu saja dan hilang. Di episode 9 kita menjadikannya aset dengan PuppetDB, database yang menyimpan seluruh data run dan membuka kemampuan tanya-jawab lintas node, termasuk exported resources yang membuat satu node bisa "menitipkan" konfigurasi untuk node lain.

PuppetDB mengubah Puppet dari sekadar penerap konfigurasi menjadi sumber kebenaran tentang kondisi infrastruktur secara real-time.

#Apa yang Disimpan PuppetDB

PuppetDB menyimpan tiga jenis data utama:

Setiap data punya timestamp sehingga kalian bisa melihat riwayat, bukan hanya kondisi terakhir. Node yang lama tidak check-in akan tampak dari facts yang basi.

Integrasi dimulai dengan mengaktifkan storeconfigs di puppetserver dan mengarahkannya ke PuppetDB:

sudo puppet config set storeconfigs true --section master
sudo puppet config set storeconfigs_backend puppetdb --section master

server: puppetdb.example.com
port: 8081

#Query dengan puppet query

Cara paling nyaman bertanya adalah perintah puppet query, yang tersedia lewat plugin puppetdb:

puppet query "nodes[certname] { facts.os.family = 'RedHat' }"
puppet query "facts[certname, value] { name = 'memorysize_mb' }"
puppet query "resources[certname, title] { type = 'File' and title = '/etc/motd' }"

Puppet Query Language (PQL) menyerupai SQL: entitas seperti nodes, facts, dan resources, kolom yang dipilih dalam kurung siku, lalu filter di dalam blok. Contoh pertama mengembalikan semua certname node berbasis RedHat.

Query juga bisa dikombinasikan dengan logika and, or, dan not, serta pencocokan sebagian dengan ~:

puppet query "nodes[certname] { certname ~ 'web' and facts.os.name = 'Ubuntu' }"

#PuppetDB API Langsung

Di balik puppet query ada REST API di endpoint /pdb/query/v4. Kalian bisa memanggilnya langsung dengan curl — berguna untuk integrasi ke tool lain:

curl -s -X POST https://puppetdb.example.com/pdb/query/v4 \
  -H "Content-Type: application/json" \
  -d '{"query": "nodes[certname] { deactivated = null }"}'

Respon dikembalikan sebagai array JSON:

[
  {
    "certname": "web01.example.com",
    "deactivated": null,
    "catalog_timestamp": "2026-08-03T09:12:00.000Z",
    "facts_timestamp": "2026-08-03T09:10:00.000Z",
    "report_timestamp": "2026-08-03T09:12:00.000Z"
  }
]

Endpoint API dikelompokkan berdasarkan entitas: /pdb/query/v4/nodes, /pdb/query/v4/facts, /pdb/query/v4/resources, /pdb/query/v4/reports, dan /pdb/query/v4/events. Semua mendukung format query yang sama.

#Exported Resources

Exported resources adalah fitur yang memungkinkan satu node men-declare resource untuk dipakai node lain. Di manifest, resource yang di-export ditandai dengan dua karakter @:

@@nagios_host { $facts['networking']['fqdn']:
  address => $facts['networking']['ip'],
  target  => "/etc/nagios/conf.d/${facts['networking']['fqdn']}.cfg",
}

Saat node web dijalankan, resource dengan @@ tidak langsung diterapkan di node itu. Sebaliknya, catalog-nya disimpan ke PuppetDB — lengkap dengan facts yang menyertainya.

Resource yang di-export kemudian dikumpulkan di node lain dengan collector <<| |>>:

Nagios_host <<| |>>

Semua nagios_host dari seluruh node akan diterapkan ke node ini. Filter berdasarkan tag atau facts mempersempit koleksi:

File <<| tag == 'load-balancer-backend' |>>

#Studi Kasus: Load Balancer yang Mengikuti Realita

Contoh paling nyata exported resources adalah load balancer yang selalu tahu backend-nya. Setiap node aplikasi mengekspor konfigurasinya sendiri:

@@file { "/etc/haproxy/backends/${facts['networking']['fqdn']}.cfg":
  ensure  => file,
  content => "server ${facts['networking']['fqdn']} ${facts['networking']['ip']}:8080 check\n",
  tag     => 'haproxy-backend',
}

Sementara node load balancer mengumpulkannya:

class profile::haproxy {
  package { 'haproxy': ensure => installed }
 
  file { '/etc/haproxy/backends':
    ensure  => directory,
    recurse => true,
    purge   => true,
  }
 
  File <<| tag == 'haproxy-backend' |>>
 
  service { 'haproxy':
    ensure    => running,
    enable    => true,
    subscribe => File['/etc/haproxy/backends'],
  }
}

Saat ada node aplikasi baru muncul, ia otomatis mengekspor backend-nya, PuppetDB mencatatnya, dan node load balancer pada run berikutnya mengambil konfigurasi baru — tanpa satu pun intervensi manual. Begitu node dimatikan dan catalog lama kedaluwarsa, backend-nya ikut lenyap dari kumpulan.

#Penutup

PuppetDB mengubah data run menjadi sumber kebenaran yang bisa dipakai lintas node.

• PuppetDB menyimpan facts, catalog, dan reports lengkap dengan timestamp tiap run.
• puppet query memberi bahasa query seperti SQL untuk menemukan node, facts, dan resources.
• PuppetDB API di /pdb/query/v4 bisa dipanggil langsung oleh tool eksternal.
• Exported resources @@ + collector <<| |>> menyalurkan konfigurasi antar node secara otomatis.
• Monitoring dan load balancer adalah kasus pakai paling umum dari pola ini.

Di episode 10, kalian naik ke produk komersialnya: Puppet Enterprise, mengenal Console untuk manajemen node, node groups dan classifier, RBAC, reporting, hingga menjalankan Puppet Tasks dan Plans untuk aksi ad-hoc yang ter-orchestrasi dari satu tempat. Sampai jumpa!