Strategi Uji PXE Boot agar Perubahan DHCP Tak Lolos ke Produksi

Strategi uji PXE boot yang baik harus menangkap regresi sebelum perubahan DHCP, TFTP, HTTP boot, atau menu boot menyentuh jaringan produksi. Masalahnya, alur boot via network melibatkan banyak komponen yang saling tergantung: firmware klien, DHCP options, file bootloader, layanan TFTP atau HTTP, kernel/initramfs, sampai konfigurasi jaringan di fase early boot.

Jika Anda mengelola server PXE/HTTP boot untuk provisioning bare metal, instalasi OS, rescue image, atau boot environment internal, pendekatan yang paling aman adalah membangun test pyramid yang sesuai dengan karakter alur boot. Bukan hanya menguji apakah service hidup, tetapi memverifikasi bahwa konfigurasi yang berubah masih menghasilkan boot yang benar, stabil, dan dapat didiagnosis saat gagal.

Artikel ini membahas strategi praktis yang bisa diterapkan pada implementasi PXE/HTTP boot modern, termasuk yang terinspirasi oleh pendekatan sistem provisioning seperti Bootimus: unit test untuk parser dan generator konfigurasi, integration test dengan container atau VM, smoke test untuk image boot, dan verifikasi end-to-end di CI sebelum rilis.

Mengapa perubahan kecil di DHCP sering berbahaya

Pada stack PXE boot, perubahan yang terlihat sepele sering berdampak besar karena DHCP menjadi titik keputusan awal. Salah konfigurasi satu opsi bisa mengarahkan klien ke bootloader yang salah, protokol transfer yang tidak didukung firmware, atau URL/image yang tidak cocok dengan arsitektur mesin.

Contoh regresi yang umum:

Mapping arsitektur salah: UEFI x86_64 mendapat bootloader untuk BIOS lama.
Next-server atau filename keliru: klien mendapatkan path file yang valid secara sintaks, tetapi tidak tersedia di TFTP/HTTP.
Perubahan menu boot: entri default berubah, label salah, atau parameter kernel hilang.
Perubahan jaringan early boot: image boot berhasil diunduh, tetapi initramfs gagal memperoleh IP atau route.
Perpindahan TFTP ke HTTP boot: firmware tertentu mendukung subset perilaku yang berbeda, sehingga alur yang lolos di VM belum tentu lolos di perangkat nyata.

Karena itu, pengujian tidak boleh berhenti di level “service start tanpa error”. Yang perlu diuji adalah kontrak antar-komponen: input DHCP, output config, keberadaan artefak boot, dan perilaku klien saat benar-benar mencoba boot.

Test pyramid yang relevan untuk PXE/HTTP boot

Untuk workflow boot jaringan, piramida pengujian yang efektif biasanya dibagi menjadi empat lapisan:

Unit test untuk parser, validator, dan generator konfigurasi.
Integration test untuk interaksi DHCP, TFTP/HTTP, file layout, dan menu boot.
Smoke test untuk memastikan image benar-benar bisa mulai boot.
End-to-end test di CI menggunakan VM atau host uji untuk memverifikasi alur penuh.

Semakin ke atas, pengujian makin mahal dan lambat, jadi tidak semua kasus harus diuji end-to-end. Kuncinya adalah mendorong sebanyak mungkin validasi ke lapisan bawah tanpa kehilangan cakupan risiko nyata.

1) Unit test parser dan generator konfigurasi

Lapisan ini paling murah dan paling cepat. Tujuannya menangkap kesalahan logika sebelum layanan apa pun dijalankan. Fokuskan pada:

Parser file inventori host atau group.
Validator opsi DHCP dan menu boot.
Generator konfigurasi dhcpd, dnsmasq, iPXE script, PXELINUX/GRUB menu, atau mapping URL image.
Resolver arsitektur klien dan firmware mode (BIOS/UEFI).

Uji yang baik bukan hanya memeriksa string output, tetapi juga aturan bisnis. Misalnya, jika arsitektur UEFI terdeteksi, generator tidak boleh mengeluarkan file boot BIOS. Jika image HTTP boot dipilih, URL harus absolut dan path harus tersedia pada root yang benar.

Contoh pseudo-test untuk generator menu:

def test_uefi_client_gets_correct_boot_artifact():
    host = {
        "arch": "x86_64",
        "firmware": "uefi",
        "profile": "rescue"
    }

    cfg = render_boot_config(host)

    assert "ipxe.efi" in cfg.bootloader
    assert "pxelinux.0" not in cfg.bootloader
    assert cfg.kernel_url.endswith("/images/rescue/vmlinuz")
    assert "initrd=" in cfg.kernel_args

Mengapa lapisan ini penting? Karena sebagian besar regresi konfigurasi adalah masalah deterministik: kondisi if/else yang salah, nilai default berubah, penggabungan template rusak, atau input inventori tidak tervalidasi. Semua itu sebaiknya tertangkap jauh sebelum VM dinyalakan.

2) Integration test dengan container atau VM

Setelah generator konfigurasi lolos, langkah berikutnya adalah memastikan komponen server benar-benar dapat bekerja bersama. Integration test bisa dijalankan dengan dua pendekatan:

Container untuk menguji rendering config, file serving, dan perilaku endpoint HTTP/TFTP secara terbatas.
VM untuk menguji alur DHCP sampai bootloader secara lebih realistis.

Container cocok untuk menguji hal berikut:

Config DHCP valid secara sintaks.
Direktori TFTP atau document root HTTP berisi artefak yang dirujuk.
Template menu menghasilkan file yang bisa dibaca klien.
Endpoint health check dan static file merespons sesuai harapan.

Namun, container tidak cukup untuk memverifikasi firmware PXE/UEFI. Untuk itu, VM lebih relevan karena bisa mensimulasikan NIC virtual dan network boot sequence.

Contoh hal yang layak diuji di integration test:

Klien BIOS menerima filename berbeda dari klien UEFI.
Bootloader yang didaftarkan benar-benar tersedia di TFTP/HTTP.
Menu default mengarah ke kernel dan initramfs yang ada.
Kernel command line mengandung parameter jaringan yang diperlukan.

Catatan: jika Anda memakai HTTP boot, uji juga skenario file besar dan redirect. Beberapa firmware lebih sensitif terhadap variasi perilaku HTTP daripada klien OS penuh.

3) Smoke test image boot

Smoke test bertujuan menjawab pertanyaan sempit tetapi penting: “apakah image ini masih bisa mulai boot?” Anda tidak harus menyelesaikan instalasi OS penuh pada setiap perubahan DHCP, tetapi Anda perlu memastikan bahwa kernel dan initramfs bisa diunduh, dieksekusi, dan mencapai titik observasi tertentu.

Titik observasi yang umum dipakai:

VM berhasil memuat bootloader.
Kernel mulai berjalan.
Initramfs memperoleh IP.
Sebuah string log tertentu muncul di serial console.
Agent di early userspace melakukan callback ke endpoint test.

Pendekatan callback sering lebih andal daripada menebak dari timeout semata. Misalnya, image test ringan bisa menjalankan skrip early boot yang memanggil endpoint HTTP internal ketika jaringan sudah aktif. Jika callback diterima beserta metadata build/image, Anda tahu image benar-benar melewati fase penting.

4) End-to-end verification di CI

Lapisan terakhir memverifikasi jalur penuh: perubahan config di repository menghasilkan artefak baru, layanan test dijalankan, VM melakukan PXE/HTTP boot, dan pipeline memutuskan lulus atau gagal berdasarkan sinyal yang jelas.

End-to-end test tidak harus sangat banyak. Pilih skenario representatif yang memberi cakupan risiko terbesar:

BIOS + TFTP.
UEFI + HTTP boot.
Menu boot default.
Satu image rescue atau installer utama.
Satu skenario jaringan dengan DHCP normal.

Jika lingkungan Anda heterogen, tambahkan matriks minimum berdasarkan risiko nyata, bukan semua kombinasi yang mungkin. Misalnya, cukup satu test untuk tiap keluarga firmware yang memang dipakai di produksi.

Desain environment test yang tidak rapuh

Masalah terbesar pada pengujian boot workflow adalah flaky test: test kadang gagal bukan karena regresi, tetapi karena network timing, race condition, atau image terlalu berat. Supaya strategi uji PXE boot tetap berguna, environment test harus dirancang agar deterministik.

Isolasi dependensi jaringan

Jangan menguji terhadap jaringan bersama yang dipakai service lain. Gunakan network namespace, bridge virtual, atau segment terisolasi khusus CI agar:

Tidak ada DHCP server lain yang menjawab request.
Alamat IP test tidak bentrok.
Latency dan packet loss lebih terkendali.
Artefak test tidak bercampur dengan produksi.

Prinsip pentingnya adalah satu sumber kebenaran untuk tiap dependency. Jika test mengharapkan DHCP tertentu, pastikan hanya instance itulah yang aktif pada segmen test.

Gunakan fixture image yang kecil dan stabil

Jangan selalu memakai image produksi penuh untuk semua test. Untuk smoke test dan end-to-end, sediakan fixture image yang:

Ukurannya kecil agar boot lebih cepat.
Memiliki kernel/initramfs yang jarang berubah.
Mampu mencetak log yang mudah dikenali.
Bisa melakukan callback HTTP atau menulis marker ke serial console.

Dengan image fixture, Anda mengurangi sumber noise dari perubahan paket aplikasi, dependency OS, atau skrip provisioning yang tidak relevan dengan perubahan DHCP/TFTP/HTTP boot.

Atur timeout yang sehat, bukan agresif

Timeout terlalu pendek akan menghasilkan false negative. Timeout terlalu panjang akan memperlambat CI dan menyamarkan kegagalan. Pisahkan timeout berdasarkan fase:

DHCP lease timeout: cukup untuk beberapa retry.
Bootloader fetch timeout: sesuai ukuran file dan media penyajian.
Kernel/startup timeout: lebih longgar jika initramfs memuat modul jaringan.
Global test timeout: hard stop agar pipeline tidak menggantung.

Lebih baik mendefinisikan milestone dan timeout per milestone daripada satu timeout besar untuk seluruh boot sequence. Dengan begitu, saat gagal Anda tahu fase mana yang bermasalah.

Jangan menggantungkan hasil test pada teks log yang rapuh

Log parsing tetap berguna, tetapi jangan bergantung hanya pada string yang mudah berubah. Firmware, bootloader, atau kernel dapat mengubah format log antar-build. Kombinasikan beberapa sinyal:

Kode exit proses orchestrator.
Ketersediaan file/artefak yang diunduh.
Callback dari image fixture.
Serial console log untuk diagnosis.
Paket jaringan yang tertangkap pada fase gagal.

Contoh arsitektur pipeline pengujian

Berikut alur CI yang realistis untuk perubahan pada stack PXE/HTTP boot:

Lint dan validasi statis: cek format YAML/JSON/inventori, validasi template, dan schema config.
Unit test: uji parser, mapper arsitektur, generator menu, dan rule DHCP.
Build environment test: siapkan container/VM, mount artefak boot fixture, jalankan DHCP + HTTP/TFTP test.
Integration test: verifikasi file boot tersedia, endpoint merespons, config service dapat dimuat.
Smoke boot: boot VM, tunggu callback atau marker serial console.
End-to-end gate: tandai lulus hanya jika skenario inti berhasil untuk BIOS/UEFI yang dipilih.
Publish artifact dan promote: hanya jika semua gate hijau.

Contoh pseudo-konfigurasi pipeline:

stages:
  - validate
  - unit
  - integration
  - smoke
  - e2e

validate:
  run:
    - ./scripts/validate-config.sh
    - ./scripts/check-boot-artifacts.sh

unit:
  run:
    - pytest tests/unit

integration:
  run:
    - docker compose up -d dhcp http tftp
    - ./scripts/test-rendered-config.sh
    - ./scripts/test-artifact-availability.sh

smoke:
  run:
    - ./scripts/boot-vm-smoke.sh --firmware uefi --transport http

end_to_end:
  run:
    - ./scripts/boot-vm-e2e.sh --firmware bios --transport tftp
    - ./scripts/boot-vm-e2e.sh --firmware uefi --transport http

Nama tool dan script bisa berbeda, tetapi idenya sama: setiap lapisan memberi umpan balik yang cepat sebelum masuk ke test yang lebih mahal.

Apa yang perlu diuji pada DHCP, TFTP, HTTP boot, dan menu

DHCP

Untuk DHCP, fokus pada kontrak respons terhadap tipe klien:

Pilihan boot file berdasarkan BIOS/UEFI/arsitektur.
Next-server atau URL yang benar.
Classing vendor atau user class bila dipakai.
Lease dan network parameter minimum untuk early boot.

Kesalahan umum adalah menguji hanya satu tipe klien, padahal produksi punya campuran firmware.

TFTP

TFTP sederhana tetapi sensitif terhadap path dan permission. Uji:

Semua file yang dirujuk benar-benar ada.
Path relatif tidak rusak akibat perubahan struktur direktori.
Ukuran file masih masuk akal untuk skenario test Anda.
Service dapat membaca file dengan permission yang benar.

Jika Anda sedang memigrasikan sebagian alur dari TFTP ke HTTP, pastikan fallback behavior tidak membingungkan klien lama.

HTTP boot

Untuk HTTP boot, uji hal berikut:

URL absolut benar dan dapat diakses dari network test.
Content type tidak menjadi syarat implisit pada komponen tertentu.
Document root memuat kernel, initramfs, dan script tambahan.
Tidak ada redirect atau auth yang tidak didukung firmware klien.

Firmware UEFI HTTP boot biasanya lebih terbatas daripada klien Linux biasa, jadi jangan berasumsi semua perilaku HTTP akan sama.

Menu boot

Menu boot adalah sumber regresi yang sering diremehkan. Uji:

Label default masih benar.
Kernel command line tidak kehilangan parameter penting.
Nama image yang dirujuk sinkron dengan artefak di server.
Jika menu dibangkitkan dinamis, semua host profile menghasilkan entri valid.

Observability untuk diagnosis gagal boot

Tanpa observability, test PXE boot yang gagal hanya menghasilkan status timeout. Itu tidak cukup. Siapkan data diagnosis dari awal.

Kumpulkan log per fase

DHCP logs: request, offer, ack, identitas klien, dan bootfile yang dipilih.
TFTP/HTTP access logs: file apa yang diminta, status respons, byte transfer.
Serial console log VM: output bootloader, kernel, initramfs.
Packet capture: minimal untuk kasus gagal atau flaky.

Jika memungkinkan, simpan artefak log sebagai hasil pipeline agar bisa dibandingkan antar-build.

Tambahkan correlation ID atau metadata build

Masukkan ID build, nama image, atau hash konfigurasi ke:

Nama direktori artefak test.
Header callback dari image fixture.
Output log generator konfigurasi.

Tujuannya agar Anda bisa memastikan VM test benar-benar mem-boot artefak yang sedang diuji, bukan file lama yang tertinggal.

Rekam snapshot konfigurasi final

Banyak kegagalan berasal dari perbedaan antara template dan file final yang benar-benar dimuat service. Simpan snapshot dari:

Rendered DHCP config.
Rendered menu boot.
Daftar file yang diekspos via TFTP/HTTP.
Parameter VM test yang dipakai pada pipeline.

Ini sering mempercepat diagnosis dibanding membaca template mentah.

Sumber flaky test pada boot workflow

Flaky test pada PXE/HTTP boot biasanya berasal dari kombinasi faktor berikut:

DHCP race: ada responder lain pada network yang sama.
Resource contention: host CI kehabisan CPU atau I/O, sehingga VM lambat boot.
Image terlalu besar: fetch initramfs memakan waktu dan tidak stabil.
Timeout tidak proporsional: sukses di laptop, gagal di runner CI.
State bocor antar-test: lease lama, cache artefak lama, socket belum dibersihkan.
Dependensi eksternal: image atau script boot mengakses layanan di luar environment test.

Strategi mitigasinya:

Isolasi jaringan test.
Bersihkan state sebelum dan sesudah test.
Gunakan image fixture lokal.
Kurangi dependency internet atau service bersama.
Batasi paralelisme untuk test yang memakai resource network/VM yang sama.
Tambahkan retry hanya pada tahap setup yang benar-benar non-deterministik, bukan pada assertion utama.

Hindari retry buta pada test end-to-end. Jika test sering perlu retry, anggap itu bug pada environment atau observability, bukan solusi permanen.

Checklist rollback saat rilis perubahan PXE boot

Meski pengujian sudah baik, Anda tetap perlu rencana rollback. Pada sistem boot jaringan, rollback harus cepat karena dampaknya bisa langsung mengenai seluruh host baru atau host yang sedang reboot.

Checklist rollback

Simpan versi terakhir dari file DHCP, menu boot, dan mapping artefak yang diketahui stabil.
Versioning untuk kernel, initramfs, dan bootloader; hindari overwrite file in-place tanpa jejak.
Siapkan mekanisme revert yang tidak bergantung pada build ulang artefak.
Pastikan perubahan bisa dipromosikan bertahap ke segmen test, staging, lalu produksi.
Dokumentasikan indikator rollback: misalnya persentase host gagal boot, callback smoke test hilang, atau akses log menunjukkan 404 pada artefak inti.
Pastikan tim on-call tahu file mana yang harus dipulihkan lebih dulu: DHCP response, menu default, atau symlink artefak.

Praktik yang sangat membantu adalah menggunakan immutable artifacts: setiap rilis memiliki path unik, lalu produksi menunjuk ke versi aktif melalui referensi yang mudah dipindah balik.

Acceptance criteria sebelum perubahan dirilis

Sebelum perubahan DHCP atau boot stack dinyatakan siap produksi, tetapkan acceptance criteria yang jelas dan terukur.

Contoh acceptance criteria rilis

Semua unit test parser, validator, dan generator konfigurasi lulus.
Rendered config lolos validasi sintaks dan dapat dimuat oleh service test.
Semua artefak yang dirujuk oleh menu tersedia di TFTP/HTTP test.
Smoke test untuk image fixture berhasil pada skenario utama yang disyaratkan.
Minimal satu test end-to-end untuk BIOS/TFTP dan/atau UEFI/HTTP boot lulus sesuai lingkungan produksi.
Log DHCP, access log, dan serial console tersimpan sebagai artefak CI.
Tidak ada flaky failure yang belum dijelaskan pada tiga eksekusi terakhir pipeline.
Rollback plan terdokumentasi dan artefak versi sebelumnya masih tersedia.

Acceptance criteria semacam ini lebih berguna daripada pernyataan umum seperti “sudah dites di lab”, karena memaksa adanya bukti teknis yang dapat diulang.

Kesalahan umum yang sebaiknya dihindari

Menguji hanya happy path: padahal variasi firmware dan arsitektur adalah sumber bug utama.
Mengandalkan test manual: test manual berguna untuk investigasi, tetapi tidak cukup sebagai gate perubahan rutin.
Mencampur environment test dan produksi: hasilnya sulit dipercaya dan berisiko mengganggu host nyata.
Tidak menyimpan log/pcap: ketika gagal, Anda tidak tahu masalahnya ada di DHCP, file transfer, atau kernel boot.
Memakai image produksi penuh untuk semua test: lambat, rapuh, dan banyak noise.
Tidak menguji output final: hanya menguji template, bukan file konfigurasi yang benar-benar digunakan service.

Penutup

Strategi uji PXE boot yang efektif bukan soal membuat satu test besar yang mencoba melakukan semuanya. Yang lebih penting adalah membangun lapisan pengujian yang tepat: unit test untuk logika konfigurasi, integration test untuk kontrak antarkomponen, smoke test untuk memverifikasi image benar-benar mulai boot, dan end-to-end test di CI sebagai gerbang rilis.

Jika perubahan DHCP tidak boleh lolos sembarangan ke produksi, fokuslah pada tiga hal: isolasi environment, observability yang memadai, dan acceptance criteria yang tegas. Dengan kombinasi itu, Anda bisa mengurangi regresi pada DHCP, TFTP, HTTP boot, menu boot, dan konfigurasi jaringan tanpa membuat pipeline menjadi terlalu lambat atau rapuh.

Quick Search

shopping_cart Keranjang