Docker Engine 29.10.0-rc.1: OpenAPI 3.2 dan Jobs Eksperimental

Docker Engine 29.10.0-rc.1 terbit 6 November 2026 dan membawa tiga perubahan yang menyentuh cara tim berinteraksi dengan daemon: spesifikasi Engine API pindah ke OpenAPI 3.2, paket resmi tersedia untuk AlmaLinux, Oracle Linux, dan Rocky Linux, serta jobs eksperimental yang bisa menjalankan beban sekali jalan maupun terjadwal langsung dari daemon. Data di artikel ini dibaca dari halaman rilis moby/moby pada 7 November 2026, termasuk nomor pull request tiap perubahan.

TL;DR

• 29.10.0-rc.1 terbit 6 November 2026 dengan API versi 1.57, BuildKit 0.35.0-rc1, dan Go 1.27.3.
• Spesifikasi Engine API memakai OpenAPI 3.2 sebagai format sumber, sementara Swagger 2.0 tetap dihasilkan untuk kompatibilitas.
• Jobs eksperimental menjalankan beban sekali jalan dan cron lewat daemon, diaktifkan dengan ekstensi org.mobyproject.jobs.v0.
• Paket resmi kini tersedia untuk AlmaLinux, Oracle Linux, dan Rocky Linux.
• 29.10.0-rc.1 adalah rilis kandidat, bukan rilis stabil. Jalur stabil terakhir adalah 29.9.3 yang terbit 3 November 2026.

Bagi tim yang mengelola image dan pipeline, rilis kandidat selalu menimbulkan pertanyaan yang sama: mana yang layak dicoba sekarang, dan mana yang harus menunggu. Artikel ini memisahkan keduanya berdasarkan isi rilis, bukan berdasarkan nomor versi. Semua klaim di bawah bisa dilacak ke pull request yang tercantum di catatan rilis resmi.

Apa yang berubah di Docker Engine 29.10.0-rc.1?

Ada empat perubahan struktural: spesifikasi Engine API pindah ke OpenAPI 3.2, API naik ke versi 1.57, paket distro bertambah tiga keluarga, dan containerd bawaan bisa dikonfigurasi lewat berkas di direktori /etc/docker/containerd.d/. Sisanya adalah perbaikan bug jaringan, rootless, dan pengemasan.

Perubahan pertama punya efek jangka panjang. Selama ini spesifikasi API Docker didistribusikan sebagai Swagger 2.0, format yang sudah tua dan tidak mendukung sejumlah konstruksi skema modern. Dengan OpenAPI 3.2 sebagai format sumber, generator klien dan validator skema pihak ketiga bisa membaca definisi endpoint tanpa penerjemahan tambahan. Swagger 2.0 tetap dihasilkan, jadi alat lama tidak langsung rusak.

Perubahan kedua terlihat kecil tetapi berdampak pada pustaka klien. API versi 1.57 berarti klien yang mematok versi API tertentu perlu memeriksa kompatibilitas sebelum memanggil endpoint baru. Klien yang tidak mematok versi biasanya aman, karena daemon tetap melayani versi lama selama masih didukung.

Perubahan ketiga paling mudah dirasakan tim operasi. Selama ini pengguna AlmaLinux, Oracle Linux, dan Rocky Linux harus memakai repositori CentOS atau menambal sendiri. Dengan paket resmi, jalur pemasangan untuk ketiga distribusi itu menjadi sama dengan jalur RHEL, termasuk pembaruan lewat manajer paket.

Apakah jobs eksperimental menggantikan cron di host?

Tidak. Jobs adalah ekstensi opsional yang dijalankan daemon, bukan pengganti cron sistem, dan statusnya masih eksperimental. Fitur ini harus dinyalakan secara eksplisit dengan flag --enable-extension org.mobyproject.jobs.v0, sehingga daemon yang tidak memintanya tidak berubah perilakunya.

Yang ditawarkan jobs adalah cara mendefinisikan beban sekali jalan dan beban terjadwal memakai objek yang dikelola daemon, bukan berkas crontab di host. Untuk tim yang sudah memakai Docker Swarm atau ingin menyatukan siklus hidup beban dalam satu kendali, ini mengurangi satu lapisan konfigurasi di luar Docker.

Meski begitu, kata eksperimental perlu dibaca apa adanya. Ekstensi eksperimental bisa berubah bentuk antar rilis, dan tidak dijamin kompatibel ke belakang. Untuk beban yang sudah berjalan di cron host dan tidak bermasalah, memindahkannya ke jobs sekarang berarti menukar stabilitas dengan kerapian konfigurasi. Pertukaran itu masuk akal di lingkungan uji, belum tentu di produksi.

Satu hal yang perlu dipahami sebelum mencoba: jobs dikelola daemon, sehingga status beban tersimpan bersama data Docker, bukan di crontab host. Ketika host dipulihkan dari citra lama, jadwal yang dibuat lewat jobs ikut kembali ke kondisi citra itu, kecuali volume data Docker ikut disalin. Pada cron host, kondisi sebaliknya berlaku: jadwal tetap ada karena berkasnya bagian dari sistem berkas host.

Bagaimana perbandingan 29.9.3 dan 29.10.0-rc.1?

29.9.3 adalah rilis patch keamanan, sedangkan 29.10.0-rc.1 adalah rilis fitur tahap kandidat. Keduanya menjawab kebutuhan yang berbeda, sehingga membandingkannya sebagai "lebih baru" atau "lebih lama" melewatkan intinya.

Aspek	29.9.3 (stabil)	29.10.0-rc.1 (kandidat)
Tanggal rilis	3 November 2026	6 November 2026
Isi utama	Empat CVE di Engine dan SwarmKit	Fitur baru dan perbaikan bug
Versi API	1.56	1.57
BuildKit	Rilis stabil saat itu	0.35.0-rc1
Jobs terjadwal	Tidak ada	Eksperimental, perlu flag ekstensi
Paket AlmaLinux, Oracle, Rocky	Tidak tersedia	Tersedia
Status pemakaian	Produksi	Uji coba

Baris versi API pada tabel itu perlu diperiksa ulang di catatan rilis resmi sebelum dipakai sebagai acuan internal, karena nomor versi API tidak selalu naik di setiap rilis patch. Yang tercatat di catatan rilis 29.10.0-rc.1 adalah kenaikan ke 1.57 lewat pull request moby/moby nomor 53972.

Perbaikan jaringan apa yang masuk di rilis ini?

Ada delapan perbaikan jaringan, dan tiga di antaranya menyentuh kasus yang cukup sering dilaporkan: aturan iptables yang tidak kembali setelah firewalld berhenti, MTU antarmuka overlay yang kelebihan 20 byte pada jalur data Swarm IPv6, dan resolusi DNS di jaringan buatan pengguna ketika berkas resolv.conf host kosong.

Kasus firewalld layak diperhatikan karena berulang. Ketika firewalld dihentikan atau dinyalakan setelah daemon berjalan, aturan iptables milik Docker bisa hilang, dan container kehilangan jalur keluar tanpa pesan error yang jelas. Perbaikan di 29.10.0-rc.1 memulihkan aturan itu, sementara rilis 29.9.3 menutup celah keamanan pada overlay Swarm setelah firewalld membersihkan aturan iptables. Dua-duanya gejala dari akar yang sama: dua pengelola firewall yang menulis ke tabel yang sama.

Untuk operator, urutan pengamanan yang masuk akal adalah memastikan urutan start layanan tetap konsisten, lalu memakai versi yang sudah memuat perbaikan pemulihan aturan. Tanpa urutan yang konsisten, perbaikan di level Docker hanya mengurangi frekuensi masalah, bukan menghilangkannya.

Perbaikan MTU 20 byte juga bukan kosmetik. Nilai MTU yang terlalu besar membuat paket terfragmentasi atau dibuang pada jalur yang punya batas lebih ketat, dan gejalanya muncul sebagai koneksi yang lambat pada beban tertentu, bukan error. Pada klaster yang berjalan di atas jaringan dengan MTU tidak standar, selisih 20 byte cukup untuk membuat sebagian permintaan gagal.

Apakah aman memasang rilis kandidat di server produksi?

Tidak untuk layanan yang butuh stabilitas, tetapi aman untuk lingkungan uji yang memang ingin menemukan regresi sebelum rilis stabil keluar. Rilis kandidat belum melewati seluruh siklus verifikasi yang dilalui rilis stabil, dan isinya masih bisa berubah antar rc.

Yang masuk akal dilakukan sekarang adalah menguji tiga hal di lingkungan uji: klien API yang dipakai tim, pipeline build yang bergantung pada BuildKit, dan integrasi jaringan pada konfigurasi firewall yang dipakai. Tiga area itu yang paling mungkin terpengaruh oleh perubahan di 29.10.0.

Untuk produksi, jalur yang benar tetap 29.9.3 sebagai rilis patch keamanan terakhir, dengan catatan empat CVE yang ditutup di dalamnya sudah disebut di catatan rilis resmi. Detail tiap CVE tersedia di basis data GitHub Advisory dan di catatan rilis BuildKit untuk komponen yang dipakai saat build.

Bagaimana cara mencoba 29.10.0-rc.1 tanpa mengganggu host?

Cara paling aman adalah menjalankannya di mesin terpisah atau mesin virtual sekali pakai, bukan di host yang sedang melayani trafik. Rilis kandidat mengganti daemon, dan daemon yang rusak mematikan semua container di host itu sekaligus.

Langkah praktisnya: siapkan host uji dengan versi Docker saat ini, catat keluaran docker version dan docker info, pasang 29.10.0-rc.1 dari arsip biner resmi, lalu jalankan pipeline build dan satu layanan contoh. Perhatikan apakah ada peringatan baru saat daemon start, dan periksa apakah aturan jaringan yang dipakai masih terbentuk setelah firewall dijalankan ulang.

Arsip biner resmi kini dipisah menjadi docker-cli dan docker-engine di samping arsip gabungan docker. Pemisahan ini memudahkan pengujian komponen secara terpisah, misalnya menguji klien baru terhadap daemon lama. Prosedur pemasangan dari biner dijelaskan di dokumentasi pemasangan Docker Engine dari biner, dan definisi endpoint yang berubah bisa diperiksa di referensi Engine API.

Apa manfaat konfigurasi containerd lewat /etc/docker/containerd.d/?

Direktori itu memberi tempat resmi untuk menyesuaikan containerd bawaan Docker tanpa mengganti unit layanan atau menambal berkas konfigurasi internal. Sebelumnya, penyesuaian seperti itu biasanya dilakukan dengan mengganti containerd sepenuhnya, dan cara tersebut rapuh karena hilang setiap kali Docker diperbarui.

Bagi operator, perubahan ini mengurangi satu sumber konfigurasi liar. Tim yang butuh menyesuaikan parameter runtime untuk beban berat, misalnya batas snapshotter atau pengaturan plugin, kini bisa menaruh berkas tambahan di satu direktori dan membiarkan daemon menggabungkannya. Berkas di luar direktori itu tetap dipakai untuk konfigurasi utama, sehingga perubahan bisa dilacak dari satu tempat.

Yang perlu diwaspadai, konfigurasi yang salah di lapisan containerd bisa membuat container gagal start tanpa pesan yang jelas di level Docker. Sebelum menaruh berkas di direktori itu, sebaiknya uji dulu di host sekali pakai, lalu bandingkan keluaran docker info sebelum dan sesudah perubahan. Selisih yang tidak dijelaskan di catatan perubahan adalah tanda bahwa berkas konfigurasi terbaca tetapi nilainya tidak seperti yang diharapkan.

Untuk tim kecil, fitur ini mungkin tidak langsung terasa. Nilainya muncul saat jumlah host bertambah, karena konfigurasi bisa disebar sebagai berkas biasa lewat manajemen konfigurasi yang sudah dipakai, bukan sebagai langkah manual per mesin.

FAQ

Kapan 29.10.0 versi stabil keluar?

Belum ada tanggal publik. Yang tercatat hanya 29.10.0-rc.1 pada 6 November 2026. Rilis stabil biasanya menyusul setelah siklus kandidat selesai, dan tanggalnya baru bisa dipastikan dari pengumuman resmi.

Apakah OpenAPI 3.2 mematahkan generator klien lama?

Tidak langsung. Spesifikasi Swagger 2.0 tetap dihasilkan untuk kompatibilitas, sehingga generator lama masih bisa memakai berkas itu. Yang berubah adalah format sumber yang dipakai Docker untuk memelihara definisi API.

Apakah jobs bisa dipakai tanpa Swarm?

Ya, jobs dikelola daemon dan tidak bergantung pada mode Swarm. Meski begitu, fitur ini masih eksperimental dan harus dinyalakan dengan flag ekstensi, jadi perilakunya bisa berubah di rilis berikutnya.

Apakah 29.9.3 masih perlu dipasang kalau menunggu 29.10?

Ya. 29.9.3 menutup empat CVE yang tidak akan hilang dengan menunggu. Menunggu rilis fitur sambil membiarkan celah keamanan terbuka adalah pertukaran yang salah arah.

Rekomendasi Tools & Layanan

Kalau lo mau langsung praktikkan panduan di atas, dua layanan yang gue pake sehari-hari: free trial Alibaba Cloud buat coba-coba tanpa biaya di awal, dan ECS instance 9th-gen kalau udah siap naik ke VPS production.