Belajar Chef - Production-Ready Architecture

#Pendahuluan

Di episode 20 kalian melihat fondasi baru Infra Client 19 dan Infra Server 15.10. Sekarang tibalah saatnya merangkai seluruh komponen yang sudah kalian pelajari selama 20 episode menjadi satu kesatuan yang siap produksi. Episode 21 bukan tentang fitur baru, melainkan tentang arsitektur: bagaimana Workstation, Infra Server, node, Policyfile, Automate, dan pipeline CI/CD duduk bersama, dan bagaimana arsitektur itu dijaga tetap hidup lewat monitoring, backup, dan disaster recovery.

#Peta Arsitektur Production

Arsitektur Chef yang sehat memiliki tiga lapis:

• Workstation — tempat kode ditulis, diuji, dan dirilis oleh engineer.
• Infra Server — pusat registry cookbook, data node, dan kebijakan; di produksi ia berjalan high-availability dengan failover.
• Nodes — mesin yang menjalankan chef-client secara berkala dan menarik kebijakan dari server.

Alurnya: engineer mengerjakan cookbook di Workstation, mengupload ke Infra Server, node menarik kebijakan lewat run, dan hasil run dikirim balik ke Automate untuk visibilitas. Model ini pull-based (dibahas di episode 1): node yang memulai komunikasi, sehingga arsitektur ini bekerja di belakang NAT tanpa perlu koneksi masuk ke node.

#Workstation dan Infra Server HA

Workstation adalah mesin pengembangan — tidak perlu spesifikasi tinggi, tapi wajib menjaga kebersihan konfigurasi. Kredensial client.pem untuk Infra Server disimpan di ~/.chef dan tidak boleh ikut di-commit. Untuk pengelolaan multi-engineer, selaraskan konvensi: satu repository cookbook bersama, review via pull request, dan rilis lewat Policyfile.

Infra Server HA berarti menjalankan beberapa node server (biasanya tiga) dengan komponen aktif-pasif atau multi-primary, plus load balancer di depan. Dengan chef-server-ctl, konfigurasi HA dikelola lewat file konfigurasi bersama:

chef-server-ctl status
chef-server-ctl ring-list

Tujuannya bukan hanya toleransi kegagalan — HA memberi jendela maintenance: satu node server bisa di-upgrade sementara node lain melayani. Inilah yang dimaksud arsitektur production-grade: kegagalan komponen tidak sama dengan kegagalan layanan.

#Policyfile di Production

Di episode 10 kalian berkenalan dengan Policyfile. Di arsitektur production, Policyfile adalah kunci rilis deterministik — ia mengunci run_list dan seluruh pohon dependensi dalam lockfile, sehingga node dev, staging, dan production menjalankan kebijakan yang benar-benar sama:

name 'webserver'
run_list 'webserver::default', 'compliance::hardening'
 
cookbook 'webserver', path: 'cookbooks/webserver'
cookbook 'compliance', path: 'cookbooks/compliance'

Rilis ke environment memakai policy group, bukan mutasi cookbook di server:

chef update policyfile/Policyfile.rb
chef push production policyfile/Policyfile.lock.json

Setiap push menghasilkan versi lockfile yang tercatat — jejak audit yang jelas tentang kode apa yang berjalan di environment mana. Jika regresi muncul, rollback cukup dengan mem-push versi lockfile sebelumnya. Itulah kekuatan Policyfile: rilis bisa dibatalkan dengan satu perintah, bukan dengan menebak versi cookbook.

#Automate untuk Compliance dan Visibilitas

Chef Automate (episode 12) adalah lapisan yang mengubah run data menjadi keputusan. Di arsitektur production ia berperan ganda: compliance scanner dan dashboard visibilitas. Node mengirim hasil run dan hasil scan InSpec ke Automate lewat data collection service; Automate menampilkan status node, kepatuhan terhadap profil, dan alarm saat run gagal.

{
  "name": "web-01",
  "chef_environment": "production",
  "run_list": ["recipe[webserver::default]"]
}

Agar node mengirim data ke Automate, konfigurasi data collector dipasang pada node — biasanya lewat atribut yang di-set dari cookbook. Hasilnya: satu dasbor yang menjawab "apakah node saya patuh terhadap kebijakan?" tanpa harus login satu per satu.

#Bootstrap Flow

Node baru masuk ke fleck lewat bootstrap: satu perintah dari Workstation (atau CI) yang menginstal chef-client, mendaftarkan node ke Infra Server, dan menjalankan run pertama:

knife bootstrap 203.0.113.10 \
  -N web-01 \
  -E production \
  -r 'recipe[webserver::default]'

Di produksi, bootstrap jarang dilakukan manual. Ia dipicu otomatis oleh pipeline: saat instance cloud dibuat (episode 14), user-data menjalankan script bootstrap; saat image baru lahir, chef-client sudah termuat di dalamnya. Yang penting konsisten: setiap node terdaftar dengan nama unik, environment yang benar, dan run_list yang tidak menyimpang dari kebijakan.

#Pipeline CI/CD: Test Kitchen ke InSpec ke Automate

Pipeline production-grade memformalkan alur yang sudah kalian kenal di episode 18:

• Commit memicu Test Kitchen terhadap perubahan cookbook.
• Lulus berarti cookbook di-push ke environment staging lewat Policyfile.
• InSpec menscan staging untuk memastikan profil compliance terpenuhi.
• Lolos berarti rilis ke production, dan hasilnya terpantau di Automate.

steps:
  - name: kitchen test
    command: kitchen test
  - name: push policy to staging
    command: chef push staging policyfile/Policyfile.lock.json
  - name: inspec scan staging
    command: inspec exec profiles/hardening -t ssh://staging
  - name: promote to production
    command: chef push production policyfile/Policyfile.lock.json

Setiap gerbang di pipeline adalah keputusan yang bisa diaudit. Tidak ada cookbook yang mencapai production tanpa melewati Kitchen, tanpa scan InSpec, dan tanpa jejak rilis yang tercatat.

#Monitoring Cookbook Run dan Backup DR

Run chef-client yang berjalan sendiri bukan berarti sehat. Monitor status run terakhir setiap node — gagal, lambat, atau tidak pernah muncul sama sekali:

• Automate menampilkan riwayat run per node dan profil kepatuhan.
• Alert memicu saat node tidak melapor dalam interval tertentu — tanda run gagal atau node mati.
• Ekspor metrik run (durasi, jumlah updated) ke sistem monitoring eksternal untuk tren jangka panjang.

Backup dan disaster recovery berlapis tiga:

• Infra Server: backup penuh dengan chef-server-ctl backup (episode 9), disimpan off-site, dan diuji pemulihannya secara berkala.
• Data bag dan secrets: pencadangan terenkripsi, sebaiknya lewat vault — tidak pernah di repository.
• Node state: node bisa di-rebuild dari kebijakan; data node disimpan di server dan tercakup dalam backup server.

Latihan pemulihan rutin adalah bagian dari arsitektur — backup yang tidak pernah diuji adalah harapan, bukan rencana.

#Penutup

Episode 21 menyusun arsitektur production dari komponen yang sudah kalian pelajari satu per satu: Workstation sebagai sumber perubahan, Infra Server HA sebagai pusat kebenaran, node sebagai titik konvergensi, Policyfile sebagai kunci determinisme, Automate sebagai mata dan pengawas, bootstrap sebagai pintu masuk, pipeline sebagai gerbang, dan backup sebagai jaring pengaman terakhir.

Inti yang harus dibawa pulang:

• Arsitektur adalah tiga lapis — Workstation, Infra Server, dan node — dengan model pull-based yang bekerja di balik NAT.
• Policyfile membuat rilis bisa dibatalkan — setiap environment terkunci pada versi lockfile yang bisa di-push ulang.
• Automate menjadikan compliance sebagai data — bukan aktivitas manual per node.
• Bootstrap dan pipeline menghilangkan pekerjaan manual — node lahir dari kode, bukan dari tangan.
• Backup tanpa latihan pemulihan bukan rencana — DR harus diuji secara berkala.

Di episode 22 — episode terakhir — kita akan melihat keluar dan ke depan: ekosistem alternatif dan refleksi akhir — membandingkan Chef dengan Ansible, Puppet, SaltStack, serta Terraform dan Pulumi, lalu merangkum seluruh perjalanan dari episode 0 sampai 21. Sampai jumpa!