Belajar Chef - Test Kitchen & Integration Testing

#Pendahuluan

Di episode 17 kalian sudah membungkus aplikasi menjadi artifact Habitat dengan hab pkg build. Namun membangun artifact hanyalah separuh cerita — sebelum cookbook kalian menyentuh node produksi, ia harus terbukti bekerja di lingkungan yang terkontrol. Di episode 15 kita sempat menyinggung test-driven infrastructure; episode 18 ini mengangkatnya menjadi praktik nyata dengan Test Kitchen: alat baku Chef Workstation untuk menguji cookbook terhadap instance nyata, mulai dari container lokal hingga node cloud.

#Apa Itu Test Kitchen

Test Kitchen adalah framework pengujian yang memutar instance sungguhan (bukan mock), menerapkan cookbook ke instance itu (converge), lalu memverifikasi hasilnya (verify). Siklusnya sengaja dibuat pendek agar feedback cepat:

• create — memutar instance dari driver (container, VM, atau node cloud).
• converge — menjalankan chef-client dengan cookbook yang sedang diuji.
• verify — menjalankan verifier (InSpec) untuk memeriksa state yang dihasilkan.
• destroy — menghapus instance, memastikan lingkungan bersih.

Pola ini mengubah cara kalian bekerja: alih-alih "tulis cookbook lalu coba manual", kalian menulis harapan lebih dulu dan membiarkan Kitchen membuktikannya berulang kali. Kitchen sudah tersedia di Chef Workstation, jadi kitchen version langsung bisa dipakai.

#Anatomi kitchen.yml

Semua perilaku Kitchen diatur lewat file kitchen.yml di root cookbook. File ini mendefinisikan tiga bagian besar: driver (tempat instance berjalan), provisioner (cara cookbook diterapkan), dan suites (skenario yang diuji).

---
driver:
  name: docker
 
provisioner:
  name: chef_zero
 
platforms:
  - name: ubuntu-22.04
    driver_config:
      image: dokken/ubuntu-22.04
 
suites:
  - name: default
    run_list:
      - recipe[webserver::default]
    verifier:
      name: inspec

Mari bedah bagian per bagian. Driver docker memakai image dokken/ubuntu-22.04 yang dirancang khusus untuk Kitchen — ramping dan tanpa systemd bawaan. Provisioner chef_zero memakai cookbook langsung dari direktori kerja tanpa perlu server jarak jauh, dan suite default menetapkan run_list yang menunjuk ke recipe yang diuji. Verifier inspec memberi tahu Kitchen verifikasi apa yang dipakai setelah converge.

#Memilih Driver

Driver menentukan di mana instance dijalankan, dan pilihan ini berdampak pada kecepatan maupun kemiripan dengan produksi:

Ubah driver cukup dengan mengganti nilai driver.name dan menyesuaikan driver_config. Untuk cloud, Kitchen memakai plugin seperti kitchen-ec2 yang membaca kredensial dari environment — kredensial tidak boleh ditulis di kitchen.yml.

#Siklus Converge, Verify, Destroy

Perintah utama Kitchen mengikuti siklus dasar. Untuk mencontohkan, mari jalankan instance dan menerapkan cookbook:

kitchen create
kitchen converge webserver-default
kitchen list

kitchen verify webserver-default

kitchen list menampilkan state semua instance (created, converged, atau destroyed). Setelah converge, verifikasi dengan InSpec. Jika verifikasi gagal, perbaiki cookbook dan jalankan kitchen converge && kitchen verify lagi — iterasi ini adalah denyut nadi pengembangan berbasis test. Setelah puas, bersihkan lingkungan:

kitchen destroy

Untuk satu putaran penuh dalam satu perintah, gunakan kitchen test yang menjalankan create, converge, verify, dan destroy secara berurutan — persis alur yang diinginkan CI.

#Menulis Verifikasi InSpec di dalam Kitchen

Verifikasi ditulis sebagai profil InSpec sederhana di direktori test/integration/<nama-suite>/. Resource InSpec bekerja deklaratif: describe memeriksa suatu properti dan it menegaskan ekspektasinya.

describe package('nginx') do
  it { should be_installed }
end
 
describe service('nginx') do
  it { should be_enabled }
  it { should be_running }
end
 
describe port(80) do
  it { should be_listening }
end
 
describe file('/etc/nginx/nginx.conf') do
  it { should exist }
  it { should be_owned_by 'root' }
end

Verifikasi ini membaca fakta langsung dari instance hasil converge — bukan dari janji di cookbook. Jika recipe hanya memasang paket tanpa menyalakan service, verifikasi should be_running akan gagal dan memaksa kalian memperbaikinya. Itulah tujuan sebenarnya: harapan ditulis lebih dulu, kode dipaksa memenuhinya.

#Integrasi dengan CI

Kekuatan penuh Kitchen muncul saat ia berjalan otomatis di CI: setiap pull request yang mengubah cookbook diuji terhadap instance nyata sebelum di-review. Dengan driver Docker, tidak perlu mesin khusus — runner cukup menjalankan perintah standar.

name: test-cookbook
 
on:
  pull_request:
 
jobs:
  kitchen:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Chef Workstation
        run: |
          curl -L https://omnitruck.chef.io/install.sh | sudo bash -s -- -P chef-workstation
      - name: Test Kitchen
        run: kitchen test

Untuk Jenkins, polanya sama — job dijalankan oleh agent dengan Docker dan Chef Workstation terpasang, lalu mengeksekusi kitchen test sebagai langkah terakhir. Kunci sukses di CI: pastikan kitchen.yml tidak bergantung pada path lokal, dan beri image Docker yang eksplisit agar deterministik.

#Penutup

Episode 18 menutup siklus pengembangan dengan Test Kitchen sebagai jembatan antara penulisan dan pembuktian: kitchen.yml sebagai kontrak tiga bagian, driver sebagai pilihan medan tempur, alur converge-verify-destroy sebagai ritme kerja, verifikasi InSpec sebagai hakim, dan CI sebagai penjaga permanen.

Inti yang harus dibawa pulang:

• kitchen.yml adalah satu-satunya sumber kebenaran konfigurasi pengujian — driver, provisioner, dan suites dibaca dari sini.
• Siklus pendek — create, converge, verify, destroy — meminimalkan jarak antara perubahan dan umpan balik.
• Verifikasi InSpec menulis harapan lebih dulu dan membuat cookbook membuktikan janjinya pada instance nyata.
• CI terintegrasi mengubah pengujian dari kebiasaan individu menjadi gerbang yang tidak bisa dilewati pull request.

Di episode 19 kita akan berpindah dari "bagaimana menguji" ke "bagaimana mengoperasikan": performance & troubleshooting — menganalisis chef-client run, penjadwalan dengan systemd timer atau cron, caching, dan solusi untuk masalah-masalah umum di lapangan. Sampai jumpa!