Belajar Chef - Performance & Troubleshooting

#Pendahuluan

Di episode 18 kalian sudah menguji cookbook dengan Test Kitchen dan memastikan ia bekerja di lingkungan terkontrol. Namun di dunia nyata, cookbook tidak berjalan sekali — ia berjalan terus-menerus di ratusan node, mengikuti jadwal, dan kadang gagal dengan cara yang tidak muncul di CI. Episode 19 membekali kalian dua keterampilan yang paling sering dipakai di lapangan: menganalisis performa run dan memecahkan masalah ketika sesuatu tidak berjalan seperti harapan.

#Anatomi Chef Client Run

Setiap run chef-client melewati fase yang bisa dibayangkan sebagai lintasan:

1. Ohai mengumpulkan fakta node (OS, memori, network).
2. Chef mengunduh cookbook dan mengevaluasi run_list.
3. Recipe di-compile menjadi koleksi resource.
4. Resource dikonvergensikan — diterapkan ke node.
5. Laporan dikirim ke server atau handler.

Sebagian besar waktu dihabiskan pada fase compile dan konvergen. Jika sebuah run melambat, pertanyaan pertamanya selalu: fase mana yang memakan waktu? Jawabannya ada di log.

#Menganalisis Run dengan Log Debug

Log default chef-client hanya menampilkan ringkasan. Untuk membedah setiap langkah, jalankan dengan level debug:

chef-client -l debug

Keluaran debug memperlihatkan setiap resource yang dievaluasi, keputusan idempotency-nya, dan alasan di balik aksi yang diambil. Kombinasi dengan interval menjadikannya berguna untuk run terjadwal:

chef-client -l debug -i 3600

Parameter -i menetapkan interval dalam detik — nilai 3600 berarti chef-client berjalan setiap jam. Dalam mode ini chef-client tetap di memori; lebih hemat daripada menjalankan proses baru setiap kali karena cookbook, fakta Ohai, dan koneksi server di-cache.

#Mode Why-Run: Mencoba Tanpa Mengubah

Sebelum run sungguhan, -W (why-run) memperlihatkan apa yang akan dilakukan chef-client tanpa benar-benar menerapkannya:

chef-client -W --runlist 'recipe[webserver::default]'

Why-run adalah alat terbaik untuk menguji cookbook baru di node yang sudah berjalan. Jika sebuah resource non-idempotent, why-run akan menampilkannya — resource itu selalu "mau berubah" meskipun state sudah benar. Kejadian tersebut adalah sinyal merah pertama dalam audit performa.

#Penjadwalan: systemd Timer vs Cron

Chef-client menyediakan unit chef-client.service dan chef-client.timer yang bisa diaktifkan langsung di sistem Linux:

systemctl enable --now chef-client.timer
systemctl list-timers | grep chef

0 */2 * * * /usr/bin/chef-client -j /etc/chef/run_list.json > /dev/null

Timer systemd unggul karena bisa menyalakan service tepat waktu, mengejar run yang terlewat, dan punya log terpusat lewat journald. Untuk kebutuhan sederhana, cron juga berfungsi. Jadwal yang umum di produksi: interval 15–30 menit untuk node aplikasi, dan jeda lebih panjang untuk node batch. Lebih penting dari angka pastinya adalah konsistensi — run yang tidak pernah terjadi adalah konfigurasi yang tidak pernah dikonvergensikan.

#Caching untuk Performa

Chef-client melakukan beberapa bentuk caching yang bisa dikendalikan:

• Fakta Ohai di-cache untuk menghindari pemindaian ulang perangkat setiap run.
• Cookbook di-cache per versi di node, sehingga tidak diunduh ulang jika tidak berubah.
• Paket di-cache oleh package manager (apt/dnf) selama resource memakai versi yang sama.

Resource remote_file juga mendukung properti use_conditional_get dan use_etag agar file yang tidak berubah tidak diunduh ulang:

remote_file '/opt/tools/tool.tar.gz' do
  source 'https://cdn.example.com/tool.tar.gz'
  owner 'root'
  mode '0644'
  use_conditional_get true
end

Hindari mematikan caching tanpa alasan — node yang re-converge setiap run dengan download penuh adalah pemborosan bandwidth dan waktu.

#Troubleshooting Umum

Pengalaman di lapangan menunjukkan lima masalah yang mendominasi. Mari bahas satu per satu.

#Cookbook Tidak Ter-Upload

Gejala: run gagal dengan pesan cookbook tidak ditemukan. Penyebab: cookbook di server lebih lama daripada versi di workstation. Solusinya:

knife cookbook upload webserver
knife cookbook list

Biasakan mengupload setelah setiap perubahan yang akan dirilis, dan jangan lupa memeriksa versi cookbook di server dengan knife cookbook show webserver.

#Run List Salah

Gejala: node tidak mendapatkan konfigurasi yang diharapkan, padahal recipe sepertinya sudah ditulis. Penyebab: run_list menunjuk ke recipe yang salah atau tidak lengkap. Periksa apa yang sebenarnya dijalankan node:

knife node show web-01 -a run_list

Perbaiki dengan memperbarui run_list node. Selalu verifikasi run_list setelah bootstrap, karena kesalahan di sini diam-diam membuat node "terlihat sehat" padahal tidak diatur.

#Authentication Error

Gejala: Failed to authenticate atau error SSL. Penyebab: client key hilang atau sudah di-rotate, atau fingerprint server berubah. Periksa kredensial di /etc/chef/client.pem, validasi koneksi dengan knife ssl check, dan pastikan certificate authority yang benar ada di /etc/chef/trusted_certs. Jika node pernah di-rebuild, client key-nya harus dibuat ulang dan di-registrasi ulang ke Infra Server.

#Resource Tidak Idempoten

Gejala: why-run selalu menunjukkan perubahan, atau run selalu menandai "updated" padahal state sudah benar. Penyebab: action atau properti resource tidak memanfaatkan idempotency bawaan. Contoh klasik — menulis file yang kontennya ditimpa tanpa pengecekan. Solusinya adalah memakai resource yang deklaratif:

template '/etc/nginx/nginx.conf' do
  source 'nginx.conf.erb'
  mode '0644'
  notifies :reload, 'service[nginx]'
end

Resource template hanya menulis ulang file jika isi berubah. Gunakan execute dengan properti not_if atau only_if untuk perintah yang hanya boleh berjalan dalam kondisi tertentu, agar tidak dieksekusi ulang tanpa perlu.

#Dependency Conflict

Gejala: run gagal karena versi cookbook saling bertabrakan, biasanya pada metadata.rb yang menuntut depends dengan constraint terlalu kaku. Solusi: gunakan constraint versi yang longgar, misalnya menuntut versi minimum saja, dan lebih baik lagi — alihkan ke Policyfile yang mengunci seluruh pohon dependensi dalam lockfile. Konflik yang muncul di banyak cookbook adalah tanda untuk berinvestasi pada Policyfile sejak awal.

#Penutup

Episode 19 menutup sisi operasional dengan kemampuan membaca run secara presisi: log debug sebagai kamera slow-motion, why-run sebagai uji tanpa risiko, systemd timer dan cron sebagai konduktor jadwal, caching sebagai penghemat biaya, dan katalog troubleshooting sebagai kit pertolongan pertama.

Inti yang harus dibawa pulang:

• Analisis dimulai dari fase — tentukan dulu apakah lambatnya di Ohai, compile, atau konvergen.
• Why-run adalah jaring pengaman — jalankan chef-client -W sebelum run sungguhan pada node yang sudah ada.
• Penjadwalan butuh konsistensi — chef-client yang tidak pernah dijalankan tidak mengkonvergensikan apa pun.
• Kebanyakan kegagalan sudah berpola — upload, run list, autentikasi, idempotency, dan dependensi; kenali gejalanya, terapkan solusinya.

Di episode 20 kita akan melihat fitur stabil terbaru: Chef Infra Client 19 yang dibangun di atas Habitat, standard licensing, Ruby 3.4, helper cloud oci?, dan pembaruan Infra Server 15 dengan Valkey serta PostgreSQL 14. Sampai jumpa!